红包系统是后端并发场景里最典型的练习题。它不是单一的接口优化，而是从发红包、抢红包、拆红包到余额入账一整条链路都要在峰值流量下保持稳定。很多人看到“千万并发”这四个字就只盯着 QPS，实际上真正要回答的问题是：突发流量打过来时，红包会不会超发，用户会不会重复领取，账目能不能对平，失败数据能不能自动补偿。
这篇文章适合后端开发、准架构师，也适合正在准备高并发面试的人。最值得关注的核心不是“把服务节点多部署几个”，而是超发控制怎么做、流量怎么削峰、异步任务怎么保证不丢不重、压测时到底看哪些指标。
下面按实际落地顺序拆一遍。
1. 先把红包系统的业务链路拆清楚，再谈并发优化
很多人把红包系统想成“一个抢红包接口”，这其实是最大的误区。真正上生产环境时，一次用户操作会被拆成多个前后关联的步骤，每一步的流量特征不一样，优化方式也不一样。
1.1 红包系统的几个核心状态
任何一个红包活动，都可以抽象成下面几个状态：
- 创建红包：用户发一个红包，系统生成红包主单，设置总金额、总个数、有效期。
- 拆分子红包：按平均金额或随机金额把总红包拆成 N 份，生成子红包记录。
- 抢红包：用户在业务入口点击“抢”，服务端判断红包是否还有剩余、用户是否已经抢过。
- 拆红包：确认当前用户能拿到哪一档金额，这一步会真的扣减剩余库存。
- 入账：把用户抢到的金额写入账户余额或零钱明细，并留下流水记录。
- 查询展示：用户查看红包详情、领取列表、手气最佳等信息。
这里面“创建红包”和“查询展示”的并发压力并不高，充其量是读多写少。真正的热点集中在“抢红包”和“拆红包”，尤其是拆红包那一刻，所有用户都往同一个红包的库存上打。只要这个点不做特殊设计，数据库行锁、缓存热 Key、接口超时就会全部爆出来。
1.2 抢和拆为什么要分开
很多初版实现会把“抢”和“拆”放在同一个接口里，用户点击一次，后端直接完成判断、扣减和入账。流量低的时候没问题，一旦进入大促画面，这个接口会同时承担两类工作：
- 高频判断：判断红包是否可抢、用户是否已抢、活动是否过期。
- 高频写操作：扣减库存、生成领取记录、更新余额。
把这两件事混在一起，会导致一个用户的失败影响另一个用户。比如库存扣减成功，但入账超时，用户界面显示“已抢到”，余额却没变。与其这样，不如把“抢”做成一个轻量级的判定动作，把“拆”和“入账”放到后续链路里执行。
在生产实践中，我一般这样做：
- 用户点击后，先通过 Redis 判断红包状态。
- 如果可抢，立刻用 Lua 脚本扣减红包库存，并把当前用户写入一个“已领取”集合。
- 返回“抢到”的即时结果。
- 同时发送一条消息到消息队列，消费者拿到消息后做异步入账。
这样做的原因是：用户侧最关心的反馈是“我到底有没有抢到”，这个反馈必须快。而真正把金额入账的动作，不需要用户盯着等，可以放到异步任务里慢慢处理。
1.3 流量模型差异决定架构选型
红包系统中存在三种完全不同的流量：
- 读流量：详情页、榜单、领取列表，属于典型读多写少，适合加缓存。
- 瞬时写流量：同一时间大量用户抢同一个红包，写集中在少数几个 Key 上。
- 异步流量：入账、对账、通知，这些任务可以排队，但不能丢。
理解了这三种流量，就能理解为什么红包系统不能只靠数据库，为什么 Redis 和消息队列是标配。
2. 防超发：为什么第一道防线要放在 Redis 里
红包系统最不能容忍的就是超发。一个 100 元的红包，最多只能发出 100 元，哪怕只多发出 0.01 元，后续对账都是事故。所以防超发不是性能问题，是资金安全问题。
2.1 数据库库存扣减为什么扛不住热点
最早期的方案通常会直接操作数据库表，用一条 update 语句做条件扣减：
update red_packet_stock set remain_amount = remain_amount - #{money} where packet_id = #{packetId} and remain_amount >= #{money}这条语句在单红包、低并发下是能用的。但红包系统的高并发场景是同一时刻几千甚至几万人同时抢同一个红包，所有这些请求都会打到同一行记录上。
数据库对这行的 update 是串行加锁的。结果就是请求大量堆积，锁等待超时，连接池被占满，最终表现就是接口大面积报错。即使你把数据库连接池调大，也只是让更多请求卡在锁上，没有真正提升吞吐。
所以红包库存的第一道防线不能只靠数据库行锁。
2.2 用 Lua 脚本保证扣减原子性
业界的常规做法是在 Redis 层维护红包的剩余金额和剩余个数，用 Lua 脚本完成判断和扣减的原子操作。
Redis 单线程执行脚本，Lua 脚本在执行期间不会被其他命令打断。这就避免了“先查询再扣减”的竞态问题。
一个简化版的思路是这样：
- 发红包时，在 Redis 里写入剩余金额 key 和剩余个数 key。
- 抢红包时，执行 Lua 脚本，检查剩余个数是否大于 0、剩余金额是否够本次发放。
- 如果条件满足，扣减金额和个数，返回成功。
Lua 脚本示意：
-- KEYS[1] 红包剩余金额 -- KEYS[2] 红包剩余个数 -- ARGV[1] 本次要发放的金额 local amount = tonumber(redis.call('get', KEYS[1]) or '0') local count = tonumber(redis.call('get', KEYS[2]) or '0') local money = tonumber(ARGV[1]) if count > 0 and amount >= money then redis.call('decrby', KEYS[1], money) redis.call('decr', KEYS[2]) return 1 end return 0这只是一个核心片段，真实实现里还要考虑子红包金额如何生成、用户是否已领取、过期时间设置等问题。
更稳妥的做法是发红包时直接把 N 个子红包的金额放进 Redis List，抢红包时用 Lua 从 List 里 pop 一条。这样就不存在“每次算金额”的问题，金额在发红包那一刻已经固定下来了。
如果使用随机红包，常见做法是二倍均值法：每次按剩余金额除以剩余个数的两倍取随机。但随机金额本身不能在高并发请求里再计算，它必须提前生成并保存好。
2.3 Redis 异常时怎么兜底
把第一道防线放在 Redis 里，很多人会担心一个问题：Redis 宕机了怎么办，预扣数据丢了怎么办。
这个担心是对的。所以红包系统不能只依赖 Redis，数据库还是要承担最终账本职责。
一个可行的兜底方案是：
- Redis 层负责高并发下的快速扣减，确保不超发。
- 数据库表负责记录每一笔领取流水，作为最终账本。
- 异步任务把 Redis 的扣减结果和数据库流水做比对。
- 如果 Redis 发生主从切换或数据丢失，可以基于数据库流水重新构建某个红包的剩余库存，再回写 Redis。
这里要先明白一点：Redis 即使出问题，也不能让用户“凭空多拿钱”。兜底逻辑的目标不是保证 Redis 24 小时不宕机，而是保证账目恢复时能对平。
所以每个红包主单必须保留创建时的完整信息，包括总金额、总个数、已经领取的钱数、已经领取的人数。这样无论 Redis 里剩多少，都可以用数据库流水计算出来。
3. 削峰限流和异步化：千万流量不是一台机器扛出来的
当瞬时流量冲到千万级，任何单点应用都会被压垮。红包系统的另一个核心设计是削峰，把“瞬时高峰”切成一段一段可处理的流量。
3.1 入口限流：先挡住无效请求
每次红包活动里，真正能抢到红包的用户只是少数，但大多数用户都会在活动开始那一刻疯狂点击。如果所有请求都穿透到业务层，甚至打到数据库，系统必然被打垮。
所以在最外层就需要做限流。
常见做法包括：
- 网关层限流：按接口维度设置令牌桶或滑动窗口，超出的请求直接返回“活动太火爆”。
- 用户维度限流：同一个用户在短时间内只能放行一次抢红包请求，其他点击直接忽略或返回重复提示。
- 接口线程池隔离：把抢红包接口和普通业务接口放到不同的线程池，避免一个高峰接口拖垮整个应用。
限流不是把正常用户挡在外面，而是把无效请求挡在外面。比如用户连续点了十次，只需要让第一次请求进入业务逻辑，剩下九次可以在网关或者前置校验里直接短路。
3.2 异步化拆分：拆红包和入账解耦
刚才提到“抢”和“拆”可以合并，也可以拆开。更彻底的做法是拆红包成功后就立刻返回，入账动作放到消息队列里异步消费。
这样做的好处是：
- 用户响应时间短，不需要等数据库写入完成。
- 高峰期的写流量可以被队列缓冲，数据库不会瞬间被打满。
- 入账失败可以进入重试队列，不影响用户抢红包的结果。
一个常见的流程是这样：
- 用户请求到达，进入抢红包接口。
- 接口检查用户是否已领取。
- 用 Lua 脚本从 Redis 里 pop 一个子红包金额。
- 写入一条领取记录，状态为“待入账”。
- 发送 MQ 消息，消息内容包含红包 ID、用户 ID、金额。
- 接口直接返回“抢到了”。
- 消费者收到消息后，把金额写入用户余额，更新领取记录状态。
这里面消费者需要注意消费速度。不要一上来就开几百个消费者线程同时写数据库。数据库写入是有瓶颈的，建议先用小批量消费者跑，观察数据库负载和消息积压情况，再逐步增加。
3.3 队列消费速率和数据库写入节奏
实际落地时，我一般会关注三个参数：
- 消息积压数：如果积压越来越多，说明消费速度跟不上生产速度。
- 数据库写入耗时：单条入账写操作如果超过 50ms，就要小心锁和 IO 问题。
- 消费失败率：失败率突然升高，通常是数据库连接异常或数据格式不对。
控制写入节奏的方式有很多，最简单的是控制消费者的并发线程数。比如先从 10 个线程开始，观察数据库 CPU 和磁盘 IO，如果负载不高再逐步加到 20 个、50 个。
也可以把多条入账消息合并成批量写。给每个用户单独生成一条明细，然后一次性批量插入，这样能明显降低数据库压力。
4. 幂等、超时和资金安全：高并发最容易翻车的地方
高并发系统还有一个隐形杀手，就是重复请求。一个用户网络不好，前端自动重试，或者网关超时重发，都可能导致同一条领取请求被处理两次。如果不做幂等，用户就会领到两笔钱。
4.1 重复请求是怎样产生的
重复请求不一定来自恶意用户，更多时候是正常网络行为：
- 用户点击后没有立刻收到结果，又点了一次。
- 客户端设置了超时重试，但第一次请求其实已经成功了。
- 网关或消息队列在消费时发生重试，导致同一条消息被消费两次。
所以幂等不是一个可选项，而是必须项。
4.2 幂等键怎么设计才稳
最简单的幂等键是“用户 ID + 红包 ID + 领取场景”。
在领取记录表里给这个组合加唯一索引。重复请求第一次插入成功，第二次插入时因为唯一索引冲突直接返回“已领取”。
这里最容易踩的坑是只靠用户 ID 做幂等。一次活动、多个红包的情况下，用户 ID 相同不代表是同一次领取，必须带上红包 ID。
还有更复杂的情况：同一个用户，在同一个红包里已经领取过，但系统异常，用户订单状态还是“待入账”。这时候即使有唯一索引，也可能出现“领取记录存在，但状态没更新”的中间态。
所以幂等不仅要防止重复插入，还要处理状态机。比如“待入账”变成“入账中”，再变成“入账成功”，整个过程要保证同一个用户同一个红包只能成功流转一次。
4.3 事务边界和对账机制
资金相关操作最怕跨事务。比如“扣减红包库存”和“增加用户余额”如果放在同一个分布式事务里，性能会很差，而且一旦一个节点失败，整个链路都会阻塞。
更稳妥的方式是采用最终一致性：
- 在本地事务里写入资金流水，并更新领取记录状态。
- 把更新余额的操作放到异步任务里。
- 异步任务执行成功后，更新流水状态。
- 定时任务扫描长时间未成功的流水，触发补偿。
这样即使某个环节失败，也可以通过流水状态找回数据。
对账机制也不能省。每天凌晨跑一次对账，把红包主单的总金额、总个数、已领取金额、已领取人数和数据库流水汇总做比对。一旦发现不一致，就触发告警，再由人工或补偿任务处理。
5. 压测验证：别在低并发下自我感动
很多人做红包系统只是把流程跑通了，就觉得自己已经“扛住高并发”。但真实环境的问题，只有在高并发压测下才会暴露。
5.1 从单机到集群的压测步骤
压测不要直接上千万并发，那是浪费资源也得不到有效结果。正确顺序应该是：
- 先单机单接口压测，确认服务的处理上限。
- 再单机混合链路压测，模拟抢红包、拆红包、入账的真实流程。
- 然后集群压测，验证负载均衡和缓存是否有效。
- 最后做全链路压测，把网关、应用、Redis、数据库、MQ 都纳入测试范围。
压测工具有很多，比如 JMeter、wrk、Locust，也可以使用公司内部的压测平台。工具不是重点，重点是测试时要尽量贴近真实请求。
建议先用少量并发跑通脚本，比如 100 并发，确认脚本参数都正常。然后逐步增加到 500、1000、2000，每次增加后观察几分钟，记录指标。
5.2 读哪些指标才能判断系统是否可靠
压测时不要只盯 TPS。TPS 再高，如果错误率很高，也没有意义。
我一般重点看这几个指标：
- P99 响应时间：99% 的请求耗时是多少，反映了用户真实体感。
- 错误率：超过 0.5% 就要认真排查，超过 1% 基本不可接受。
- Redis 的 CPU 和内存：如果 Redis 先被打爆，说明缓存设计或 Key 拆分需要优化。
- 数据库连接池占用：连接池满通常是慢 SQL 或死锁的前兆。
- MQ 积压数：如果积压持续增长，说明消费者处理速度不足。
- 线程池活跃线程数：活跃线程长期接近 maximumPoolSize，说明服务已经快承受不住了。
判断一个红包系统是否扛住了千万并发，不是看某台机器 CPU 是多少，而是看整个链路在压力下是否还能保持稳定。
5.3 压测中常见的六类问题
压测过程中最容易发现的问题，我归纳成六类：
- 热 Key 问题：所有请求都打到同一个红包的 Redis Key 上，单个 Redis 节点 CPU 被打满。
- 连接池耗尽：应用线程等待数据库连接或 Redis 连接，耗时直线上升。
- 慢 SQL：库存更新或流水插入出现锁等待。
- 消息积压：入账消费者处理不过来了。
- 日志阻塞：压测时日志量暴增，磁盘 IO 成为瓶颈。
- 反向超时：上游网关超时时间设置太短，服务还没来得及处理就被中断。
这些问题在低并发下很难复现，但一到高峰就会集中爆发。压测的目标就是提前把这些问题找出来。
6. 回到千万并发：架构选型的核心取舍
最后说回“千万并发”这个词。
真正要做到千万用户同时抢同一个红包，单靠任何一项技术都不够。Redis 解决了热点扣减问题，MQ 解决了流量削峰问题，数据库解决最终账本问题，幂等机制保证重复请求不影响资金安全，定时任务负责兜底对账。每一项都不是孤立存在的。
6.1 每个组件的职责边界
- Redis：扛住瞬时热点写流量，用 Lua 脚本保证扣减原子性。
- MQ：承接拆红包后的入账动作，把高峰写流量切成平稳消费。
- 数据库：保存红包主单、领取流水和用户余额，作为最终账本。
- 定时任务：处理超时未入账、数据不一致、对账差异。
- 缓存：承载红包详情、领取列表等读多写少的请求。
这个职责分法可以复制到大多数高并发交易场景里。
6.2 真正要盯的关键链路
如果只让你盯一条链路，那就是：扣减库存和入账是否最终一致。
扣减库存用的是 Redis 预扣，入账用的是 MQ 异步写库。这两者之间天然存在时间差。任何一个环节丢了数据，都会导致用户“扣了钱但没入账”，或者“没扣钱却拿到了钱”。
所以日志必须完整，每个用户在每个红包上的领取记录都要带上请求 ID、红包 ID、用户 ID、金额、状态和时间。压测时也要专门做“异常流量测试”，比如消费失败后重试、Redis 主从切换后恢复，观察数据是否还能对平。
6.3 给中小团队的落地建议
如果你所在团队的技术栈比较简单，没有现成的 MQ 和分布式事务组件，也不用一上来就追求最复杂的架构。
可以先做这些事：
- 抢红包接口用 Redis + Lua 做防超发。
- 领取记录表加唯一索引做幂等。
- 入账操作放到本地消息表或简单的延迟任务里异步执行。
- 每天跑一次对账任务比对红包总账和流水明细。
这套方案不能算最极致，但能把“超发”“重复领取”“账不平”这几个核心风险控制住。等流量真正起来后，再逐步引入 MQ、全链路压测和更细的监控。
红包系统的高并发设计，归根到底是取舍问题：用 Redis 换瞬时性能，用 MQ 换削峰能力，用异步任务换吞吐，用幂等和定时对账换资金安全。每一样都会增加复杂度，但每一样都在防住一类真实事故。真正落地时，最该盯住的不是功能列表，而是数据一致性、失败补偿和压测结果。
