春节红包架构设计

高并发问题,是每个程序员、架构师都不可避免的问题,而这类问题无非是并发量大小以及需要多么可靠的区别。在解决这类问题的时候,也遵循着「没有银弹」的法则,一个场景一个设计,不同容忍度不同可靠性。

春节期间的抢红包,这个场景是一个非常鲜活现实的场景、就在我们身边,正好旁听了某司的红包架构设计,浅谈自己的看法权当抛砖引玉。

业务需求

春节红包是一个容忍性非常高的业务场景,他可以允许用户抢不到红包、业务代码没有响应,但不能容忍数据上的不一致以及财务上的损失

所以在这里,「保证数据最终一致性」是我们的 top priority 。

理解了这一点,我们就开始自己的春节红包的架构设计。

红包金额生成

这个场景与微信群抢红包不太一致,这相当于是几亿人抢一个群红包,所以不能够动态生成金额数量。

因为超高并发场景下动态生成金额是有风险的,而且是风险极高的。若是超发红包,以 3kw QPS 的情况,这个金额是不堪想象的。

因此,结论一:

我们使用空间换时间,预先生成红包的金额与数量,不动态生成。

其好处,不仅可以提前对红包的金额的分布有所了解,也可以根据运营特殊化定制特殊红包。

红包数据存储

基于结论一,我们肯定需要有个地方存储,而且这个存储方案的选择会影响到后面的技术实现。

第一个想法,使用数据库去存储,但结论是不可能。

每个请求都要求实时的数据,每秒 3kw 请求用什么数据库都要崩,所以不可能使用数据库去抗。

第二个想法,使用 Redis 去存储,但结论是不放心。

Redis 的持久化 ADF 和 RDB 都不一定可靠,虽然说久经战场,但不能把自己的性命赌在了别人的可靠上。

第三个想法,客户端、服务端(业务层面)做存储(容灾),结论是可行的。

假设每一轮红包有 5 亿用户去争抢,那么相当于我们要做一个「10秒5亿」的发号器。

每一个号是预先生成的,只要保证同一个号一个用户,那么这就是可以接受的。

于是这个号就会存储在客户端和服务端,做双端冗余(容灾)。当然,这里的每个号必然是无规律,并且有着特殊签名校验的。

所以,结论二:

不完全依赖数据库、Redis,业务实现超高并发的发号器。

高并发的发号

我们知道,当并发量大的时候,如果代码处理的不好,那么就有很大的几率出现「一号多人」的情况。

有几率发生的事情,总是会发生。

所以我们就要想一个办法,让这件事情不可能发生。于是我们就想到了 Golang 的 Channel 的机制,原生就可以帮助我们实现 exactly once 的效果。

这个号一旦从 channel 取出,那么就不会再被第二个人获取。

所以,结论三:

业务上基于 Golang 的 Channel 机制,保证每个号的使用是唯一的。

最终设计

我们会对每一轮的红包数量进行估计,在每台实例上预先生成那么多红包(Token)。

在这里,每一个 Token 就是一个红包,Token 保存着红包的唯一 ID 以及红包的基础信息(以分为单位的金额、展示的广告、校验码)。

然后这些信息通过压缩、AES(对称)加密后,变成一个 60 位的 Token。

1
<Red_Packet_ID>|<Money_Amount>#<Ad_ID>#<Nounce>#<Checksum>

为什么要将红包的信息存放在 token 里面呢?

这就和我们的结论二有关,客户端和服务端进行双端冗余,而且解密这个 Token 不强依赖于数据库或者缓存,直接在 API 层就可以将红包进行拆包。

然后使用 Golang 的 Channel 机制,确保红包只会被使用一次,不会出现「一个红包多个人」的情况。

上面的设计就保证了「发红包」的最终一致性,而且我们在「发」的同时,将获取红包的设备 ID 异步写到「发红包」实例的日志中。

这样就保证我们可以知道红包发给了哪个设备,若是有用户反馈,我们就可以根据这个记录反查到红包路径。

因为 Token 中存有着红包的信息,所以「拆红包」的时候只要 API 层将根据 AES 的密钥进行解密即可,不依赖于任何存储。

于是,我们只需要将拆包的用户 ID 异步写到实例的日志中,并将这个用户 ID 和红包 Token 塞入队列中,异步入账及核对。

至此我们就扛过了 5s 每秒 3kw+ 请求的春节红包。

总结

最后总结一下让人眼前一亮的地方:

  • Token 即红包,预先生成、双端冗余、业务容灾
  • Golang Channel 保证每个红包只消费一次,保证不会重复
  • 拆包不强依赖其他组件,解密 Token 即结果
  • 异步入账,用户抢、拆体验流畅,钱包延迟展示

至于安全问题,每个服务器一个 AES 密钥、Nounce 字符串、MD5 校验,以及发、拆日志记录,无论是核账还是薅羊毛都没有太大的问题。

更多的实现细节就不做讨论,权当抛砖引玉、学习别人的架构设计,不断地提升自己。