经典系统设计题：大型抢红包系统设计

尽量不要在每个拆红包的请求中都去修改红包记录的状态（比如扣减金额），因为红包记录只有一条，只能串行的去执行，当拆分出大量红包时（比如春晚红包，几百万个），会严重影响拆红包的效率。发红包阶段，新建一张临时表，表名和红包id对应，将拆分的金额存入到表中，每个金额都有一个自增id（从1开始），假如拆分出了100个金额，那么id就是1到100，然后hash(用户id)来获取金额id从而决定金额，最简单的就

咦940

1819人浏览 · 2024-01-11 15:53:16

咦940 · 2024-01-11 15:53:16 发布

业务流程

以微信红包为例，分为如下流程：

发红包（包红包）；
抢红包；
拆红包（开红包）。

发红包

设置金额和份数，完成支付，红包详情入库，为红包生成一个唯一ID。

红包拆分

拆分时机

红包金额拆分分为实时拆分和提前拆分，实时拆分对系统性能和拆分算法要求较高，在拆分时既要保证线程安全，又要保证并发效率，开发难度较大。而且拆分过程中要一直保证后续待拆分红包的金额不能为0，不容易做到拆分的红包金额服从正态分布规律。

大型红包系统一般选择提前拆分，从而降低系统复杂度。

拆分算法

随机数

我们假设有一个100元的红包。第一个人可以在0.01元到100元之间，随机地分配到一定金额。如果我们把第一个人抽到的所有可能的金额都计算在内，并取个平均值，那么他平均能获得50元。这50元在数学上还有个形象的名字，叫作数学期望。既然是“期望”，就总会有落空的时候，也不排除会有意外的惊喜。因此，第一个人抽到的金额可能不足50元，也可能大于50元。

第二个人就只能在0.01到剩下的金额之间随机了，显然，第二个人平均能获得的金额比第一个人小，而且越到后面的人，这个平均金额越小。

也就是说，越在前面抢的人越有优势，因此，这个算法非常不公平。

二倍均值法

二倍均值法拆分的金额比较平均，属于“雨露均沾”类型。

假设红包总金额是a，红包个数为p，每个红包的最低金额是0.01元。
那么每次抢到的红包金额的范围在 [0.01, (a / p) * 2] 之间。

算法代码如下：

public class DoubleAVG {

    /**
     * 拆分金额
     * @param amount 总金额，单位：元
     * @param part 份数
     * @return
     */
    public static float[] compute(int amount, int part) {
        // 红包最低金额0.01元，乘以100以后就可以全部用整型计算，不用担心精度丢失的问题
        int amt = amount * 100;
        float[] amounts = new float[part];
        Random random = new Random();
        int maxIndex = part - 1;
        for (int i = 0; i < maxIndex; i++) {
            // 随机出来的值的范围[0, 金额 / 份数 * 2), 所以需要加1
            int packetAmount = random.nextInt(amt / part << 1) + 1;
            amounts[i] = packetAmount / 100f; // 转换为元
            amt -= packetAmount; // 剩余金额
            --part; // 剩余份数
        }
        // 最后一个红包直接赋予剩余金额
        amounts[maxIndex] = amt / 100f;

        return amounts;
    }

    public static void main(String[] args) {
        testCase();
    }

    public static void testCase() {
        int amount = 100;
        int part = 20;
        float[] amounts = compute(amount, part);
        for (float amt : amounts)
            System.out.println(amt);
    }
    
}

抢红包

抢红包是整个流程中并发最高的阶段，对系统的性能要求最高。在此阶段，至少要做如下业务校验：

红包还有没有剩余，有剩余才能抢；
已经抢过的人不能重复抢。

不能重复抢可以通过客户端交互界面限制，但是碰到直接调接口的“高端玩家”就没办法了，所以还是需要后端校验。这些请求如果全部放到数据库，可能会把数据库搞宕机，所以在这里我们需要限流。

限流

分布式锁

只有抢到锁才能抢红包，说白了就是让请求串行，但是遇到高并发，会导致大量请求排队，可能会耗尽线程资源，可以设置抢锁的等待超时时间和分段锁机制来缓解这种状况。抢到锁的请求，在通过业务校验之后，需要修改数据库里的数据（或是插入一条数据，或是修改一个标识位），表示抢到了红包。

Redis限流

设置了超时时间的分布式锁在高并发场景下会导致大量请求超时，用户体验非常不友好。相比之下，redis限流更适合这种场景。

在发红包阶段，以红包ID生成count_key（比如固定前缀 + 红包ID），红包份数作为value保存到redis，抢红包时，执行lua脚本（保证原子性），lua脚本的逻辑如下：

先判断count_key存不存在，不存在则说明红包不存在或已抢完，直接返回没抢到；
若count_key存在，接着判断份数是否等于零，若等于零，说明红包已经抢完，直接返回没抢到；
若份数大于零，接着判断该用户是否已经抢过红包，可以通过redis的set数据结构来判断，同样固定前缀+红包id作为key，记为repeat_key，用户id作为value保存到set。若用户已经抢过红包，则直接返回；
若用户还没抢过红包，则将红包份数扣减一，同时将用户id保存到set，返回抢红包成功的响应给客户端。

redis的数据全部保存在内存中，查询效率非常高，所以能支撑大量的并发，为了应对高并发，redis还可以部署集群。