redis cluster通过6节点最小部署、主从分离、gossip协议及客户端容错等组合策略实现高可用，配合业务层随机ttl、本地缓存兜底、细粒度限流与监控告警，共同防范雪崩。
Redis Cluster 本身不直接“防雪崩”，但它能防止因单点故障引发的全量服务中断——这是高并发下保障高可用的第一道防线。真正稳住流量的，是集群配置 + 业务层协同策略的组合。
用对集群架构：6节点起步，主从分离不凑合
3主3从是最小生产级部署。少于3个主节点无法满足多数派（quorum）投票机制，故障转移可能卡死；没有从节点，主挂了就彻底不可写。每个主节点必须配至少1个从节点，且主从不能部署在同一物理机或同一可用区，避免共因故障。
- 16384个槽位由主节点均分，请求按 key 的 CRC16 值自动路由，客户端无需感知分片逻辑
- 节点间通过 Gossip 协议交换状态，超时时间（cluster-node-timeout）建议设为 15000ms，太短易误判，太长影响故障发现速度
- 禁用 cluster-require-full-coverage yes，某分片异常时，其余槽仍可读写，避免“一损俱损”
客户端必须带重试与熔断，不能裸连集群
集群健康 ≠ 请求必成功。网络抖动、MOVED 重定向、ASK 转向都可能失败，客户端若无容错，一次超时就会放大为大量线程阻塞。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Java 推荐用 JedisCluster，设置 max-attempts=3，timeout 不超过 200ms
- Python 推荐 redis-py-cluster，开启 skip_full_coverage_check=True 避免因部分槽不可用而拒绝服务
- 所有客户端需集成监控埋点：记录 cluster_state、cluster_slots_assigned、重定向次数、连接异常率
业务层兜底策略比集群配置更重要
集群只管“数据在哪、谁来接管”，不管“缓存要不要一起过期”或“数据库扛不扛得住”。这些必须在代码里控制。
- 写缓存时加随机 TTL 偏移：基础过期时间 3600 秒，再加 0–1800 秒随机值，打散热点 key 失效时间
- 本地缓存兜底：Caffeine 或 Guava Cache 设置短 TTL（如 30 秒），Cluster 故障时降级为本地读，避免全量穿透
- 回源限流必须细粒度：按业务模块（如商品详情、用户中心）分别限流，RateLimiter 每秒 500 请求，而不是全局一把锁
- 配置中心驱动降级开关：cache.enabled=false 一键切到直连数据库只读模式，比硬扛更可控
监控与响应要跑在故障前面
等业务报错才去查集群，已经晚了。真正的高可用靠的是可观测性驱动的快速干预。
- 重点盯三个指标：CLUSTER INFO 中的 cluster_state=ok、cluster_slots_assigned=16384、各节点 connected_slaves ≥1
- 对 failover_time 和 master_repl_offset 做趋势告警，主从延迟突增往往预示复制断裂
- 定期模拟节点宕机（如 kill -9 主进程），验证故障转移是否在 30 秒内完成，从节点是否正确接管槽位
