方案一Redis 预分配 MQ 异步入库红包拆分算法二倍均值法为了避免高并发时实时计算产生性能瓶颈红包金额通常在发红包时就提前计算好存储在队列中。最常用的拆分算法是二倍均值法。公式每次随机金额 [0.01,剩余金额剩余人数×2)[0.01, \frac{剩余金额}{剩余人数} \times 2)[0.01,剩余人数剩余金额​×2)优点保证每个人随机到的平均概率是相等的且不会出现某个人一把把钱抓光的情况高并发架构设计面对瞬时的高并发流量绝对不能直接读写数据库MySQL。我们需要利用 Redis 队列 数据库异步持久化 的方案发红包写操作用户发了一个 100 元、10 个人的红包后端通过“二倍均值法”生成 10 个随机数字例如8, 12, 5, …将这 10 个金额放入 Redis 的 List 结构中同时在 Redis 中设置一个计数器Counter 10和一个红包元数据TotalAmount 100将红包记录写入 MySQL状态为进行中抢红包高并发读写第一步先看有没有利用 Redis 计数器减 1使用 DECR 命令把红包个数减 1。如果返回值 0说明红包已经抢光了直接返回“手慢了”请求不往下走保护后续系统第二步拿金额利用 Redis List使用 LPOP 从 Redis List 中弹出一个金额第三步异步入库利用消息队列 MQ抢到金额后不要直接写数据库。把“用户 A 抢到红包 X金额 Y”的信息发送到消息队列Kafka/RocketMQ。消费端异步拉取消息批量更新 MySQL 中的红包明细表和用户钱包表方案二分段存储如果所有线程都去争抢同一条红包记录数据库会出现严重的行锁竞争Hotspot。为了解决这个问题我们可以引入分段锁的概念类似于 Java 中 ConcurrentHashMap 的早期实现我们在发红包时在数据库里把一个大红包拆成多个“子红包池”。-- 红包分段表 (RedEnvelope_Segment)CREATETABLEred_envelope_segment(idINTPRIMARYKEY,parent_envelope_idINT,-- 主红包IDsegment_indexINT,-- 分段序号例如 0, 1, 2, 3remaining_amountDECIMAL(10,2),-- 该段剩余金额remaining_countINT,-- 该段剩余个数versionINT-- 用于乐观锁);扣减逻辑随机分段 乐观锁/悲观锁当用户请求通过应用层队列进入数据库操作时随机路由用户 UID 对分段数取模例如 UID % 4路由到指定的 segment_index。这样原本抢同一个红包的流量被平均分流到了 4 条不同的数据库行记录上行锁竞争瞬间降低到 1/4扣减金额二倍均值实时计算读取该分段的剩余金额和个数在内存中计算出本次抽到的金额更新数据库方式 A乐观锁适合冲突稍低的段UPDATEred_envelope_segmentSETremaining_amountremaining_amount-X,remaining_countremaining_count-1,versionversion1WHEREid#{id} AND version #{version} AND remaining_count 0;如果更新失败说明被别人捷足先登可以尝试重试Retry或者直接路由到下一个 segment方式 B悲观锁适合冲突高的段使用 SELECT … FOR UPDATE 锁住该行计算金额后直接更新。因为有了前面的应用层排队和分段这里的锁冲突已经完全在数据库的可承受范围内某个段先抢完了但是其他段还有剩余如何处理这是一个很好的边缘场景。我们可以引入“段跳转Segment Hopping”机制。当用户路由到 Segment 1 发现 remaining_count 0 时代码中不直接返回失败而是顺延尝试 Segment 2、Segment 3。只有当所有 Segment 都为空时才真正返回“红包已领完”。因为此时并发已经被过滤得差不多了这种数据库轮询不会造成太大的压力