REDIS / INCIDENT TABLETOP

Sentinel 仲裁与脑裂事故台

集群稳定 · current primary: redis-a
一定要分清

quorum 负责客观下线（ODOWN）判定；实际故障转移还需要 Sentinel 多数派授权。三台 Sentinel 中，即使 quorum=1，也不能靠一票完成故障转移。

网络拓扑 · 点击连线即可切断/恢复

实线=可达　红色虚线=断开
Redis Sentinel 网络拓扑 包含三台 Sentinel、一台 current primary、两台 replica 和两个客户端。连线可以点击切断。 CONTROL PLANE · SENTINEL 监控与投票 DATA PLANE · REDIS 数据节点 CLIENTS · 普通客户端 / 少数派客户端 监控× 监控× 监控× 复制流× 复制流× 旧地址× 仍写旧址× Sentinel-1监控 · 投票 Sentinel-2监控 · 投票 Sentinel-3监控 · 投票 redis-acurrent primary在线 redis-breplicaoffset 9840 redis-creplicaoffset 9790 普通客户端地址 redis-a 少数派客户端缓存旧地址 redis-a

链路开关

判定账本

观察到主节点不可达0 / 3 票
ODOWN 所需 quorum2 票
故障转移多数授权0 / 2 票
旧 primary 合格 replica2 台

故障转移流水线

判定与授权是两道不同的门
1

SDOWN

单个 Sentinel 超过 down-after 后主观下线。

2

ODOWN

下线报告数达到 quorum，形成客观下线。

3

多数派授权

获至少 2/3 Sentinel 授权，才能领导故障转移。

4

选择 replica

比较优先级、复制 offset 与连接质量。

5

提升新 primary

向候选节点发送 REPLICAOF NO ONE。

6

重配 replica

其余节点改为复制新的 current primary。

7

客户端发现

客户端向 Sentinel 查询并切到新地址。

脑裂写入：同一个 key，两条时间线

故障转移完成后，少数派客户端仍可能握着旧 primary 的地址。

旧 primary · redis-a

少数派视角：current primary
orders:1001 = 未写入
未同步写：0

新 primary · 尚未产生

多数派视角：等待选举
orders:1001 = 未写入
已确认写：0
完成“提升新 primary”后，再从两侧写入，观察哪一边会在网络恢复时被覆盖。

三道门各管什么

把参数混在一起理解，是 Sentinel 配置中最常见的误区。

机制回答的问题不能保证
down-after单个 Sentinel 等多久才报告 SDOWN？其他 Sentinel 是否同意。
quorum多少个下线报告才能形成 ODOWN？故障转移一定能拿到多数授权。
多数派授权谁有资格领导这一轮 failover？异步复制下零数据丢失。
min-replicas-*primary 的健康 replica 不够时是否拒写？强一致；窗口内仍可能丢写。
生产结论：Sentinel 提升可用性，不会把 Redis 异步复制变成强一致。旧 primary 在分区中确认、却没有复制出去的写入，重新加入集群后通常会被新 primary 的数据覆盖。