一句话答案

三种高可用方案：主从复制（基础）、Sentinel（自动故障转移）、Cluster（分片+高可用，16384 槽）。

核心要点

主从复制的三个阶段：

1. 全量同步（初次连接或增量日志丢失）

Slave → 发送 PSYNC runId offset → Master

全量同步：
  Master fork 子进程 → 生成 RDB 快照
  期间的写命令写入 replication buffer（缓冲区）
  RDB 文件传给 Slave
  Slave 清空数据，加载 RDB
  Master 将 replication buffer 中的增量命令发给 Slave

2. 增量同步（断线重连，offset 仍在 repl_backlog 中）

Slave 重连 → 发送 PSYNC runId lastOffset
Master 检查 lastOffset 是否在 repl_backlog（环形缓冲区）中：
  ├─ 在 → 只发送 lastOffset 之后的增量命令（增量同步）
  └─ 不在（repl_backlog 已被覆盖）→ 触发全量同步

3. 命令传播（正常运行阶段）

Master 执行写命令 → 同步发给所有 Slave（异步，非阻塞）
Slave 执行同步命令，更新数据

主从复制的一致性问题：

• 异步复制：主库写入成功即返回客户端，Slave 可能滞后（读 Slave 可能读到旧数据）
• 主库宕机数据丢失：未同步到 Slave 的数据在主库宕机时丢失
• 解决：min-slaves-to-write 1（至少 1 个 Slave 同步才允许写入，接近半同步复制）

追问与易错

追问方向：

• 三种方案怎么选？
• Cluster 支持事务吗？
• 从主从升级 Cluster 注意什么？

易错点：

• ❌ Sentinel 和 Cluster 一样——前者不分片
• ❌ Cluster 节点越多越好——Gossip 开销增加

💡 记忆锚点

三级进化：主从(师傅带徒弟，手动切换) -> 哨兵(加了监工，自动换师傅，但只有一个师傅干活) -> Cluster(多个师傅各管一片，既分片又高可用)。选型口诀：数据装得下单机用哨兵，装不下用Cluster。