本文主要从服务器的角度对2022春节赏花活动中的钱包提现模块进行总结和反思，希望对整个开发过程中使用的技术和遇到的问题进行梳理和整理，对后续类似活动有所帮助。 　　

　　

　　一、活动背景及互动流程2022年春运活动的目标是在Tik Tok、火山、西瓜等八个终端开始。希望Tik Tok码头能够向码头引水，实现“一个字节，一个春节”的活动。对于用户来说，可以在任何一端参与春节活动，在钱包里看到集卡、红包雨等游戏获得的全部收入。最后，他们可以在任何一端将春节收入提现到个人账户，保证用户在活动中的奖励能够落地，提高他们对春节活动的参与度。 　　

　　

　　进入活动钱包页面后，互动用户可以查看参与活动获得的奖励收入，点击【提现】按钮跳转到提现页面。在提现页面，用户输入提现金额并选择绑定收款方式，然后点击【确认提现】，将活动收益提现到自己选择的个人账户中。 　　

　　

　　 　　

　　

　　2.提现，大流量下的主要问题，是指用户将参与集卡、红包雨等活动的奖励收入提取到银行卡、支付宝或Tik Tok零钱等个人账户。由于春节活动集中抽奖带来的高流量，以及活动奖励金额巨大的特点，在开展春节活动提现的过程中，有几个方面需要考虑： 　　

　　

　　1.过账延迟和提款限制。除夕19:00-23:00每小时开启红包雨，开始19336030春节活动卡抽奖和烟花大会。此时，面对正在记录的数百万QPS用户的奖励，请求记录可能会出现一些延迟，导致用户提现时看到的金额与参与活动获得的奖励金额不一致。 　　

　　

　　 　　

　　

　　此外，今年春节提现提高了每单1元提现的门槛限制。有了集卡抽奖的加持，除夕夜的红包雨和烟火表演，用户可以轻松获得1元以上的收益。但如果在收入达到门槛后立即提现，可能会导致因为参与后续游戏获得的奖励较少而无法提现的情况。 　　

　　

　　2.在高并发卡抽奖和红包雨之后，提现入口打开时将面临几十万的请求流量。用户选择支付方式，输入取款金额后，也有数万张QPS取款单。钱包服务器收到请求后，会操作扣除用户的活跃账户余额，然后调用金融端(字节内部的支付中间站)请求支付。金融端维护与各类支付机构(支付宝、银网联)的接入交互。但是，每个支付机构分配给每个单位的支付请求流量是有限制的，在字节端获得的容量与提现相差一个数量级。此时需要保证用户的提现体验不受影响，同时需要保证下游通道侧不会出现高流量带来的可用性抖动。 　　

　　

　　3.资金安全提现是春节活动的最后一道流程。公司从用户春节活动的收入账户中扣款，并通过预设的预留账户将资金转入到最终绑定的个人账户中，使获得的奖励最终落地。如果用户在终端上的操作是超额支付，一旦支付成功，基本没有挽回的可能。因此，资金安全是提现业务发展过程中必须考虑和保障的部分，以保证每一笔支付都是可追溯的，符合提现规则的。 　　

　　

　　三、设计方案针对以上问题，我们使用RocketMQ进行异步支付，保证用户体验。同时，RocketMQ的使用还可以将银行卡等支付渠道的峰值削减到r 　　

　　

　　1.除夕当天，将举行抽奖活动，从19:30集卡。用户进入主会场就可以看到集卡奖励。同时，他们可以在烟花表演开始参加活动时获得红包奖励。另外20:00-2:00每个小时都会有红包雨。用户将继续获得春节奖励，并进入钱包页面查看个人收入。 　　

　　

　　 　　

　　

　　为了保证卡抽奖和红包雨活动顺利过账，不会出现因钱包无收入或无奖励导致的提现错误。当用户进入提现页面时，我们会根据最后请求参数中的红包令牌列表进行过账请求，以保证在用户确认提现订单之前，账户中的金额可以通过令牌列表强制过账。但是为了让用户在提现页面有更好的体验，这里的发帖是弱依赖请求。当用户确认提现订单时，我们设置了强依赖强制过账作为最终方案，使得奖励金额已经过账成功，支持提现。 　　

　　

　　同时，为了保证用户在活动结束后能够提现全部奖励，减少用户因为提现门槛而无法提现的情况，我们在春节活动中启动了延迟大批量提现。19:00-凌晨1: 00关闭提现入口时，用户只能在主会场参加活动获取奖励，不能进入钱包页面提现。当用户在活动钱包页面点击【提现】时，会弹出窗口提示用户在01:00年2月1日之后提现。此外，在弹窗中，还加入了用户绑卡的营销策略，引导用户提前绑卡，让提现更快捷。 　　

"https://tupian.lamuhao.com/pic/img.php?k=余额宝转账到卡里的钱怎么转出,余额宝普通转出会提前到账吗4.jpg">

　　

随着凌晨一点提现入口打开，可能会有大量用户涌入提现页面进行提现。此时，为防止瞬间流量突增过高可能引发数据库连接问题，我们通过在配置平台上进行配置，针对用户 id 进行取模后的结果进行分批放开。在有限的情况下，确保用户入账无误，请求不被限流是我们用户体验是否良好一个比较重要的评判因素。延迟到凌晨 1 点分批次放开提现有效降低了用户提现的并发，保障了用户提现体验。

　　

2. MQ 异步出款在除夕当天的晚上 19:00 到春节凌晨 01:00 时间段内，春节活动钱包页中会暂时关闭提现功能，进行部分营销导流。而随着凌晨 01:00 提现开关打开，请求会蜂拥而至逐步上涨至数万 QPS，但由于银网联的处理能力有限，导致银行卡渠道出款最高可支持的 QPS 只有几千。此时如果提现模块不进行限速下单的话，可能存在下游系统被压垮引起雪崩的风险，同时用户会给感受到提现功能卡顿并频繁失败。

　　

为解决该问题，我们引入了 RocketMQ 来进行异步出款。当用户在钱包页进行提现操作时，服务端会在春节活动收入账户扣款完成后立即返回结果并跳转至提现结果页面展示当前状态，同时将当前请求参数发送至 MQ 中进行异步消费出款。这样给用户的感觉即账户余额已扣除，提现出款进行中，稍后也可以通过账单流水查询提现结果。

　　

　　

将消息发送到 MQ 后，提现模块利用 MQ 消费提现订单的现金出款，通过下游消费者有限的消费能力进行消息处理。同时增加自定义限流器对每个出款渠道进行限流，利用 MQ 进行流量削峰与限流出款两种方式双重保证了下游出款不会因流量过高而出现抖动。当消费成功时则顺利出款，当消费失败或被限流时则返回错误，MQ 会进行消费重试。我们在这里设置 MQ 最大重试次数为 3 次，如果消息没有超过最大重试次数，则被放入 retry 队列；如果消息达到最大重试次数，则放入死信队列不再处理。

　　

2.1 定时任务为防止提现订单因 MQ 多次重试消费失败或其他原因导致状态一只卡在某个中间状态停止更新，我们额外设置了定时任务进行补单操作推进提现状态。每小时固定从数据库中捞取已被创建超过 4 个小时且当前还处于未完成状态的订单，并根据其当前状态进行推动：

　　

待扣款的订单，则说明用户的账户收入还未进行扣款，此时则直接将订单状态推进为失败状态；待出款状态的订单，请求财经接口进行出款操作，推动状态到出款中或出款完成；出款中的订单，查询财经出款订单的状态，如果财经侧已成功或失败则将该状态同步更新到提现订单中，如果财经侧查单不到的话则调用财经出款接口进行重试；对于从任一状态流转至失败的订单，我们会查询账户的订单流水，如果账户侧存在余额扣减流水的话，则操作进行余额退回，保证失败的订单不会扣减用户的收入。

　　

3. 提现资金安全在提现的过程中，一旦技术方案设计有问题，容易存在资金安全问题：账户未扣款但现金已转入用户的个人账户，账户多次扣款或者现金多次出款等。因此，在春节活动中提现模块的设计中，资金安全问题是重点考虑的部分。在提现请求发生时，服务端需要确保每笔订单一定对应一次账户余额扣减，一次现金出款。而提现完成后，需要有对账任务与账户和财经出款进行对账，分别对提现订单的金额和状态进行校验，保证事件中的验证无误。

　　

3.1 订单幂等幂等，指任意多次执行所产生的影响均与一次执行的影响相同。提现针对 orderID 做幂等性控制，在账户侧每个 orderID 只有一笔扣款操作，从而保证用户的活动账户余额不会被重复扣款；同时，在用户当前订单提现失败后进行账户余额回滚操作时，首先查询账户侧是否存在扣款订单，如果存在则进行余额退回，退回时控制一笔扣款操作对应一笔退回流水，防止出现多退的情况。

　　

账户完成扣款之后，需要调用财经的出款接口将资金从公司预先设置的备付金账户转入至端上绑定的个人账户中，此时需要确保每笔提现请求只能有一次出款。在每次操作提现订单进行现金出款时，我们使用 redis 分布式锁对 orderID 进行加锁操作，加锁成功后判断当前订单状态，如果是待出款状态则调用财经接口进行现金出款。在接口调用后立即更新订单状态为出款中，防止重复调用引发可能出现的重复出款操作。同时，财经侧也针对 orderID 做了幂等控制，确保每笔 orderID 都对应一笔出款。

　　

　　

3.2 对账校验涉及到资金流动，需要有对账任务来保证上下游之间资金数据的一致性，能够及时发现处理金额或状态差异导致的资损问题。我们在对账平台分别增加了准实时对账和天级对账来进行资金的校验。

　　

　　

准实时对账在提现事件发生过程中，我们在对账平台中增加了与下游服务（账户、财经）提现数据的准实时对账，确保提现订单每次状态变化时都是准确无误的：

　　

1. 与账户侧准实时对账：

　　

a. 在余额扣减成功后账户侧会保存一笔提现扣款的数据流水，此时需要将扣减流水与提现订单进行金额和状态校验，确保扣款状态和金额一致；

　　

b. 在提现失败的时候，如果此时账户侧已经扣款成功的话则需要将之前扣减的金额退回至用户的活动账户中，此时需要在余额退回成功后进行账户金额退回流水与提现订单状态、金额做校验。

　　

2. 与财经侧准实时对账：

　　

a. 在提现订单状态更新为成功或失败时，获取财经侧的出款订单数据与提现订单数据进行一致性校验，判断双方数据的状态、金额是否一致。

　　

对账平台中的数据校验，是基于数据双方的 binlog 消费进行的准实时对账，在对账双方任一方缺失数据或双方对账状态金额出现不一致的情况下便会发送飞书报警通知。

　　

　　

此外，我们还在线上服务中增加了自主对账任务，通过消费提现数据库的 binlog 消息。针对其中到达终态的订单，我们会根据订单状态分别通过接口调用的方式对账户、财经侧进行查单检查。成功的提现订单在账户的查单接口中可以查到一笔扣款流水，在财经的查单接口中也会有一笔出款成功的订单。而失败的提现订单在账户的查单接口中可以查到一笔扣款和一笔退回余额的流水，在财经的查单接口中如果可以查到订单的话则只有失败订单，如果没有订单的话说明提现流程还没有走到出款便失败了，此时可忽略缺失的差异。

　　

天级对账另外，我们也增加了与下游服务（账户、财经）的天级对账，作为准实时对账之外的一种兜底对账。因为上下游之间可能因调用失败或者回调失败导致状态同步不及时，我们增加了定时任务进行订单状态推进，保证每笔提现订单最终都可以达到终态。天级对账即为了解决状态同步不及时可能引发的准实时对账差异，通过每天生成的 hive 数据进行状态和金额校验，减少时间差产生的误报。

　　

　　

　　

四、前期预案为保证活动上线后用户能够在钱包页中进行正常提现，我们在活动开始前增加了准备预案。

　　

1. 提前演练在活动正式开始前，我们组织了内部圈定人群、内部所有人、外部圈定城市等三次预演，针对春节活动红包雨和现金提现进行了提前演练，模拟春节活动的正常流程与突发情况的处理。通过演练，我们可以提前发现整个活动流程是否顺利，并将可能存在的问题提前暴露解决。

　　

　　

2. 充分压测为支持春节活动过程中产生的大流量请求，保证给用户提供良好的活动体验，我们将春节活动现金提现与钱包日常收入提现的功能进行了集群隔离。在代码开发上线后，申请压测资源对各业务流程进行了预估流量压测，集群隔离也使得压测操作不会对线上正常业务有任何影响。

　　

　　

在提现业务压测的过程中，有两个方面需要做一些数据准备：

　　

查询到账方式接口需要对压测的 uid 构造已绑定的到账方式结果返回；确认提现下单接口需要对压测的 uid 有绑定到账方式的同时，还需要 uid 对应的活动账户中有足够的金额支持余额扣减。为解决此问题，财经的同学在压测之前提供了一批已绑定到账方式的测试 uid 生成的文件， 方便我们在进行到账方式查询接口压测的时候能够从文件中指定 uid 参数。另外，在账户同学压测入账接口的时候，我们提供了该文件让其帮助对这批 uid 进行入账。如此在压测提现下单的时候，我们使用已经绑定到账方式的测试 uid 数据，其活动账户中已经存在余额可支持提现余额扣减。

　　

最终，通过对到账方式查询、确认提现下单等接口进行全链路压测后，我们能够准确评估了为支持春节活动最高 QPS 所需的各项资源容量，使春节活动可按照预先计算的流量支持用户操作提现。

　　

3. 除夕当日执行剧本除夕是我们春节活动启动后的重要时间点，当天有多场红包雨，同时还有烟火大会和集卡开奖等玩法出现，整个活动会在春节联欢晚会开始的时候达到高潮。在这种大型活动参与过程中，每个人或多或少都会有一些压力在身上。纵使代码经过验证，前期进行过多次演练均无问题，但还是需要抱有谨慎的态度来应对重要活动的开始。在大脑记忆力有限的情况下，为防止出现遗漏，我们针对除夕当天写了执行剧本：

　　

执行细节。从除夕上午十点开始到初一凌晨两点，每场红包雨前需要做什么准备，红包雨发生时需要查看哪些监控指标，红包雨后是否需要记录数据等，执行剧本需要详细记录每个时间点需要做的事情。配置校验。提现业务在春节活动上有活动配置与限流等。在活动开始前需要再次做一遍检查，确保各项配置和限流均正确无误。容灾方案。除执行细节和配置校验外，我们还在剧本中加入了容灾预案，方便在某项流程出现问题的时候能够及时根据预案进行处理。交叉检查。剧本中的各项操作细节和配置检查均为两个人分工进行，通过交叉检查的方式防止出现一人疏忽大意而错误改动的情况。五、活动总结春节活动上线后，用户积极参与各种玩法并在其活动钱包中进行现金提现。在除夕当晚，延时放量虽然使用户在获得收入的第一时间不能进行提现，但用户奖励入账正常，延时放开后提现请求没有被出款渠道限流，有效地保障了用户提现体验。同时，在渠道侧出款能力有限的情况下，通过使用 MQ 进行异步出款有效地限制了对下游服务的请求流量，使其没有因流量过高而导致出款异常。

　　

此外，在春节活动的整个时间段内，通过对提现流程进行风险梳理，增加对账平台准实时与小时级对账支持和线上服务对账支持，双重保障了春节活动现金提现模块对账任务的全覆盖，使用户在参与活动并收获奖励进行提现的过程中未对其造成资金损失，确保了用户的参与度。

　　

加入我们抖音开放平台团队在“激发创造、丰富生活”的使命愿景下，为更好地连接人与服务，满足多场景的用户需求而成立。团队一手肩负着合理开放抖音产品能力与数据，并做好管控，一手负责维护了小程序、抖音钱包等工具。面对多样需求，赋能更多合作方，连接更多外部优质服务、商品、内容，助力抖音各业务，更好满足用户需求，实现终极业务目标。同时，我们也将做好更精细化的开发者/服务商运营，并配合能力和数据的安全治理，保证生态长期可持续发展。

　　

欢迎加入我们，你的每一行代码都会影响亿级用户，实现的每一个功能都会被亿级用户使用，解决的每一个 bug 都会改善亿级用户的体验。

　　

招聘链接：

　　

https://job.toutiao.com/s/FRMqAYp