redis集群模式

Gaaming Zhang2025/12/21大约 5 分钟

redis集群模式

面试口述要点（约 1 分钟）

Redis 常见集群形态：

主从+哨兵：读写分离，哨兵负责主从切换，适合小规模、无分片需求的场景。
Redis Cluster（官方分片）：16384 哈希槽分片，去中心化，节点互为对等；客户端感知槽分布并跟随 MOVED/ASK 重定向；主从架构容忍节点故障。
代理模式（如 Twemproxy、Codis）：客户端无感知分片，代理层维护路由，运维简单但多一跳；Codis 支持平滑迁移，Twemproxy 不支持重分片。

核心机制：

数据分片：CRC16%16384 分槽，槽与节点映射可在运行时迁移；迁移过程中客户端收到 ASK 并重定向。
高可用：每个主至少 1 从；故障检测靠节点间心跳（PING/PONG、Gossip）；故障转移由大多数主节点投票选出新主。
一致性与写安全：Cluster 不支持多键跨槽事务；Pipeline/事务需同槽；强一致性无保证，主从异步复制有丢失窗口，可用 min-replicas-to-write 限制写入降级。
持久化与恢复：仍依赖 AOF/RDB；重启或故障恢复先加载本地持久化，再与主节点增量对齐。

运维要点：

扩容/缩容：通过 reshard 将槽迁移到新节点，先加从、再提升为主或接管槽。
读写路径：写走主，读可走主或只读从（slave-read-only=no）；客户端需支持 Cluster 协议。
常见问题：槽分布不均导致热点；大 Key/大 Value 影响迁移与复制；分片批量操作需要 hash tag 保证同槽（如 {user123}）。

高频追问与简答

问：Redis Cluster 如何做故障转移？
答：节点间心跳标记主为 FAIL，大多数主确认后由其从节点发起选举，满足配置纪元最大且日志最新的从提升为主；客户端收到 MOVED 更新路由。
问：MOVED 与 ASK 区别？
答：MOVED 表示槽已永久迁到新节点，客户端刷新槽映射；ASK 表示槽迁移进行中，本次请求临时重定向且需带 ASKING 命令。
问：为何不支持跨槽事务？怎么处理多键操作？
答：分片后不同槽在不同节点，原子性无法保障；通过 hash tag 将相关键放同槽，或在业务侧拆分。
问：如何避免主从不一致导致的数据丢失？
答：设置 min-replicas-to-write/min-replicas-max-lag，主在从节点不足或延迟过高时拒写；关键链路开启 AOF everysec 或增量备份。
问：扩容时如何保证可用？
答：先添加节点作为从，进行槽迁移（reshard），迁移采用小批量 Key，业务端需支持 ASK；迁移完成后再做主从角色调整。
问：Codis 与官方 Cluster 的主要差异？
答：Codis 通过代理屏蔽分片，迁移平滑、客户端无感；但多一跳、单点需 HA；官方 Cluster 去中心化、无代理，客户端需实现路由。

在 Redis Cluster 中，故障转移依赖“主从复制+投票”。如果某个哈希槽对应的主节点及其所有从节点全部宕机，集群无法自动提升新主，因为不存在可选的从节点副本。这时集群会进入“槽未覆盖”状态：默认配置下返回 CLUSTERDOWN Hash slot not served，如果 cluster-require-full-coverage no 则仅该槽不可用，其他槽照常服务。恢复路径通常是：

紧急止血：将 cluster-require-full-coverage 设为 no，保证其他业务不被波及；客户端需容错该槽的请求。
数据恢复：基于最近的 AOF/RDB 备份启动一个新节点，或新增空节点接受该槽并接受数据丢失的风险。
槽重分配：使用 redis-cli --cluster reshard 将该槽（及必要的 key）迁移到健康主节点，或把新节点加入为该槽的主；随后为其再添加至少 1 个从节点，恢复高可用。
事后治理：增加每主最少从节点数、开启跨机架副本、监控坏盘/延迟、定期演练恢复，减少“主从同时故障”的概率。

redis集群模式

redis集群模式

面试口述要点（约 1 分钟）

高频追问与简答

哈希槽主从全挂的故障转移（约 1 分钟）

相关高频面试题（该场景）