微信红包的设计实践

红包功能的设计实现是一个很有趣的话题,主要的功能是P个人抢总金额M的N个红包,满足先抢的N个人能抢到红包。如果这是一个leetcode的算法题目难度应该是easy,只要保证Ni抢到的金额区间在[0.01,2倍剩余金额平均值)就能ac。
将算法带入到真实的工程实现,问题就要复杂得多,如果达到微信的量级,明显要考虑的有以下几点。

  1. 拆红包
  2. 高并发读
  3. 并发写
  4. 网络流量峰值
  5. 对账
  6. 降级
  7. 故障恢复

拆红包

拆红包有预拆包和实时拆包2种策略

预拆包策略

预拆包的策略在发红包时将金额M的红包拆分成N份,将分配好的结果放入内存队列或者cache,通过incr操作在用户抢红包时分配预算好的红包slot,预算的策略可以避免对共享资源的操作,减少了锁竞争,服务本身是无状态的,设计和实现相对简单,伸缩性较好。劣势是需要额外的存储空间,如果存在大量活跃红包或者红包份数很多时会增加成本。

实时拆包

实时拆包的策略在用户抢红包时实时拆包计算金额,这样只需要保存剩余红包数量和金额,不需要额外保存每个预拆包的红包金额。使用预拆包的策略会面临并发写的问题,如果多个拆红包的请求同时执行会导致数据不一致引起超发的问题,可以使用CAS操作实现乐观锁保证并发拆包不会出现问题。

高并发读

应对高并发读的通常思路是业务层拦截过滤无效请求,使用有效的缓存。可以使用Cache层decr功能记录请求红包的用户数,当decr到0后就拦截后面的请求直接返回,对DAO层也要增加相应的缓存减少数据库的压力。

并发写

应对并发写的通常思路是串行化和乐观锁。在用户抢红包时实时拆包计算金额,每抢到一个红包,就cas更新剩余金额和红包个数,同时在DB中记录凭证,考虑到DB的写入压力,需要做分库分表,冷热分离。

网络流量峰值

大量用户同时抢红包是否会造成网络拥塞,发红包和抢红包最好在同一个IDC。

对账

考虑到拆红包凭证和入账是异步的2套系统,以及出现故障的可能,需要定时对账保证数据的一致性。

降级

在cache故障时有限流的使用DB进行服务,在资源紧张的时候关闭掉非核心流程,在实时入账请求量过大时,延迟批量入账。

微信红包的设计实践

上一篇:微信小程序又一爆炸功能上线-云开发


下一篇:自己开发的网页在跳转至微信公众号文章后,点击微信的返回,无法返回原网页