如何搭建一个红包架构?
做技术将来想做架构师，就要多见多想，大家都有过使用微信红包的经验，如何做一个能够承受高并发的红包架构是一个值得探讨的问题。
微信金额什么时候算？
微信的金额是拆出来时候实时算的，不是预先分配的，采用纯内存计算，不需要预先空间存储。
注：京东金融的红包是预先算出来放到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操作。另外还有对账来保护。
注：还需要一个对账验证最终一致性。
文章分享自微信公众号：
春哥talk
登录 后参与评论
0 条评论
相关文章
精选专题
活动推荐
关注
腾讯云开发者公众号
将获得
10元无门槛代金券
洞察腾讯核心技术
剖析业界实践案例
腾讯云开发者
扫码关注腾讯云开发者
领取腾讯云代金券