微信抢红包的设计

抢红包

一个“秒杀”活动，对应 DB 中的一条库存记录。当用户进行商品“秒杀”时，系统的主要逻辑在于 DB 中库存的操作上。一般来说，对 DB 的操作流程有以下三步：

1. 锁库存
2. 插入“秒杀”记录
3. 更新库存

“秒杀”系统的设计难点就在这个事务操作上。商品库存在 DB 中记为一行，大量用户同时“秒杀”同一商品时，第一个到达 DB 的请求锁住了这行库存记录。在第一个事务完成提交之前这个锁一直被第一个请求占用，后面的所有请求需要排队等待。同时参与“秒杀”的用户越多，并发进 DB 的请求越多，请求排队越严重。因此，并发请求抢锁，是典型的商品“秒杀”系统的设计难点。

微信红包业务相比普通商品“秒杀”活动，具有海量并发、高安全级别要求的特点。在微信红包系统的设计上，除了并发请求抢锁之外，还有以下两个突出难点：

首先，事务级操作量极大。上文介绍微信红包业务特点时提到，普遍情况下同时会有数以万计的微信群在发红包。这个业务特点映射到微信红包系统设计上，就是有数以万计的“并发请求抢锁”同时在进行。这使得 DB 的压力比普通单个商品“库存”被锁要大很多倍。

其次，事务性要求严格。微信红包系统本质上是一个资金交易系统，相比普通商品“秒杀”系统有更高的事务级别要求。

使用内存操作替代实时的 DB 事务操作

如图 所示，将“实时扣库存”的行为上移到内存 Cache 中操作，内存 Cache 操作成功直接给 Server 返回成功，然后异步落 DB 持久化。

这个方案的优点是用内存操作替代磁盘操作，提高了并发性能。

但是缺点也很明显，在内存操作成功但 DB 持久化失败，或者内存 Cache 故障的情况下，DB 持久化会丢数据，不适合微信红包这种资金交易系统。

悲观锁

悲观锁，假定会发生并发冲突，在你开始改变此对象之前就将该对象给锁住，直到更改之后再释放锁。
其实，悲观锁是一种利用数据库内部机制提供的锁的方法，也就是对更新的数据进行加锁。这样在并发期间一旦有一个事务持有了数据库记录的锁，其他的线程将不能再对数据进行更新了，这就是悲观锁的实现方式。

悲观锁的实现方式: SQL + FOR UPDATE

1    <!--悲观锁-->
2    <select id="getRedPacketForUpdate" parameterType="int" resultType="com.demo.entity.RedPacket">
3        select id, user_id as userId, amount, send_date as sendDate, total, unit_amount as unitAmount,
4        stock, version, note
5        from t_red_packet
6        where
7        id = #{id} for update
8    </select>

根据加锁的粒度，当对主键查询进行加锁时，意味着将持有对数据库记录的行更新锁（因为这里使用主键查询，所以只会对行加锁。如果使用的是非主键查询，要考虑是否对全表加锁的问题，加锁后可能引发其他查询的阻塞〉，那就意味着在高并发的场景下，当一条事务持有了这个更新锁才能往下操作，其他的线程如果要更新这条记录，都需要等待，这样就不会出现超发现象引发的数据一致性问题了。

对于悲观锁来说，当一条线程抢占了资源后，其他的线程将得不到资源，那么这个时候， CPU 就会将这些得不到资源的线程挂起，挂起的线程也会消耗CPU 的资源，尤其是在高井发的请求中。

一旦线程l 提交了事务，那么锁就会被释放，这个时候被挂起的线程就会开始竞争资源，那么竞争到的线程就会被CPU 恢复到运行状态，继续运行。

于是频繁挂起，等待持有锁线程释放资源，一旦释放资源后，就开始抢夺，恢复线程，周而复始直至所有红包资源抢完。试想在高并发的过程中，使用悲观锁就会造成大量的线程被挂起和恢复，这将十分消耗资源，这就是为什么使用悲观锁性能不佳的原因。有些时候，我们也会把悲观锁称为独占锁，毕竟只有一个线程可以独占这个资源，或者称为阻塞锁，因为它会造成其他线程的阻塞。无论如何它都会造成并发能力的下降，从而导致CPU频繁切换线程上下文，造成性能低下。为了克服这个问题，提高并发的能力，避免大量线程因为阻塞导致CPU进行大量的上下文切换，程序设计大师们提出了乐观锁机制，乐观锁已经在企业中被大量应用了。

乐观锁

所谓乐观锁，它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。

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

这个方案解决了“并发请求抢锁”的问题，可以提高 DB 的并发处理能力。

 1    <!--乐观锁-->
 2    <update id="decreaseRedPacketByVersion">
 3        update t_red_packet
 4        set
 5          stock = stock - 1,
 6          version = version + 1
 7        where
 8          id = #{id}
 9        and version = #{version}
10    </update>

但是如果应用于微信红包系统，则会存在下面三个问题：

1. 如果拆红包采用乐观锁，那么在并发抢到相同版本号的拆红包请求中，只有一个能拆红包成功，其他的请求将事务回滚并返回失败，给用户报错，用户体验完全不可接受。

2. 如果采用乐观锁，将会导致第一时间同时拆红包的用户有一部分直接返回失败，反而那些“手慢”的用户，有可能因为并发减小后拆红包成功，这会带来用户体验上的负面影响。

3. 如果采用乐观锁的方式，会带来大数量的无效更新请求、事务回滚，给 DB 造成不必要的额外压力。

因此，在高并发的情景下，由于版本不一致的问题，存在大量红包争抢失败的问题。为了提高抢红包的成功率，我们加入重入机制。

重入机制
按时间戳重入(比如100ms时间内)

1        // 记录开始的时间
2        long start = System.currentTimeMillis();        // 无限循环，当抢包时间超过100ms或者成功时退出
3        while(true) {            // 循环当前时间
4            long end = System.currentTimeMillis();            // 如果抢红包的时间已经超过了100ms,就直接返回失败
5            if(end - start > 100) {                return FAILED;
6            }
7            ....
8
9        }

按次数重入(比如3次机会之内)

 1        // 允许用户重试抢三次红包
 2        for(int i = 0; i < 3; i++) {            // 获取红包信息, 注意version信息
 3            RedPacket redPacket = redPacketDao.getRedPacket(redPacketId);            // 如果当前的红包大于0
 4            if(redPacket.getStock() > 0) {                // 再次传入线程保存的version旧值给SQL判断，是否有其他线程修改过数据
 5                int update = redPacketDao.decreaseRedPacketByVersion(redPacketId, redPacket.getVersion());                // 如果没有数据更新，说明已经有其他线程修改过数据，则继续抢红包
 6                if(update == 0) {                    continue;
 7                }
 8            ....
 9            }
10            ...
11        }

这样就可以消除大量的请求失败，避免非重入的时候大量请求失败的场景。

Redis

我们知道当数据量非常大时，频繁的存取数据库，对于数据库的压力是非常大的。这时我们可以采用缓存技术，利用Redis的轻量级、便捷、快速的机制解决高并发问题。

如何解决数据不一致带来的超发问题——分布式锁

通俗的讲，分布式锁就是说，缓存中存入一个值(key-value)，谁拿到这个值谁就可以执行代码。
在并发环境下，我们通过锁住当前的库存，来确保数据的一致性。直到信息存入缓存、库存-1之后，我们再重新释放锁。

为了防止死锁的发生，可以设置锁的过期时间来解决。

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

悲观锁使用了数据库的锁机制，可以消除数据不一致性，对于开发者而言会十分简单，但是，使用悲观锁后，数据库的性能有所下降，因为大量的线程都会被阻塞，而且需要有大量的恢复过程，需要进一步改变算法以提高系统的井发能力。

使用乐观锁有助于提高并发性能，但是由于版本号冲突，乐观锁导致多次请求服务失败的概率大大提高，而我们通过重入（按时间戳或者按次数限定）来提高成功的概率，这样对于乐观锁而言实现的方式就相对复杂了，其性能也会随着版本号冲突的概率提升而提升，并不稳定。使用乐观锁的弊端在于， 导致大量的SQL被执行，对于数据库的性能要求较高，容易引起数据库性能的瓶颈，而且对于开发还要考虑重入机制，从而导致开发难度加大。

使用Redis去实现高并发，消除了数据不一致性，并且在整个过程中尽量少的涉及数据库。但是这样使用的风险在于Redis的不稳定性，因为其事务和存储都存在不稳定的因素，所以更多的时候，建议使用独立Redis服务器做高并发业务，一方面可以提高Redis的性能，另一方面即使在高并发的场合，Redis服务器岩机也不会影响现有的其他业务，同时也可以使用备机等设备提高系统的高可用，保证网站的安全稳定。

综合上面的分析，微信红包系统针对相应的技术难点，采用了下面几个方案，解决高并发问题。

1. 系统垂直 SET 化，分而治之

微信红包用户发一个红包时，微信红包系统生成一个 ID 作为这个红包的唯一标识。接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等操作，都根据这个 ID 关联。

红包系统根据这个红包 ID，按一定的规则（如按 ID 尾号取模等），垂直上下切分。切分后，一个垂直链条上的逻辑 Server 服务器、DB 统称为一个 SET。

各个 SET 之间相互独立，互相解耦。并且同一个红包 ID 的所有请求，包括发红包、抢红包、拆红包、查详情详情等，垂直 stick 到同一个 SET 内处理，高度内聚。通过这样的方式，系统将所有红包请求这个巨大的洪流分散为多股小流，互不影响，分而治之，如下图所示。

这个方案解决了同时存在海量事务级操作的问题，将海量化为小量。

2. 逻辑 Server 层将请求排队，解决 DB 并发问题

红包系统是资金交易系统，DB 操作的事务性无法避免，所以会存在“并发抢锁”问题。但是如果到达 DB 的事务操作（也即拆红包行为）不是并发的，而是串行的，就不会存在“并发抢锁”的问题了。

按这个思路，为了使拆红包的事务操作串行地进入 DB，只需要将请求在 Server 层以 FIFO（先进先出）的方式排队，就可以达到这个效果。从而问题就集中到 Server 的 FIFO 队列设计上。

微信红包系统设计了分布式的、轻巧的、灵活的 FIFO 队列方案。其具体实现如下：

首先，将同一个红包 ID 的所有请求 stick 到同一台 Server。

上面 SET 化方案已经介绍，同个红包 ID 的所有请求，按红包 ID stick 到同个 SET 中。不过在同个 SET 中，会存在多台 Server 服务器同时连接同一台 DB（基于容灾、性能考虑，需要多台 Server 互备、均衡压力）。

为了使同一个红包 ID 的所有请求，stick 到同一台 Server 服务器上，在 SET 化的设计之外，微信红包系统添加了一层基于红包 ID hash 值的分流，如下图所示。

其次，设计单机请求排队方案。

将 stick 到同一台 Server 上的所有请求在被接收进程接收后，按红包 ID 进行排队。然后串行地进入 worker 进程（执行业务逻辑）进行处理，从而达到排队的效果，如下图所示。

最后，增加 memcached 控制并发。

为了防止 Server 中的请求队列过载导致队列被降级，从而所有请求拥进 DB，系统增加了与 Server 服务器同机部署的 memcached，用于控制拆同一个红包的请求并发数。

具体来说，利用 memcached 的 CAS 原子累增操作，控制同时进入 DB 执行拆红包事务的请求数，超过预先设定数值则直接拒绝服务。用于 DB 负载升高时的降级体验。

通过以上三个措施，系统有效地控制了 DB 的“并发抢锁”情况。

3. 双维度库表设计，保障系统性能稳定

红包系统的分库表规则，初期是根据红包 ID 的 hash 值分为多库多表。随着红包数据量逐渐增大，单表数据量也逐渐增加。而 DB 的性能与单表数据量有一定相关性。当单表数据量达到一定程度时，DB 性能会有大幅度下降，影响系统性能稳定性。采用冷热分离，将历史冷数据与当前热数据分开存储，可以解决这个问题。

处理微信红包数据的冷热分离时，系统在以红包 ID 维度分库表的基础上，增加了以循环天分表的维度，形成了双维度分库表的特色。

具体来说，就是分库表规则像 db_xx.t_y_dd 设计，其中，xx/y 是红包 ID 的 hash 值后三位，dd 的取值范围在 01~31，代表一个月天数最多 31 天。

通过这种双维度分库表方式，解决了 DB 单表数据量膨胀导致性能下降的问题，保障了系统性能的稳定性。同时，在热冷分离的问题上，又使得数据搬迁变得简单而优雅。

综上所述，微信红包系统在解决高并发问题上的设计，主要采用了 SET 化分治、请求排队、双维度分库表等方案，使得单组 DB 的并发性能提升了 8 倍左右，取得了很好的效果。