微信红包系统设计方案

Table of Contents

1 微信红包两大业务特点

  • 比普通商品秒杀有更高的并发要求
  • 更严格的安全级别,传统的秒杀库存是运营预设,并且存在超卖情况

2 传统的秒杀系统架构设计

一般由接入层、逻辑服务层、存储层与缓存构成。

3 解决高并发问题通常使用的方案

  • 使用内存操作替代实时的DB事务操作,然后异步持久化入库

这种方案的优点是用内存操作替代磁盘操作,提高并发性能。但缺点是,存在内存操作成功DB持久化失败,或内存cache故障,DB持久化会丢数据。

  • 使用乐观锁替代悲观锁

商品秒杀系统中,乐观锁的具体应用方法,在DB的库存记录中维护一个版本号。在更新库存的操作进行前,先去DB获取当前版本号。然后在事务提交时,检查该版本号是否已被其他事务修改。如果没有修改则提交,且版本号加1。否则回滚事务,并给上层报错。

如果使用传统方案,则会存在以下三个问题:

  1. 如果拆红包采用乐观锁,那么在并发抢到相同版本号的拆红包请求中,只有一个能拆红包成功,其他的请求将事务回滚并返回失败,给用户报错,用户体验完全不可接受。
  2. 如果采用乐观锁,将会导致第一时间同时拆红包的用户有一部分直接返回失败,反而那些“手慢”的用户,有可能因为并发减小后拆红包成功,这会带来用户体验上的负面影响。
  3. 如果采用乐观锁的方式,会带来大数量的无效更新请求、事务回滚,给 DB 造成不必要的额外压力。

4 微信红包系统的高并发解决方案

  1. 系统垂直 SET 化,分而治之。 所谓set化,其实就是根据一定规则(比如取模运算)将流量路由到某一组指定服务去。
  2. 逻辑 Server 层将请求排队,解决 DB 并发问题。 事务串行化,使用FIFO(先进先出)的队列设计。
  3. 双维度库表设计,保障系统性能稳定。 虽然已经使用多库多表,但随着单表数量的逐渐增加,DB性能会有大幅下降。所以采用冷热分离,将历史冷数据与当前热数据分开存储,可以有效避免该问题。即在系统以ID维度分库表的基础上,增加了以循环天分表的维度。

link-source: https://www.infoq.cn/article/2017hongbao-weixin