获课：jzit.top/24574/

Redis 高并发高可用集群 + 百万秒杀：从原理到线上落地

秒杀是互联网系统中最典型的极端高并发场景。一场百万级秒杀活动，意味着在活动开启的瞬间，可能有数十万甚至上百万用户同时涌入，争抢极其有限的库存。如果系统没有经过精心设计，轻则响应缓慢、页面卡顿，重则库存超卖、服务雪崩，直接影响用户体验和商业信誉。

而在这场流量洪峰中，Redis 往往扮演着最核心的角色。

为什么秒杀离不开 Redis

秒杀系统的本质挑战，是在极短时间内处理海量并发请求，同时保证数据的一致性和准确性。传统的数据库方案在这种场景下几乎无法胜任。数据库的磁盘 IO、锁竞争、连接池限制，决定了它很难承受每秒数万甚至数十万次的写入操作。

Redis 的优势在于它是基于内存的数据结构存储，单节点就能达到极高的吞吐量。更重要的是，Redis 是单线程执行命令的模型，天然保证了命令执行的原子性，这为库存扣减等关键操作提供了可靠保障。

但单节点 Redis 的内存和计算能力终究有限，面对百万级并发，必须依赖集群架构来实现水平扩展和高可用。

Redis 集群的核心原理

Redis 集群采用去中心化的分片架构，通过 16384 个哈希槽将数据分散到多个主节点上。客户端发起请求时，根据键的哈希值定位到对应的槽，再路由到负责该槽的节点。每个主节点可以配置一个或多个从节点，当主节点出现故障时，从节点会自动晋升，实现故障转移。

节点之间通过 Gossip 协议交换状态信息，维护集群拓扑。这种去中心化的设计避免了单点故障，也让集群具备了线性扩展的能力。

在秒杀场景中，库存数据会被提前预热到 Redis 集群中，活动开始后，所有的库存校验和扣减操作都在 Redis 层完成，只有扣减成功的请求才会进入后续的订单创建流程。

防超卖：Lua 脚本原子化扣减

超卖是秒杀系统最致命的错误。在高并发下，如果采用"先读取库存、再判断、再扣减"的方式，多个请求可能同时读到相同的库存值，导致实际卖出的数量超过库存。

解决这个问题的核心思路是保证扣减操作的原子性。Redis 支持执行 Lua 脚本，整个脚本在执行过程中不会被其他命令打断，相当于一个原子操作。在脚本中可以同时完成库存校验、用户去重、库存扣减等多个步骤，从根本上杜绝超卖。

这种方案的性能极高，是目前互联网大厂最主流的秒杀库存扣减方式。

削峰填谷：消息队列异步下单

Redis 扣减库存成功后，并不意味着要立即操作数据库创建订单。如果百万请求同时写入数据库，数据库依然会被压垮。

正确的做法是，Redis 扣减成功后立即向用户返回"抢购成功，正在生成订单"，同时将用户信息和商品信息投递到消息队列中。后端的订单服务按照自身的处理能力，从消息队列中平滑消费，逐步完成订单创建、支付锁定等后续流程。

这一步将瞬时的百万级并发洪峰，转化为后端可以稳定处理的流式请求，实现了削峰填谷。

多层防护：从接入层到数据层

一个完整的百万秒杀系统，不是只靠 Redis 就能搞定的，而是需要多层协同防护。

在接入层，通过 Nginx 限流、验证码、IP 频率限制等手段，提前拦截无效请求和恶意流量。在网关层，通过令牌桶算法进行业务限流，防止流量尖峰压垮服务。在应用层，将秒杀模块独立部署，与常规业务隔离，避免互相影响。在缓存层，通过 Redis 集群承担库存扣减的核心压力。在数据层，通过消息队列异步处理订单，数据库作为最终一致性的兜底保障。

这种漏斗式的架构设计，让每一层都能过滤掉一部分流量，最终到达数据库的请求量被控制在可承受的范围内。

高可用保障：不让任何单点成为瓶颈

百万秒杀不仅考验性能，更考验系统的容错能力。任何一个节点宕机，都不应该导致整个活动失败。

Redis 集群本身通过主从复制和自动故障转移保证了缓存层的高可用。消息队列通常采用多副本机制确保消息不丢失。数据库通过主从复制和分库分表提升读写能力和容灾能力。同时，整个系统需要配备完善的监控告警体系，实时监控 QPS、响应时间、库存变化、消息积压等关键指标，一旦异常立即触发告警。

在活动上线前，还需要进行全链路压测，模拟真实流量验证系统的承载能力，提前发现并解决瓶颈。

从原理到落地：关键在架构思维

百万秒杀系统的设计，本质上是一套完整的分布式架构思维的体现。它要求工程师不仅要理解 Redis 的底层原理，还要掌握集群部署、数据分片、原子操作、异步处理、多级缓存、限流熔断、最终一致性等一系列核心技术。

Redis 在秒杀系统中的价值，不仅仅是"快"，更在于它提供了一套从高性能缓存到高可用集群再到原子化操作的完整能力组合。当这些能力被合理地组织在一个分层架构中时，系统就能在百万级并发的极限压力下依然保持稳定、准确、可靠。

从原理到线上落地，中间的距离不是某一行代码，而是对整体架构的深刻理解和对每一个环节的精细把控。