Redis Sentinel：故障检测、自动切主与参数调优

Mon, 03 Aug 2026 00:00:00 +0800

一个 Redis Master 宕机，两个 Replica 却都还健康。数据明明有副本，服务却不会自己恢复：Replica 不会主动接管，客户端也不会凭空找到新的写入地址。主从复制的工作到这里已经结束，Sentinel 要处理的，正是故障发生后的这段空白。

要看懂 Sentinel，可以跟着一次完整的故障转移往下走：多个 Sentinel 如何交换判断并授权其中一个执行切换，新 Master 怎样被选出，整个复制组又如何接受新拓扑。本文先划清职责边界，再沿这条路径拆解原理；第三节转向 Sentinel 本身，说明这些独立进程如何发现同伴并协调行动。随后用本地三 Redis、三 Sentinel 环境观察关键状态，最后落到参数取舍和生产排障。

如果还不熟悉主从复制，可以先读《Redis 主从复制》。本文的机制说明基于 Redis 8.10.0 和源码 commit 5279a8d44818a5ca51e9abb91a9b8ce481d3c88b；实验结果均按实际操作记录，避免把依赖运行环境的现象写成定论。

1. Sentinel 解决什么问题#

主从复制负责把 Master 的数据变化传给 Replicas。它解决的是“故障后有没有副本”，没有回答以下问题：

谁判断 Master 已经不可用；
哪个 Replica 应该接管；
谁修改其余 Replicas 的上游；
客户端到哪里查询新的写入地址。

如果这些动作依赖人工处理，服务恢复时间就取决于告警、判断和操作速度。Sentinel 把这条控制链自动化，但不改变 Redis 异步复制的性质。

这条控制链决定了 Sentinel 的职责范围。Sentinel 是独立于 Redis 数据节点的控制面：一个 Sentinel 进程可以监控多个 Master 复制组，同一个复制组通常由多个 Sentinel 共同管理。

Redis 复制：从全量同步到 PSYNC2

Sun, 29 Mar 2020 09:45:19 +0800

Sentinel 可以在主节点故障后提升副本，Redis Cluster 也能在故障分片内完成主从切换。两种架构都要求副本在故障发生前持续接收主节点的数据，并尽量跟上写入进度。Redis 复制负责维护这份可供接管的数据。

但副本不是主节点的实时镜像。Redis 默认异步传输复制流，主节点响应写入时，副本可能还没有收到对应的数据。链路断开后能否从断点接着传，则取决于 replication ID、offset 和 replication backlog 能否证明双方共享同一段复制历史。本文从部分重同步、全量同步和正常复制流三个阶段入手，解释这些机制为什么存在，以及它们在恢复成本、内存占用、写入延迟和数据一致性之间的取舍。

1. 为什么需要复制#

对现代在线业务来说，只运行一个 Redis 进程、把所有数据和流量压在一台机器上，已经很难满足生产要求。节点故障时，业务需要尽快恢复服务；当数据量或访问量超过单机上限时，又需要把容量和请求分散到多个节点。前者是高可用问题，后者是大数据量和高并发带来的水平扩展问题。RDB 和 AOF 只能帮助单个节点重启后恢复数据，不能让另一个在线节点立即接管服务，也不能突破单机容量。

Redis 提供了两种典型部署架构来处理这两类问题。Sentinel 面向不分片的数据集，监控主节点和副本，并在主节点故障后自动选择副本接管，主要解决高可用。Redis Cluster 把键空间分到多个主节点，用分片扩展容量和写入吞吐；每个分片内仍配置副本，因此 Cluster 也包含分片级的高可用。

两种架构都依赖复制。无论是 Sentinel 提升副本，还是 Cluster 在故障分片内切换主节点，候选节点都必须预先拥有尽可能新的数据。复制持续把主节点的数据变更传给副本，是两种架构的共同基础。它不负责故障判断、选主或客户端路由，这些职责分别由 Sentinel、Cluster 和客户端完成。

2. Redis 如何复制数据#

Redis 复制的发起方是副本。它连接主节点，完成 PING、可选的身份认证和 REPLCONF 信息交换，然后发送 PSYNC <replication-id> <offset> 申报自己已有的复制历史和进度。主节点维护 replication ID、当前 offset 和 replication backlog，并根据副本的请求选择同步方式。

复制链路按主节点的处理顺序分为三段：副本断线恢复时，先尝试部分重同步；第一次复制或部分重同步条件不成立时，改为全量同步；副本追上主节点后，进入持续传输复制流的正常运行状态。这三段并不是每次都依次执行：部分重同步成功后会跳过全量同步，直接回到复制流。两种同步方式都通向同一个结果：先让副本追上，再持续传递新的数据变更。

为什么复制进度要同时使用 replication ID 和 offset？

offset 只是某一条复制历史中的字节位置，并不是全局版本号。两条不同的复制历史即使 offset 相同，对应的数据也可能完全不同。replication ID 用来标识复制历史，offset 用来标识这条历史中的位置；主节点只有同时核对二者，才能判断副本缺少的是不是自己仍可补发的那段字节。

PSYNC2 还保留 secondary replication ID 和它的有效 offset 边界，使新主节点在故障转移后仍能识别上一条复制历史。Redis 只保存当前和上一代两个 ID，不追踪完整的历史树，元数据大小固定，判断也简单。连续多次角色切换或缺失数据已经离开 backlog 时，仍需全量同步。

高可用 on Yeqown

Redis Sentinel：故障检测、自动切主与参数调优

1. Sentinel 解决什么问题#

Redis 复制：从全量同步到 PSYNC2

1. 为什么需要复制#

2. Redis 如何复制数据#