获课：shanxueit.com/12891/

秒杀场景避坑：Redis集群高并发高可用，应对百万级流量压力

秒杀，堪称分布式系统领域的“终极考场”。它考验的不是单一技术点，而是整个架构在极端流量下的综合抗压能力。当百万用户在同一秒涌向一个只有百件库存的商品时，系统的每一个环节都在承受极限考验。而在这场流量洪峰中，Redis 集群往往扮演着“最后一道防线”的关键角色。

秒杀场景的“三座大山”

真正做过秒杀的人都知道，最大的挑战不在于代码逻辑本身，而在于应对以下三个核心矛盾：

第一，流量瞬时爆发。 秒杀开启的瞬间，请求量可能在几秒内从日常的几百 QPS 飙升至几十万甚至上百万，这是典型的“脉冲式突刺流量”，而非平稳增长。常规的扩容策略在这种场景下既来不及，也不经济。

第二，数据一致性焦虑。 库存只有100件，绝不能卖出101单。超卖是秒杀最致命的事故，直接造成经济损失和用户体验崩塌。在单机环境下用 synchronized 可以保证线程安全，但一旦部署为集群，多个 JVM 之间的锁就完全失效了。

第三，资源竞争白热化。 海量请求不仅要争抢库存，还会争抢数据库连接、网络带宽、系统线程。如果缺乏有效的流量管控，所有请求会直接穿透到数据库层，瞬间将其击穿，进而引发服务雪崩。

Redis集群：不仅仅是“大号缓存”

很多团队对 Redis 集群的认知停留在“存储更多数据”这个层面。但在秒杀场景下，Redis 集群的价值远不止于此。

分片与高可用：扛住流量与故障的双重保险

单机 Redis 的性能天花板大约在 10 万 QPS 左右，面对百万级流量显然不够。Redis Cluster 通过 哈希槽（Hash Slot）机制 将数据分散到多个主节点，每个节点负责 16384 个槽中的一部分，从而实现水平扩展。

更关键的是高可用设计。每个主节点可以配置从节点，当主节点宕机时，集群内部通过 Gossip 协议 快速感知，从节点自动发起选举并晋升为新主节点，整个故障转移过程对客户端基本透明。这意味着，即使某个节点在秒杀峰值时突然宕机，集群依然能持续提供服务，不会成为“单点事故放大器”。

原子操作：解决超卖问题的“金钥匙”

超卖的本质是多线程并发修改共享资源时产生的竞态条件。在集群环境下，Java 的本地锁无法跨 JVM 生效，此时需要引入 分布式锁 或 原子操作。

Redis 提供了两个利器：一是 SETNX 命令配合过期时间实现的分布式锁，确保同一用户同一时刻只能有一个请求在执行下单逻辑，解决“一人一单”问题；二是 Lua 脚本，因为 Redis 执行脚本是原子性的，可以将“查询库存-判断-扣减”这一系列操作封装在脚本中，一次性执行，从根本上杜绝超卖。使用 Lua 脚本的方案，吞吐量可达数万 QPS，远超数据库事务。

从集群到“避坑”的完整链路

搭建好 Redis 集群只是第一步，真正决定成败的是如何利用它构建完整的流量防线。

第一层防线在接入层。 使用 Nginx 或云负载均衡器配置单 IP 限流（如令牌桶算法），直接拦截恶意刷单和爬虫请求。无效流量越早拦截，下游的压力就越小。

第二层防线在应用层。 将秒杀业务独立部署为一个物理隔离的微服务集群，避免秒杀流量拖垮常规订单和支付服务。同时，应用层只做轻量级校验和转发，复杂业务逻辑一律异步化，通过消息队列削峰填谷。

第三层防线在数据层。 这时 Redis 集群正式登场。秒杀开始前，将商品库存、活动信息等核心数据预热到 Redis 集群中。用户的抢购请求直接与 Redis 交互，只有扣减成功的请求才异步写入数据库。数据库不再是流量入口，而是最终一致性的兜底存储——此时数据库的 QPS 压力已被削减了数个数量级。

千万注意：集群模式下的认知陷阱

第一个陷阱是“MOVED 重定向”。 在 Redis Cluster 中，客户端连接任意节点，如果请求的 key 不在该节点负责的槽位，节点会返回 MOVED 错误并告知正确地址。客户端必须处理这种重定向，否则会频繁走弯路，放大延迟。

第二个陷阱是“缓存三剑客”：穿透、击穿、雪崩。 秒杀场景下，如果某个热 key 过期（缓存击穿）或集群大面积故障（缓存雪崩），大量请求会直接压垮数据库。解决方案包括：对热 key 设置逻辑过期（不物理删除）、使用互斥锁重建缓存、以及多级缓存兜底（本地缓存+分布式缓存）。

第三个陷阱是“连接资源耗尽”。 海量瞬时请求会带来大规模的 TCP 连接创建与销毁，消耗内核资源。务必开启连接池和长连接复用，避免频繁三次握手和四次挥手成为系统瓶颈。

秒杀场景下的 Redis 集群设计，本质上是一场 “在保证数据一致性的前提下，最大化并发吞吐能力” 的博弈。单机环境下的编程思维在此完全不适用。只有将集群的高可用分片、原子操作保障、以及层层递进的流量管控结合起来，才能真正做到“百万流量过，库存不超卖，系统不宕机”。