如何搭建一个红包架构?

做技术将来想做架构师，就要多见多想，大家都有过使用微信红包的经验，如何做一个能够承受高并发的红包架构是一个值得探讨的问题。

微信金额什么时候算？

微信的金额是拆出来时候实时算的，不是预先分配的，采用纯内存计算，不需要预先空间存储。

注：京东金融的红包是预先算出来放到CDN上，后期抢红包的行为主要是分配红包ID的行为。所以这样看来京东红包还是取巧了。

实时性：明明抢到了红包，点开后发现没有？

2015年以后红包的拆和抢是分离的，需要点两次，会出现抢到红包，点开之后红包领完的情况。

注：每个业务逻辑的拆分都可以很大程度上缓解一些技术的压力与问题。

红包金额如何分配？为什么出现红包金额相差较大问题？

随机分配的。额度在0.01和剩余平均值*2之间。

例如：发100块钱，总共10个红包，平均值是10元，发出的红包额度在0.01----102之间波动。 当前面红包总共被领了40块钱的时候，剩下的60块钱，总共7个红包，这7个额度在0.01-(60/7)=17.17之间。

每被抢一次红包重复一下上面的计算。

注：不知道为啥这样随机。

红包的设计

微信系统从财付通拉取金额数据，生成个数/红包类型/金额放到redis集群中，app端将红包id的请求放入请求队列中，如果发现请求个数超过红包个数，直接返回。

依据红包逻辑处理成功得到令牌请求，供财付通进行一致性调用，类似于比特币两边保存交易记录，交易后交给第三方服务审计，如果交易过程中出现不一致情况会强制回归。

主：这里类似于秒杀系统的设计，通过redis前端的原子计数过滤无效请求，通过队列排队用户请求，阈值以redis库存为主。

红包如何计算被抢完？

cache会抵抗无效的请求，将无效请求过滤掉，实际进入到后台的量不大。cache记录红包个数，原子操作进行个数递减，到0表示被抢光。财付通按照20w/笔每秒入账准备。

注：这里处理类似于秒杀系统用户请求，仓储库存处理的解决方案。

如何保持8w每秒写入？

多主sharding，水平扩展机器。

数据容量多少？

一个红包只占一条记录，有效期只有几天，一次不需要太多空间。

询红包分配的压力

抢到红包的人数和红包都记录在一条cache记录上，没有太大的查询压力。

一个红包一个队列？

没有队列，一个红包一条数据，数据上有一个计数器字段。

注：上面到这里笔者提到过很多次redis原子计数器操作，所以大家要了解一下这个，目前看来这种解决方案可以出现在很多秒杀，高并发场景下解决问题。

有没有从数据上证明每个红包的概率是不是均等？

不是绝对均等，就是一个简单的拍脑袋算法。

注：有的时候产品经理提出是随机场景，最后的方案大多是拍脑袋的算法，笔者有过这个经验。

拍脑袋算法，会不会出现两个最佳？

会出现金额相同的，但是手气最佳只有一个，按照时间来。

每领一个红包就更新数据吗？

每抢到一个红包，就cas更新剩余金额和红包个数。

注：cas在计算机体系下常有两个意思： Central Authentication Service中央认证服务， 另一个compare and swap比较并交换，比较常用在多线程并发场景下的计数操作，属于原子性。

红包如何入口入账？

数据库会累加已经领取的个数与金额，插入一条领取记录，入账是后台的异步操作。

注：还是标准的流水做对账，异步处理。

入账出错怎么办？比如红包个数没了，但是余额还有？

最后会有一个talk all操作。另外还有对账来保护。

注：还需要一个对账验证最终一致性。