微信红包系统设计方案

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

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

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

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

• 使用乐观锁替代悲观锁

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

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

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

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

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