获课：shanxueit.com/12891/

秒杀系统的最后一道防线：Redis集群如何扛住百万级并发，瓦解雪崩危机

秒杀，是互联网系统最残酷的"成人礼"。当百万用户在同一秒疯狂点击"立即抢购"，数据库瞬间被击穿，缓存大面积失效，整个服务链轰然倒塌——这样的悲剧，在每年的双十一、春运抢票、限量发售现场反复上演。

能扛住秒杀的系统，没有一个把数据库当作"主战场"。 真正的底牌，是一套经过严苛打磨的Redis集群。它不仅承载着库存扣减的核心逻辑，更承载着防止缓存雪崩、穿透、击穿的防御使命。

单体Redis的"天花板"——为什么必须上集群

单个Redis实例，即使配置再高，面对百万级QPS也注定力不从心。CPU单核瓶颈、网络带宽上限、内存容量约束，这三座大山让单体Redis在秒杀场景下不堪一击。

Redis集群的核心思想，就是分而治之。 通过一致性哈希槽（Hash Slot）机制，将全部数据分散到多个节点上。一个标准的三主三从集群，写请求被均匀打散到三个主节点，每个主节点再挂载一个从节点做热备。读写分离的架构下，读流量可以被多个从节点分担，写流量则由多个主节点并行处理。

集群带来的另一个关键收益是水平扩展能力。当业务增长到当前集群扛不住时，只需增加新的主节点，系统自动完成槽位的重新分配，数据平滑迁移，整个过程对上游调用方几乎无感知。

数据分片的智慧——让每个请求都找到"对的门"

Redis集群的数据分布，依赖 CRC16(key) mod 16384 这个核心公式。每个key经过哈希计算后，被映射到0-16383号槽中的某一个，而集群中的每个主节点负责一段连续的槽位区间。

这个设计的精妙之处在于，客户端可以直接根据key计算出目标节点，无需经过代理层转发。客户端维护一份槽位与节点的映射关系，当集群发生拓扑变化时，节点会返回MOVED错误指导客户端更新本地缓存。这种"去中心化"的架构，比传统代理模式少了一次网络跳转，延迟更低，吞吐更高。

但在秒杀场景下，一个棘手的问题随之而来：库存扣减往往基于同一个商品ID，所有请求的key都是"product_123"，哈希计算结果完全一致，所有流量全部打到同一个节点上，其他节点空闲，形成"热点倾斜"。

解决方案其实并不复杂：在key后面拼接随机后缀，如"product_123_01"到"product_123_10"，将同一个商品的库存拆分成10份，分别存储在不同节点上。用户请求到达时，根据用户ID取模决定访问哪个子key，将热点流量均匀打散。

缓存雪崩的三道防线——把"瞬间崩塌"变成"平滑泄洪"

秒杀系统最可怕的敌人，不是高并发本身，而是缓存雪崩——大批缓存key在同一时间集体失效，所有请求直接穿透到数据库，数据库连接池瞬间耗尽，服务彻底瘫痪。

第一道防线，是过期时间增加随机偏移。不让所有key在同一秒过期，而是给每个key的过期时间加上一个随机数（比如原TTL的5%-10%），让失效时刻均匀分布，避免"整齐划一"地压向数据库。

第二道防线，是互斥锁重建缓存。当大量请求发现缓存已过期，只允许第一个请求去数据库加载新数据并重建缓存，其他请求短暂等待或返回旧数据（兜底值）。这个"单线程重建"机制，保证了数据库只承受一份查询压力。

第三道防线最为关键——Redis持久化与主从切换的联动。当Redis节点自身发生故障时，哨兵机制（Sentinel）或集群自身的故障转移能力，能在秒级内将从节点提升为主节点，接替服务。而RDB和AOF两种持久化策略的合理配置，则确保节点重启后能从磁盘快速恢复内存数据，减少冷启动带来的"空窗期"。

秒杀库存扣减——Lua脚本保证原子性

在高并发下扣减库存，竞态条件是头号大敌。两个请求同时读到库存为10，各自减1后写回9，实际上卖出了2件但库存只减了1——这就是经典的"超卖"问题。

Redis集群环境下，解决这个问题的标准方案是Lua脚本。将"读取库存-判断是否大于0-减1-返回结果"这一串操作封装在同一个脚本中，Redis保证脚本执行期间不会被其他命令打断，天然具备原子性。

更重要的是，Lua脚本在集群中的执行要求所有涉及的key必须在同一个槽位上。这又倒逼我们在设计key时，使用Hash Tag机制，比如{product_123}这个格式，让集群只对花括号内的内容做哈希计算，确保库存扣减涉及的多个key（库存计数、限流计数、防重计数）全部落在同一个节点上，避免跨节点的多key操作报错。

限流与降级——别让系统"有尊严地死去"

即使有了集群和缓存，仍然要面对一个残酷现实：流量可能远超系统承载极限。这时候，与其让系统被冲垮，不如主动限流，有尊严地拒绝一部分请求。

令牌桶算法在Redis中的实现极为高效。每个商品维护一个key存储剩余令牌数，每次请求消耗一个令牌，令牌以固定速率补充。当令牌耗尽时，直接返回"排队中"或"已售罄"，不再向下游传递压力。

而熔断降级则是在检测到某节点响应延迟骤增时，主动切断对该节点的调用，快速返回兜底数据（如"库存充足"的假象，随后由异步任务修正），避免因为一个节点的慢响应拖垮整个线程池，引发级联故障。

写在最后：集群不是终点，而是起点

搭建一套三主三从的Redis集群，可能只需要一下午。但让这套集群在百万级秒杀中稳如泰山，考验的是对数据分布、容灾切换、原子操作、限流降级、监控告警每个环节的精细打磨。

真正的秒杀架构，不是把宝押在任何一个组件上，而是让缓存、集群、限流、降级形成一套联动的"防御体系"。 当雪崩来临时，每一层防线都能卸掉一部分冲击力，最终到达数据库的，是一股温和可控的涓涓细流——而这，正是架构师的价值所在。