Redis 高可用（主从 / 哨兵 / Cluster / 脑裂）

一句话机制：主从复制做数据冗余与读写分离；哨兵在主从之上做自动故障转移；Redis Cluster 用无中心 + 16384 哈希槽做分片与水平扩展。三者依次解决「备份/读扩展 → 自动切换 → 数据分片」。

不变量（必须成立的约束）

• 主从复制单向：master → slave；一主多从，一从一主。分两阶段：全量复制（psync → master bgsave 发 RDB → slave 加载 → 补发缓冲命令）与部分复制（靠复制偏移量 + 复制积压缓冲区 1MB + runid，断线重连只补差异）。
• 哨兵：监控 + 通知 + 自动选主；但仍是单 master 写，解决「主挂自动切换」，不解决写并发扩展。
• Cluster：无中心节点，16384 个哈希槽（crc16(key) & 0x3fff），槽-节点映射需人工分配（不自动均衡）；节点间用 gossip 通信（端口 = 服务端口+10000）；官方建议 ≤ 1000 节点。
• 选主：slave 发现 master FAIL 后延迟发起选举，需超过半数 master 投票；延迟 = 500ms + rand(0~500) + SLAVE_RANK*1000ms（持最新数据的 slave 优先）。
• 脑裂：网络分区出现多 master 写，恢复后数据丢失；用 min-slaves-to-write 缓解（非 100% 避免）。

关键证据 / 例子

• 复制积压缓冲区默认 1MB、FIFO；offset 差距超缓冲区只能全量复制。
• 一致性哈希会数据倾斜；Redis 哈希槽本质是对「槽」转移，key-槽映射不变，迁移更可控。
• cluster-node-timeout 防网络抖动误切换。

常见误解

• ❌「哨兵能扛高并发写」——哨兵只是单 master 的高可用包装，写仍集中在一台；要写扩展得上 Cluster。
• ❌「Cluster 会自动平衡槽位」——槽-节点映射需人工 reshard，不会自动迁移。
• ❌「Cluster 脑裂可彻底避免」——min-slaves-to-write 只是减少概率，牺牲可用性换安全性，无法 100% 杜绝。
• ❌「主从延迟时从库一定读到最新」——主从异步复制，从库可能落后；且从库不主动清过期 key（见过期删除卡）。

关联

• 来源：Redis常见面试题（面试-叶集群原理 + 老鱼干 Redis6 主从）
• 相关：Redis技术栈总览、概念卡片：Redis过期删除与内存淘汰