本文主要从服务端角度针对 2022 年春节 Flower 活动中钱包模块做一下总结与反思，希望可以对整个开发过程中使用的技术和遇到的问题进行整理和沉淀，在后续类似的活动中可以产生一些帮助。

2022 年春节活动目标是在、火山、西瓜等八端启动，希望端能够给多端进行导流，实现“同一个字节，同一个春节”活动。对用户来说，可以在任意一端参与春节活动并在钱包中看到集卡、雨等玩法获得的所有收入，最终可以在任一端春节收入至个人账户中，保证用户在活动中的奖励能够落地，提升用户春节活动参与度。

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

提现即用户将自己通过参与集卡、雨等活动玩法所活动的奖励收入提取至用户的银行卡、或抖音零钱等个人账户中。由于春节活动存在集中开奖导致的高流量，活动发奖瓜分金额巨大等特点，在开发春节活动提现的过程中，有几个方面需要重点考虑：

除夕当晚 19 点到 23 点每个整点开放红包雨，19:30 春节活动集卡开奖与烟火大会启动。此时面对上百万 QPS 的用户奖励入账，可能存在部分请求入账存在延迟，导致用户在提现的时候看到的金额与活动参与获得奖励金额不一致的情况。

此外今年春节活动提现增加了每笔订单 1 元起提的门槛限制，在除夕晚上集卡开奖、红包雨和烟火大会多个玩法的加持下，用户很容易获得 1 元以上的收入。但如果在获得收入达到门槛后立即提现，可能会导致参加后续玩法获得奖励较少而无法提现的情况。

集卡开奖与红包雨后，提现入口打开时将面对几十万的请求流量，经过用户选择到账方式和输入提现金额后也有数万 QPS 的提现下单请求。钱包服务端收到请求后会操作扣除用户的活动账户余额，接着调用财经侧（字节内部的支付中台）请求出款，财经侧维护与各支付机构（、银网联）的接入交互。但各支付机构分配给各单位的出款请求流量有限额，字节这边获得的容量与提现出款相差了一个数量级。此时需要在保障用户的提现体验不受影响的同时，又能够确保下游渠道侧不会因流量较高导致可用性抖动。

提现是春节活动的最后一道流程，公司在用户的春节活动收入账户进行扣款并将资金通过预先设置的备付金账户转入至端上绑定的个人账户中，从而使获得的奖励最终落地。如果用户在端上的操作出现打款超额等情况，一旦出款成功则基本不会有追回的可能，因此，资金安全是提现业务开发过程中必须考虑并保证的部分，确保每笔出款有迹可循且符合提现规则。

为解决上述问题，我们通过 RocketMQ 进行异步出款来保证用户体验，同时 RocketMQ 的使用还可以对银行卡等出款渠道进行削峰来减少下游的过高流量。在资金安全方面，每笔订单在进行春节活动收入账户扣款和现金出款时做了幂等操作，并增加对账任务对所有流水进行对账校验。

除夕当晚从 19:30 集卡活动开奖用户进入主会场即可看到集卡奖励，同时烟火大会开启参与活动即可获得红包奖励，此外从 20:00 开始到 23:00 每个整点都会有红包雨，用户会不断获得春节活动奖励并进入钱包页查看个人收入。

为保证用户集卡开奖和红包雨活动入账顺利，不会出现看到奖励但钱包中无收入或收入不足导致提现错误的问题，我们在用户进入提现页面的时候会根据端上请求参数中的红包 token 列表进行一次入账请求，以确保用户在确认提现下单前账户中的金额如果没有完成入账的话可通过 token 列表进行一次强制入账，但为给用户在提现页面有较好体验，此处的入账为弱依赖请求。当用户确认提现下单的时候，我们设置了强依赖性的强制入账作为最终兜底方案，来使得最终提现扣款时奖励金额已经入账成功并支持提现。

同时，为保证用户可以在活动结束后提现参与获得的所有奖励，减少因提现门槛导致用户参与后续玩法获得奖励较少而无法提现的情况，我们在春节活动中开启了延时放量提现。从 19 点到凌晨 1 点之间关闭提现入口，用户只能在主会场参与活动获得奖励，而无法进入钱包页面中进行提现操作。当用户在活动钱包页点击【去提现】时，会弹窗提示用户在 2 月 1 日 01:00 后可提现。此外，在弹窗中我们也加入了对用户的绑卡营销策略，引导用户预先绑卡，提现快人一步。

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

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

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

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

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

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

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

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

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

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

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