如何设计百万级QPS高并发下的Redis集群架构方案-Redis-PHP中文网

redis cluster在百万qps下易失稳，因其gossip协议通信开销随节点数超线性增长，导致带宽和cpu被“互相寒暄”占用；热点key引发流量倾斜，slot分片粒度固定加剧负载不均；建议主节点控制在12～24个以内，并采用本地缓存+proxy预分片+cluster分层卸压架构。

如何设计百万级qps高并发下的redis集群架构方案

百万级 QPS 下，直接上 Redis Cluster 往往是错的起点——它不是不能扛，而是容易在 200+ 节点、热点 Key、Gossip 带宽饱和后突然失稳。

为什么 Redis Cluster 在百万 QPS 下会“吵起来”

Redis Cluster 的节点间通信靠 Gossip 协议，每个节点每秒随机发 PING 给若干节点，携带当前已知的集群拓扑（含所有 Slot 映射）。当节点数从 50 扩到 300，单条 PING 消息体积翻倍，消息总量呈超线性增长。你看到的 MOVED 重定向增多、CLUSTER NODES 响应变慢、部分分片 CPU 持续 95%，往往不是业务压力大，而是节点在“互相寒暄”占用了 30%+ 网络带宽和 CPU。

这不是配置问题，是协议设计边界。16384 个 Slot 的分片粒度，在热点商品 ID 或用户 session key 集中时，天然导致流量倾斜——某个主节点扛着 80% 请求，其他节点空转。

集群规模建议严格控制在 12～24 个主节点以内，再往上扩容收益断崖下跌
避免用 user:12345 这类连续数字 ID 作为 Key，否则 CRC16 取模后极易扎堆到同一 Slot
不要依赖客户端自动重试 MOVED，生产环境必须用支持集群拓扑缓存的客户端（如 JedisCluster、Lettuce），且开启 refreshPeriod 主动轮询而非被动重定向

真正扛住百万 QPS 的三层缓冲结构

纯靠 Redis Cluster 横向堆节点是下策。有效方案是分层卸压：本地缓存挡掉 60%+ 热点读，Proxy 层做请求聚合与预分片，Redis Cluster 只承载最终不可绕过的原子写操作。

例如秒杀场景中：GET stock:1001 不直连 Redis，而是先查 Caffeine 本地缓存；未命中再走 Proxy；Proxy 收到 1000 个相同 stock:1001 请求，合并为 1 次 Lua 脚本调用，返回后广播更新本地缓存。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

本地缓存 TTL 设为 10s 左右，避免一致性失控，但足够覆盖大部分重复请求
Proxy 层必须实现 Key 预分片逻辑（如对 stock:{id} 中的 id 再哈希一次），打散原生 CRC16 的热点倾向
Redis Cluster 本身只存必要字段：库存值、用户购买标识、订单 token，不做任何业务逻辑计算

Lua 脚本 + Pipeline 是唯一能保原子性的组合

高并发下，GET + DECR + SET 三步必然竞态。必须用 Lua 封装成单次原子执行，且必须搭配 Pipeline 批量提交——否则单个 Lua 调用仍要等 RTT，QPS 上不去。

示例（Jedis）：

String script = "local stock = redis.call('GET', KEYS[1]) if tonumber(stock) > 0 then redis.call('DECR', KEYS[1]); return 1 else return 0 end";
List<string> keys = Arrays.asList("stock:1001");
// 注意：这里不是单次 eval，而是 pipeline 包裹
Pipeline p = jedis.pipelined();
p.eval(script, keys, Collections.emptyList());
p.syncAndReturnAll(); // 一批执行，网络开销摊薄</string>