在红包补贴发放链路流程中，为了应对春节的大流量，整个链路流程也经历过几次方案的迭代。

在最初的方案设计中，我们是按照同步的补贴发放流程来处理的，上游链路调用红包系统接口发券，发券成功后用户感知到券发放成功，可以使用该券来发放红包，最初方案的整体流程如下图：

上面方案的一个问题是在春节活动期间，整个链路都需要能扛住活动期间的总流量，而且最终流量都会打到数据库，而数据库的资源在春节期间也是比较紧缺的。

为了解决同步奖励发放的问题，整体流程改为通过 MQ 进行削峰，从而降低下游的流量压力，相当于是从同步改为异步，用户参与活动后会先下发一个加密 Token 给客户端，用于客户端的展示以及和服务端的交互处理。活动异步发券方案如下图

这样解决了大流量的问题，但是相应地引入了其他的问题，在最初方案中，用户的红包补贴都会先在红包系统中落库，后续用户对补贴的查询和核销我们都能在红包数据库中找到对应的记录，但是在异步的方式中，整个补贴的入账预估需要 10min，而用户在 APP 界面感知到发券后可能马上就会开始使用用补贴来发放视频红包，或者会去红包挂件查看自己已经领取的红包补贴，而此时补贴还未在红包系统中入账。

为了解决上面问题，我们对红包补贴的视频红包发放和红包补贴查询的整个逻辑进行了修改，在用户使用红包补贴进行视频红包发放时，我们会先对该补贴进行一个入库操作，入库成功后才可以用这个补贴进行红包发放。另外对于查询接口，我们无法感知到所有补贴是否完全入账，因此每次查询时我们都需要去奖励发放端查询全量的 Token 列表，同时我们还需要查询出数据库中用户的补贴，对这两部分数据进行一次 merge 操作，才能得到全量的补贴列表。

在上面的流程中，为了解决 MQ 异步会有延迟的问题，我们在用户进行请求时主动地进行入账，而用户主动的操作包括使用补贴发放红包和查询补贴，我们为什么只在补贴发放红包时入账而在查询补贴时不入账呢？因为用户的查询行为是一个高频行为，同时涉及到批量的操作，在操作 DB 前我们无法感知该补贴是否入账，所以会涉及到 DB 的批量处理，甚至用户每次来查询时我们都需要重复这个操作，会导致大量的 DB 资源浪费。而补贴的发放时入账则是一个低频的，单个补贴的操作，我们只需要在用户核销时入账即可，这样可以大量减轻数据库的压力，节省数据库资源。

在视频红包领取的技术方案中，我们也有一些方案的选择和思考，这里和大家分享下。