听说你会架构设计？来，弄一个红包系统-51CTO.COM

大家好，我是小❤，一个漂泊江湖多年的 985 非科班程序员，曾混迹于国企、互联网大厂和创业公司的后台开发攻城狮。

1. 引言

当我那天拿着手机，正在和朋友们的微信群里畅聊着八卦新闻和即将到来的周末计划时，忽然一条带着喜意的消息扑面而来，消息正中间赫然写着八个大字：恭喜发财，大吉大利。

图片

抢红包！！相信大部分人对此都不陌生，自 2015 年春节以来，微信就新增了各类型抢红包功能，吸引了数以亿万级的用户参与体验，今天，我们就来聊一聊这个奇妙有趣的红包系统。

2. 概要设计

2.1 系统特点

图片

抢红包系统从功能拆分，可以分为包红包、发红包、抢红包和拆红包 4 个功能。

对于系统特性来说，抢红包系统和秒杀系统类似。

图片

每次发红包都是一次商品秒杀流程，包括商品准备，商品上架，查库存、减库存，以及秒杀开始，最终的用户转账就是红包到账的过程。

2.2 难点

相比秒杀活动，微信发红包系统的用户量更大，设计更加复杂，需要重视的点更多，主要包括以下几点。

1、高并发

海量并发请求，秒杀只有一次活动，但红包可能同一时刻有几十万个秒杀活动。

比如 2017 鸡年除夕，微信红包抢红包用户数高达 3.42 亿，收发峰值 76 万/秒，发红包 37.77 亿个。

2、安全性要求

红包业务涉及资金交易，所以一定不能出现超卖、少卖的情况。

超卖：发了 10 块钱，结果抢到了 11 块钱，多的钱只能系统补上，如此为爱发电应用估计早就下架了；
少卖：发了 10 块钱，只抢了 9 块，多的钱得原封不动地退还用户，否则第二天就接到法院传单了。

3、严格事务

参与用户越多，并发 DB 请求越大，数据越容易出现事务问题，所以系统得做好事务一致性。

这也是一般秒杀活动的难点所在，而且抢红包系统涉及金钱交易，所以事务级别要求更高，不能出现脏数据。

3. 概要设计

3.1 功能说明

抢红包功能允许用户在群聊中发送任意个数和金额的红包，群成员可以抢到随机金额的红包，但要保证每个用户的红包金额不小于 0.01 元。

图片

抢红包的详细交互流程如下：

用户接收到抢红包通知，点击通知打开群聊页面；
用户点击抢红包，后台服务验证用户资格，确保用户尚未领取过此红包；
若用户资格验证通过，后台服务分配红包金额并存储领取记录；
用户在微信群中看到领取金额，红包状态更新为“已领取”；
异步调用支付接口，将红包金额更新到钱包里。

3.2 数据库设计

红包表 redpack 的字段如下：

id：主键，红包ID
userId：发红包的用户ID
totalAmount：总金额
surplusAmount：剩余金额
total：红包总数
surplusTotal：剩余红包总数

该表用来记录用户发了多少红包，以及需要维护的剩余金额。

红包记录表 redpack_record 如下：

id：主键，记录ID
redpackId：红包ID，外键
userId：用户ID
amount：抢到的金额

记录表用来存放用户具体抢到的红包信息，也是红包表的副表。

3.3 发红包

用户设置红包的总金额和个数后，在红包表中增加一条数据，开始发红包；
为了保证实时性和抢红包的效率，在 Redis 中增加一条记录，存储红包 ID 和总人数 n；
抢红包消息推送给所有群成员。

3.4 抢红包

从 2015 年起，微信红包的抢红包和拆红包就分离了，用户点击抢红包后需要进行两次操作。

这也是为什么明明有时候抢到了红包，点开后却发现该红包已经被领取完了。

图片

抢红包的交互步骤如下：

抢红包：抢操作在 Redis 缓存层完成，通过原子递减的操作来更新红包个数，个数递减为 0 后就说明抢光了。
拆红包：拆红包时，首先会实时计算金额，一般是通过二倍均值法实现（即 0.01 到剩余平均值的 2 倍之间）。
红包记录：用户获取红包金额后，通过数据库的事务操作累加已经领取的个数和金额，并更新红包表和记录表。
转账：为了提升效率，最终的转账为异步操作，这也是为什么在春节期间，红包领取后不能立即在余额中看到的原因。

上述流程，在一般的秒杀活动中随处可见，但是，红包系统真的有这么简单吗？

当用户量过大时，高并发下的事务一致性怎么保证，数据分流如何处理，红包的数额分配又是怎么做的，接下来我们一一探讨。

4. 详细设计

由于是秒杀类设计，以及 money 分发，所以我们重点关注抢红包时的高并发解决方案和红包分配算法。

4.1 高并发解决方案

首先，抢红包系统的用户量很大，如果几千万甚至亿万用户同时在线发抢红包，请求直接打到数据库，必然会导致后端服务过载甚至崩溃。

而在这种业务量下，简单地对数据库进行扩容不仅会让成本消耗剧增，另一方面由于存在磁盘的性能瓶颈，所以大概率解决不了问题。

所以，我们将解决方案集中在减轻系统压力、提升响应速度上，接下来会从缓存、加锁、异步分治等方案来探讨可行性。

1、缓存

和大多数秒杀系统设计相似，由于抢红包时并发很高，如果直接操作 DB 里的数据表，可能触发 DB 锁的逻辑，导致响应不及时。

图片

所以，我们可以在 DB 落盘之前加一层缓存，先限制住流量，再处理红包订单的数据更新。

这样做的优点是用缓存操作替代了磁盘操作，提升了并发性能，这在一般的小型秒杀活动中非常有效！

但是，随着微信使用发&抢红包的用户量增多，系统压力增大，各种连锁反应产生后，数据一致性的问题逐渐暴露出来：

假设库存减少的内存操作成功，但是 DB 持久化失败了，会出现红包少发的问题；
如果库存操作失败，DB 持久化成功，又可能会出现红包超发的问题。

而且在几十万的并发下，直接对业务加锁也是不现实的，即便是乐观锁。

2、加锁

在关系型 DB 里，有两种并发控制方法：分为乐观锁（又叫乐观并发控制，Optimistic Concurrency Control，缩写 “OCC”）和悲观锁（又叫悲观并发，Pessimistic Concurrency Control，缩写“PCC”）。

图片

悲观锁在操作数据时比较悲观，认为别的事务可能会同时修改数据，所以每次操作数据时会先把数据锁住，直到操作完成。

乐观锁正好相反，这种策略主打一个“信任”的思想，认为事务之间的数据竞争很小，所以在操作数据时不会加锁，直到所有操作都完成到提交时才去检查是否有事务更新（通常是通过版本号来判断），如果没有则提交，否则进行回滚。

在高并发场景下，由于数据操作的请求很多，所以乐观锁的吞吐量更大一些。但是从业务来看，可能会带来一些额外的问题：

抢红包时大量用户涌入，但只有一个可以成功，其它的都会失败并给用户报错，导致用户体验极差；
抢红包时，如果第一时间有很多用户涌入，都失败回滚了。过一段时间并发减小后，反而让手慢的用户抢到了红包；
大量无效的更新请求和事务回滚，可能给 DB 造成额外的压力，拖慢处理性能。

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

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

3、异步分治

综上所述，抢红包时不仅要解决高并发问题、还得保障并发的顺序性，所以我们考虑从队列的角度来设计。

我们知道，每次包红包、发红包、抢红包时，也有先后依赖关系，因此我们可以将红包 ID 作为一个唯一 Key，将发一次红包看作一个单独的 set，各个 set 相互独立处理。

图片

这样，我们就把海量的抢红包系统分成一个个的小型秒杀系统，在调度处理中，通过对红包 ID 哈希取模，将一个个请求打到多台服务器上解耦处理。

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

从上述 set 分流我们可以看出，一台服务器可能会同时处理多个红包的操作，所以，为了保证消费者处理 DB 不被高并发打崩，我们还需要在消费队列时用缓存来限制并发消费数量。

抢红包业务消费时由于不存储数据，只是用缓存来控制并发。所以我们可以选用大数据量下性能更好的 Memcached。

除此之外，在数据存储上，我们可以用红包 ID 进行哈希分表，用时间维度对 DB 进行冷热分离，以此来提升单 set 的处理性能。

综上所述，抢红包系统在解决高并发问题上采用了 set 分治、串行化队列、双维度分库分表等方案，使得单组 DB 的并发性能得到了有效提升，在应对数亿级用户请求时取得了良好的效果。

4.2 红包分配算法

抢红包后，我们需要进行拆红包，接下来我们讨论一下红包系统的红包分配算法。

红包金额分配时，由于是随机分配，所以有两种实现方案：实时拆分和预先生成。

1、实时拆分

实时拆分，指的是在抢红包时实时计算每个红包的金额，以实现红包的拆分过程。

这个对系统性能和拆分算法要求较高，例如拆分过程要一直保证后续待拆分红包的金额不能为空，不容易做到拆分的红包金额服从正态分布规律。

2、预先生成

预先生成，指的是在红包开抢之前已经完成了红包的金额拆分，抢红包时只是依次取出拆分好的红包金额。

这种方式对拆分算法要求较低，可以拆分出随机性很好的红包金额，但通常需要结合队列使用。

3、二倍均值法

综合上述优缺点考虑，以及微信群聊中的人数不多（目前最高 500 人），所以我们采用实时拆分的方式，用二倍均值法来生成随机红包，只满足随机即可，不需要正态分布。

故可能出现很大的红包差额，但这更刺激不是吗🐶

使用二倍均值法生成的随机数，每次随机金额会在 0.01 ~ 剩余平均值*2 之间。

假设当前红包剩余金额为 10 元，剩余个数为 5，10/5 = 2，则当前用户可以抢到的红包金额为：0.01 ~ 4 元之间。

4、算法优化

用二倍均值法生成的随机红包虽然接近平均值，但是在实际场景下：微信红包金额的随机性和领取的顺序有关系，尤其是金额不高的情况下。

于是，小❤耗费 “巨资” 在微信群发了多个红包，得出了这样一个结论：如果发出的红包总额 = 红包数*0.01 + 0.01，比如：发了 4 个红包，总额为 0.05，则最后一个人领取的红包金额一定是 0.02。

图片

无一例外：

图片

所以，红包金额算法大概率不是随机分配，而是在派发红包之前已经做了处理。比如在红包金额生成前，先生成一个不存在的红包，这个红包的总额为 0.01 * 红包总数。

而在红包金额分配的时候，会对每个红包的随机值基础上加上 0.01，以此来保证每个红包的最小值不为 0。

所以，假设用户发了总额为 0.04 的个数为 3 的红包时，需要先提取 3*0.01 到 "第四个" 不存在的红包里面，于是第一个人抢到的红包随机值是 0 ~ (0.04-3*0.01)/3。

由于担心红包超额，所以除数的商是向下取二位小数，0 ~ (0.04-3*0.01)/3 ==> (0 ~ 0) = 0，再加上之前提取的保底值 0.01，于是前两个抢到的红包金额都是 0.01。最后一个红包的金额为红包余额，即 0.02。

算法逻辑用 Go 语言实现如下：

import (
   "fmt"
   "math"
   "math/rand"
   "strconv"
)

type RedPack struct {
    SurplusAmount float64 // 剩余金额
     SurplusTotal int // 红包剩余个数
}

// 取两位小数
func remainTwoDecimal(num float64) float64 {
    numStr := strconv.FormatFloat(num, 'f', 2, 64)
    num, _ = strconv.ParseFloat(numStr, 64)
    return num
}

// 获取随机金额的红包
func getRandomRedPack(rp *RedPack) float64 {
    if rp.SurplusTotal <= 0 {
        // 该红包已经被抢完了
        return 0
    }

    if rp.SurplusTotal == 1 {
        return remainTwoDecimal(rp.SurplusAmount + 0.01)
    }

       // 向下取整
    avgAmount := math.Floor(100*(rp.SurplusAmount/float64(rp.SurplusTotal))) / float64(100)
    avgAmount = remainTwoDecimal(avgAmount)

       // 生成随机数种子
    rand.NewSource(time.Now().UnixNano())

    var max float64
    if avgAmount > 0 {
        max = 2*avgAmount - 0.01
    } else {
        max = 0
    }
    money := remainTwoDecimal(rand.Float64()*(max) + 0.01)

    rp.SurplusTotal -= 1
    rp.SurplusAmount = remainTwoDecimal(rp.SurplusAmount + 0.01 - money)

    return money
}

// 实现主函数
func main() {
    rp := &RedPack{
        SurplusAmount: 0.06,
        SurplusTotal:  5,
    }
    rp.SurplusAmount -= 0.01 * float64(rp.SurplusTotal)
    total := rp.SurplusTotal
    for i := 0; i < total; i++ {
        fmt.Println(getRandomRedPack(rp))
    }
}

打印结果：

0.01、0.01、0.01、0.01、0.02

喜大普奔，符合预期！

5. 总结

设计一个红包系统不仅要考虑海量用户的并发体验和数据一致性，还得保障用户资金的安全。

这种技术难点，对于传统的 “秒杀系统” 有过之而无不及。