抖音视频抢红包，抖音红包视频教程
春节活动期间，抖音将视频与新年红包结合起来，让用户通过拍摄视频、发红包的方式向粉丝朋友送上祝福。
商业玩法整体活跃度玩法分为B2C和C2C两种玩法，下面简单介绍一下这两种玩法的流程。
B2C红包在B2C红包的玩法中，用户必须先去抖音或抖音精简版参与春节红包雨活动，并有一定概率在春节红包雨活动中领取红包补贴。用户领取补贴后可以直接跳转到相机页面，也可以在拍摄视频后跳转到相机页面。在相机页面，录制视频后会出现一个红包小部件，您可以在小部件内查看以下内容：补贴已发放。当用户选择补助并点击“下一步”完成提交后，视频红包发放完成。
图1 新年红包雨活动图2 红包补贴图3 红包挂件图4b2c 红包发送标签页
C2C红包在C2C红包玩法中，用户可以拍摄视频，点击挂件，输入红包金额和数量，选择红包范围，点击“发送红包”即可显示收银台。用户完成付款后，单击“下一步”发布视频。也就是说，你可以完成C2C红包的发放。
图1C2C红包发送标签页图2 支付界面图3 红包支付后Widget展示
领取红包B2C 和C2C 的领取红包流程相同。当用户在抖音浏览视频时，遇到内含红包的视频时，该视频底部有一个领取红包的按钮，当用户点击红包领取时，红包的封面红包将会打开。用户可以点击红包封面，打开红包并领取红包。成功领取红包后，会弹窗显示兑换结果。兑换结果允许用户：确认兑换金额并进入兑换详情页面。在兑换详情页面，您可以查看其他领取该红包的用户的运势。
图1 红包视频图2 红包封面图3 红包领取结果图4 红包领取详情
卫视春晚演示视频C2C视频红包也将在卫视春晚进行宣传，让大家了解卫视春晚的整个流程，这里将贴出卫视春晚宣传视频。
正在加载视频.
上面提到了万能红包系统设计中遇到的一些问题。这次春节活动应该同时支持B2C和C2C红包。这两类红包虽然有一些相似的业务，但也有很多不同之处。工作。同时，这一切都涉及到两个操作：发放红包和收红包。例如，发放B2C红包需要使用补贴，而发放C2C红包则需要用户完成支付。 B2C红包用户收到后必须提现，而C2C红包用户收到后立即找零。因此，必须设计一个通用的红包系统，支持多种红包类型。另外，红包系统本身不仅有红包的发放和接收，还有查询一些红包信息以及推广各种状态机，所以如何划分这些功能模块也是需要考虑的。
发放和办理大额流量补贴如上所述，B2C红包游戏首先发放补贴。过年活动期间，每次红包送礼都会有大量用户参与。如果将这些流量直接发送到数据库，将需要大量的数据库资源。过年期间，数据库资源极其紧缺。我们如何减少这方面的资源呢？消耗也是一个需要考虑的问题。
选择红包领取方案在红包业务中，领取的情况频繁发生，因此领取方式的设计必须考虑业务场景是否会存在多个用户同时领取红包的情况。当多个用户同时收到同一个红包时，可能会出现热点账户问题，并成为系统性能的瓶颈。解决热点账号问题的方案有多种，应根据视频信封业务场景特点选择合适的方案。
本次贺岁活动的稳定容灾包括B2C和C2C两个业务流程，每个业务流量链路都依赖很多下游服务和基础服务。在如此大规模的活动中，当出现黑天鹅现象时，必须考虑的问题是如何快速止损，减少对整个系统的影响。
资金安全保障春节活动期间，B2C会发放大量红包补贴，但可能存在补贴发放过多或补贴摊销存在问题的情况，补贴可能会多次摊销。会造成较大的资金损失。此外，由于C2C涉及用户资金的流入和流出，如果自己的资金在收到红包后减少，也可能会引起大量的客户投诉和资金损失。因此，您需要为自己的财务安全做好充足的准备。
压力测试红包系统传统的压力测试方法通常在大流量接口上进行压力测试，以识别系统瓶颈。但在红包系统中，发放和用户确认是同时完成的，比如需要先发送红包，收到红包后才可以接收红包，而且这些接口也是相互的独家. 取决于.触发多人集合。采集完成后才能查看采集详情。采用传统的单界面压测方法，首先数据模拟难度很大，而且支付对应的压测数据因为涉及到实名，需要专门生成，这也比较困难。想要得到系统的实际瓶颈，就需要对单个接口进行压力测试，那么如何对系统进行全链路的压力测试，得到系统的准确瓶颈，也是需要解决的问题。
我们如何设计一个通用的红包系统呢？对于红包系统来说，核心操作包括红包的发送、接收和无人认领的退款。另外，您还应该查看红包信息和领取信息。同时，三大操作必须保持其状态：发送、接收和退款。同时，在我们的业务场景中，也有针对B2C的补贴发放，我们也需要维持补贴状态。上面对红包系统进行了初步的介绍后，我们可以看到红包的几个功能模块，包括发放、领取、退款、补贴发放、各种信息查询、状态机维护等。红包，我们开始拆分红包模块。
红包Redis限流是为了尽可能减少DB锁争用，首先根据红包数量进行限流，每次允许剩余红包数量*1.5个请求通过。限流时返回特殊错误码。前端最多可训练10次。该方法用于在请求过多时减慢内存队列的速度。除了Redis限流之外，还添加红包内存锁，减少DB锁。通过单个红包，只有获取内存锁的请求才能继续向DB发出请求，从而将DB锁争用迁移到内存进行初始处理并保留内存资源。相对于DB资源来说非常便宜，如果请求量太大也可以横向部署。我做了一些更改来实现内存锁定。首先，我们需要确保可以向同一个tce实例发送相同的红包请求。这里我们调整了网关层路由。网关层调用下游服务时，路由策略基于红包单。使用数字来确保具有相同单个数字的请求被发送到同一个实例。另外，红包系统的核心服务实现了一系列基于通道的内存锁，当收集完成后，红包对应的内存锁被释放。另外，为了防止锁占用过多内存或者没有及时释放，我设置了一个定时任务来定期处理锁。异步传输就接口时间消耗而言，传输是耗时的操作。这包括与第三方支付机构的互动。这会导致跨机房请求和较长的响应延迟。异步传输节省了接口时间。通过延迟领取红包，您可以提高我们服务的性能和用户体验。另外，从用户感知角度来看，用户更看重点击打开后是否成功领取红包。用户对余额是否同步的感知不是很强，而且转账本身是从转账过程到转账成功，转账异步从根本上影响用户感知的稳定性，没有影响，对于灾难整个红包系统的恢复，我们主要关注接口限流、业务降级以及多种机制保证状态机前进。该方法被执行。下面对每种方法进行介绍。
接口限流接口限流是一种常见的灾难恢复方法，用于保护系统仅服务可接受范围内的请求，并防止系统因外部请求过多而崩溃。在限制接口电流之前，我们首先与上游、下游和产品进行沟通，获得红包发放和领取的预估，然后根据红包的数量逐个模块计算出该链路的总流量。发行和收藏，必须分类。我当时整理的内容是：B2C全链接请求量。
得到各个模块的请求量后，经过聚合，我们就可以得到每个接口、红包系统中的每个服务以及下游依赖服务的流量请求，这对于限流很有用。
业务降级核心依赖降级春节期间，整个红包系统链路依赖的服务较多，这些下游链路依赖可以分为核心依赖和非核心依赖，如果下游核心服务不健康，导致某条链路不可用，可以直接在API层降级，返回更友好的文案提示，待下游服务恢复后发布。例如，在C2C红包发送过程中，用户必须先完成支付才能发送红包，但如果财务支付过程出现异常或支付成功状态长时间未完成，则不会发送红包。用户支付后发送成功，前端不停止。红包状态查询轮训导致请求量激增，造成服务压力，甚至影响B2C红包发放和查询。此时，您可以将C2C红包发放降级，通过接口降级的方式将其恢复回来，以缓解您的业务压力，减少对其他业务逻辑的影响。降级非核心依赖除了核心依赖之外，红包系统还有多个非核心下游依赖。对于这些依赖项，如果你的服务不健康，你可以降低一些用户体验来保证服务可用性。例如4.2中提到的，用户在发送B2C红包之前必须获得所有可用的红包补贴。去奖励发行者查询所有代币列表，然后查询自己的DB，合并并返回。如果您检索令牌列表的接口不常见，您可以将其降级为仅返回您自己的数据库中的授权数据。这使得用户在这种情况下仍然可以发红包，并且仅影响部分补贴的可见性。请发一个比影响整个红包的链接。
多种机制保证状态机的演进。以红包系统为例，如果用户收到红包后很长时间没有收到红包，或者订单很长时间没有达到最终状态，则用户将不会收到C2C红包并且长期不退款，引发用户投诉。因此，您需要能够及时、准确地将系统中每个订单的状态提升到最终状态。有多种方法可以确保这一点。第一个是回调。依赖方系统中的订单处理完毕后，会及时通知红包系统。这个方法也是最及时的。但是，仅依赖回调可能会导致依赖方异常、网络抖动和回调丢失。它在每个红包阶段都会向红包系统发送mq，定期消耗mq，并主动查询依赖方的订单状态是否有更新。最后，我们为每个状态机安排了一个计划任务来查看详细信息。如果某个定时任务运行多次未达到最终状态，则会发出Lark 通知，以便及时进行人工干预。找出问题所在。
资金的安全保证了交易的幂等性。在编程中，幂等性是指无论执行多少次请求，其效果都与执行一次相同。在资金安全方面，通过订单号进行相应的幂等逻辑处理，可以防止资金损失的发生。具体来说，红包系统使用订单号的唯一key来保证红包发放、领取、退款时接口的幂等性。另外，红包系统的补贴发放接口是幂等的，因此如果您使用同一分包号多次申请补贴，必须保证只发放一张优惠券。实现幂等性的解决方案有很多，包括使用数据库或Redis实现幂等性。最可靠的方法是在数据库内实现唯一键冲突，但如果数据库内有分片实例，则此方法会引入一些额外的问题。这里简单介绍一下补贴的分配，在业务系统的设计中，业务数据库表是采用UID分片的方式构建的，所以补贴的分片键就是UID，我也设置了一个信封。授权订单号用作唯一密钥。但是，如果上游系统调用grant签发时，同一个外部订单号改变了UID，则两次请求将被发送到不同的数据库实例，导致唯一索引失效，可能造成资金损失。为了解决这个问题，我们引入了一个额外的数据库，使用补贴发放外部采购订单号作为分片键来消除这个风险。
B2C红包验证除了在开发过程中将资金安全考虑纳入系统设计之外，还必须通过协调验证系统是否存在资金安全问题。 B2C环节主要进行从补贴发放到红包领取的整个环节，并对这些环节的上下游数据进行相应的每小时蜂巢对账。
C2C环节中的C2C红包验证主要从用户发起支付开始，一直持续到用户收到汇款，最后直到红包退款到期。您需要分别确认支付、转账、退款三个流程。同时，还需要确认用户的红包发行金额大于或等于红包汇款金额+红包退回金额。从收到红包到退款成功需要24小时以上。此外，可能还有正在进行转移的订单。这会导致多次退款订单。如果要求严格相等，则您无法控制任何特定调整的时间。
对红包系统进行压力测试前面提到，红包系统中的链路包括多个接口、发送和接收检查等。为了获得系统的真实性能，您需要模拟真实的用户行为进行压力测试。我们将使用压力测试平台的脚本化压力测试技术来进行压力测试。首先，需要对整个压测环节进行彻底改造，向上下游沟通是否可以进行压测，如果不能进行压测则进行相应的mock处理。另外，对于存储服务、数据库、redis、mq，必须保证压测标准发送正确。否则可能会影响在线流程。转换压测链接后，需要构建相应的压测脚本。该脚本分为两个脚本：一个用于B2C，一个用于C2C。
B2C红包链接压力测试以上是B2C压力测试的整个链接首先发放补贴，然后通过联系补贴，通过补贴发放红包，设置多个goroutines来接收红包同时地。
C2C红包链路压力测试由于C2C红包包含支付相关操作，整个链路是一组独立的流程，因此C2C也需要单独的脚本。压力测试过程涉及对外部系统的依赖，因此等待完整链接正常后再一起进行压力测试可能会引入未知问题。所以一旦自己的压测没问题，就应该开始对整个链路进行压测。在图中与支付相关的蓝色模块中，我们添加了相应的模拟开关来控制压力测试结果。如果模拟开关打开，则直接构造并返回结果；如果模拟开关关闭，则照常请求财务结果。
事后服务设置在上述系统容灾中，如果红包核心服务发生变更或者数据库DB主机房挂掉，所有用户都会受到影响，但目前只能降级和恢复。您无法快速切换和恢复整个系统。然后考虑将您的服务更改为固定架构。将业务服务器和相应的存储划分为独立的集合，每个集合只处理其对应分区单元内的流量，同时在多个单元之间进行流量分流和故障隔离，并在集合之间进行数据备份来实现。如果某个单元出现故障，这样可以及时将流量从某个单元切换到备用单元。
加入我们的开放平台钱包团队，为抖音开放平台提供基础支付功能支持。当前，企业快速发展，面临各种复杂的场景和技术挑战。如需参与，请发送电子邮件至：wanghao.rock@bytedance.com 您想加入我们吗？
