Redis 主从复制和 Sentinel 哨兵机制是什么？

简化版

Redis 主从复制是从节点复制主节点数据，用于读扩展和故障恢复基础；Sentinel 负责监控主从节点，发现主节点故障后自动选举新的主节点并通知客户端。主从复制解决数据副本问题，Sentinel 解决自动故障转移问题，但它不负责分片扩容。

详细版

主从复制流程大致包括：

• 从节点连接主节点；
• 首次同步通常做全量复制；
• 之后主节点把写命令传播给从节点；
• 网络中断后可尝试部分重同步。

Sentinel 的职责：

• 监控主节点和从节点状态；
• 判断主观下线和客观下线；
• 主节点故障时选举一个从节点提升为新主；
• 让其他从节点改为复制新主；
• 通知客户端新的主节点地址。

主从 + Sentinel 提供高可用，但仍要考虑复制延迟、故障切换期间短暂不可用、旧主恢复后的角色转换和客户端支持。

完整版教学

一、主从复制解决数据副本

单个 Redis 实例宕机后，即使有持久化，也需要时间恢复，而且服务不可用。主从复制让数据在多个节点上有副本。

从节点通常接收主节点的数据变更。读多写少场景可以让部分读请求走从节点，但要接受主从延迟风险。

主从复制的价值有两个：一是有数据副本，为故障转移提供基础；二是读多写少时可以把部分读请求分散到从节点。但写入仍然由主节点处理，从节点不是用来分摊写入压力的。若业务写入压力已经超过单主能力，主从复制本身解决不了，需要 Cluster 或业务分片。

写请求：client -> master -> replica
读请求：client -> master 或 replica

风险：replica 可能落后 master，读从库可能读到旧值。

二、全量复制和部分重同步

从节点第一次连接主节点时，通常需要全量同步。主节点生成快照并发送给从节点，从节点加载后再接收增量命令。

如果网络短暂断开，Redis 可以根据复制积压缓冲区和复制偏移量尝试部分重同步，只补断开期间缺失的命令。这样比每次都全量复制更高效。

全量复制成本较高：主节点要生成 RDB，传输给从节点，从节点加载期间也会消耗资源。部分重同步依赖复制积压缓冲区，如果从节点断线期间缺失的数据仍在缓冲区里，就能按偏移量补齐；如果断开太久，缓冲区覆盖了缺失部分，就只能重新全量同步。

同步方式	触发场景	成本
全量复制	首次同步、缺失增量无法补齐	RDB 生成、网络传输、加载成本高
部分重同步	短暂断线后偏移量可衔接	只补增量，成本较低
命令传播	正常复制期间	主节点持续发送写命令

记忆钩子：主从复制不是“从节点定期拷贝全量数据”，正常状态是主节点持续传播写命令，断线后尽量补增量。

三、Sentinel 解决自动故障转移

主从复制本身不会自动把从节点提升为主节点。主节点挂了，如果没有额外机制，需要人工切换。

Sentinel 就是高可用管理组件。多个 Sentinel 进程互相协作，监控 Redis 节点。当足够多 Sentinel 认为主节点不可用时，会发起故障转移，选一个从节点为新主。

故障转移不是简单改一个地址。Sentinel 要判断主库是否真的不可用，选出一个合适从库提升为主，让其他从库改为复制新主，并通知客户端新的主节点地址。客户端也要支持 Sentinel 协议或通过中间层发现新主，否则服务仍可能写旧地址失败。

四、主观下线和客观下线

单个 Sentinel 认为主节点不可用，叫主观下线。多个 Sentinel 达成一定数量共识，才会进入客观下线并触发故障转移。

这样可以降低单个 Sentinel 网络抖动导致误判的风险。

例如部署 3 个 Sentinel，配置 quorum=2。只有 1 个 Sentinel 因网络抖动连不上 master 时，只是主观下线；至少 2 个 Sentinel 都认为 master 不可达，才可能判定客观下线并进入后续选举流程。quorum 太低容易误判，太高可能故障时迟迟无法切换，要结合部署拓扑设置。

五、Sentinel 不是 Cluster

Sentinel 提供高可用，不做数据分片。所有数据仍然属于一个主节点的数据集，只是有从节点副本。

如果数据量或写入压力超过单主能力，要考虑 Redis Cluster 或业务分片。不要把 Sentinel 当成水平扩容方案。

这个区别很常被追问。Sentinel 架构下，一个主节点负责整个数据集，从节点复制它；Cluster 架构下，数据按槽分散到多个主节点。Sentinel 解决“主挂了谁接班”，Cluster 解决“数据和流量怎么分到多个主节点”，两者不是同一个问题。

六、复制延迟和脑裂风险

主从复制通常是异步的，主节点写成功不代表从节点马上有这条数据。因此读从节点可能读到旧值，主节点故障时也可能丢失还没复制到从节点的写入。网络分区场景下，如果旧主仍能接收部分客户端写入，而 Sentinel 又选出了新主，还会出现脑裂风险，需要通过合理配置、客户端路由和最小从节点写入约束降低风险。

风险链路：
master 写成功
 -> 尚未复制到 replica
 -> master 故障
 -> replica 提升为新 master
 -> 最近写入可能丢失

七、常见误区与追问

• 误区：主从复制能自动故障转移。 主从只提供数据副本，自动监控和切主需要 Sentinel 或 Cluster 的故障转移机制。
• 误区：Sentinel 可以解决写入扩容。 Sentinel 不做分片，所有写入仍由单主承载，写压力扩展要考虑 Cluster 或业务分片。
• 误区：读从节点一定能读到最新数据。 Redis 主从复制通常异步，从节点可能落后主节点。
• 误区：一个 Sentinel 就足够可靠。 单 Sentinel 容易误判或自身故障，生产通常部署多个 Sentinel 形成共识。
• 追问：主观下线和客观下线有什么区别？ 单个 Sentinel 判断不可达是主观下线，达到 quorum 共识后才是客观下线并触发故障转移。
• 追问：部分重同步失败会怎样？ 如果复制积压缓冲区无法覆盖断线期间缺失增量，从节点需要重新全量同步。

八、加强记忆

Redis 主从复制负责把主节点数据变更同步到从节点，提供副本和读扩展基础；Sentinel 负责监控、判断下线、选主、切换复制关系并通知客户端。它们解决高可用和读扩展，不解决写入水平扩展和数据分片。回答时要带上边界：复制有延迟，切换有短暂不可用，旧主恢复要重新归位，客户端也必须能发现新主。