redis cluster通过16384个哈希槽实现数据分片，每个key按crc16(key) mod 16384计算槽位并路由至对应master节点，支持多主架构、内置故障检测与自动主从切换，无需哨兵；客户端需支持集群协议以处理moved/ask重定向及拓扑更新。
Redis 集群模式通过数据分片 + 多主架构 + 自动故障检测与切换，原生实现负载均衡与故障转移，无需额外组件（如哨兵）介入。
数据分片与请求分散，天然支持负载均衡
Redis Cluster 将整个键空间划分为 16384 个哈希槽（hash slot），每个 key 按 CRC16(key) mod 16384 计算归属槽位，再由集群将槽位均匀分配给多个 master 节点。这意味着：
- 写请求自动路由到负责对应槽位的 master 节点，写压力被分散到多个节点，突破单节点写瓶颈
- 读请求默认也发往对应 master；若开启
READONLY模式，客户端可主动读取 slave，实现读写分离 - 避免热点 key 压垮单节点：可通过在 key 后添加随机后缀（如
user:123:abc）、或使用哈希标签（{user:123}）控制分片粒度
多主 + 从副本 + 集群总线，支撑自动故障转移
每个 master 可配置多个 slave，节点间通过专用端口（如 16379）运行 cluster bus，持续交换心跳、状态和配置信息：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 节点每秒向部分节点发送 PING 消息；若某节点在超时时间内未响应，会被标记为疑似下线（PFAIL）
- 当多数 master 共同确认某节点客观下线（FAIL），集群会触发故障转移：由该 master 的一个 slave 发起选举，其他 slave 投票，得票最多者晋升为新 master
- 整个过程不依赖外部哨兵，由集群内部协调完成，通常在 1–2 秒内完成主从切换
客户端需适配集群协议，才能正确路由与容错
普通 Redis 客户端无法直接对接集群，必须使用支持 Redis Cluster 协议的客户端（如 JedisCluster、redis-py-cluster、Lettuce 等）：
- 首次连接时获取 slots → nodes 映射关系，缓存本地；后续请求按 key 计算槽位，直连对应节点
- 若收到
MOVED或ASK重定向响应，客户端自动更新槽位映射并重试 - 发生故障转移后，客户端收到
CLUSTERDOWN或重定向，会刷新节点拓扑，自动连接新 master
运维层面仍需关注关键细节
集群高可用不是“开箱即用”，实际部署中需注意：
- 至少部署 3 个 master（建议 6 个以上），且每个 master 配置至少 1 个 slave，避免脑裂或多数派无法形成
- 确保各节点时间同步（NTP），否则故障检测可能误判
- 禁止手动执行
FLUSHALL或KEYS *类命令，避免阻塞节点影响集群心跳 - 定期执行
redis-cli --cluster check校验槽位分配与复制状态
