红包系统

需求分析

包红包：

• 系统为每个红包设置一个 ID ，然后将红包发送个用户。
  • 这里需要设置 红包金额，红包个数，要发送的用户，存储这些信息。

发红包：

• 设置完红包参数后，微信支付，完成付款，然后收到付款成功通知，红包系统更新红包订单状态，更新为已支付，并写入红包发送记录表。
• 这样用户可以将用户的红包信息和红包的收发记录发出，红包系统调用微信通知，将红包信息发送到微信群。

抢红包：

• 微信群用户收到红包后，点开，红包系统会校验红包是否被抢完，是否过期。

拆红包：

• 拆红包时，要先查询红包订单，判断是否可拆，计算本次拆的红包金额，记录抢红包流水。

拆红包过程是主要的业务逻辑，主要包含3步骤：

锁库存，插入秒杀记录，更新库存。

拆红包过程：

扣减库存和秒杀记录的操作，更新库存就是更新红包发送的订单，还有就是写入秒杀记录就是写入红包领取的信息流水。

还需要以用户为中心记录用户整体领了多少红包。

最后调用支付系统将拆红包后的金融转入用户余额，成功之后更新抢红包的订单状态为转账成功。

为提高性能，往往将库存信息放到内存 Cache 中, 内存 Cache 操作成功后给 Server 返回成功，然后异步落 DB 持久化。

微信红包设计

微信红包用户发一个红包时，有一个系统 ID ，作为这个红包的唯一标识，接着有 包，发 ，抢，拆 都与 ID 关联。

红包系统根据 ID，按照一定规则，垂直上下切分，切分后一个垂直链条上的逻辑 Server 服务器。

包含一个DB，同一个红包 ID 的所有请求均路由到同一个 Set 内处理。

同个红包 ID 的所有请求，按照红包 ID 路由到同一个 Set ，一个逻辑 Server 会存在多个 Server 。

• 但是 这些 Server 共享同一个 DB。

把海量的抢红包系统分成一个个的小型秒杀系统。

在调度处理中，通过对红包 ID 哈希取模，将一个个请求打到多台服务器上解耦处理。

然后，为了保证每个用户抢红包的先后顺序，把一个红包相关的操作串行起来，放到一个队列里面，依次消费。

一台服务器可能会同时处理多个红包的操作：

• 所以，为了保证消费者处理 DB 不被高并发打崩，还需要在消费队列时用缓存来限制并发消费数量。

抢红包业务消费时由于不存储数据，只是用缓存来控制并发。

• 所以可以选用大数据量下性能更好的Memcached。

除此之外，在数据存储上，可以用红包 ID 进行哈希分表，用时间维度对 DB 进行冷热分离。

红包加锁

从业务来看，加锁可能会带来一些额外的问题：

• 抢红包时大量用户涌入，但只有一个可以成功，其它的都会失败并给用户报错，导致用户体验极差。

• 抢红包时，如果第一时间有很多用户涌入，都失败回滚了，过一段时间并发减小后，反而让手慢的用户抢到了红包。

• 大量无效的更新请求和事务回滚，可能给 DB 造成额外的压力，拖慢处理性能。

总的来说，乐观锁适用于数据竞争小，冲突较少的业务场景，而悲观锁也不适用于高并发场景的数据更新。

因此对于抢红包系统来说，加锁是非常不适合的。