获课：xingkeit.top/5702/

Sentinel 哨兵集群搭建：高可用架构自动故障转移落地实操

Redis 主从架构能解决读写分离，但解决不了一个致命问题——主节点挂了，谁来顶上？答案就是 Sentinel 哨兵集群。它不存数据、不处理请求，只干一件事：盯着你的 Redis，主节点一倒，自动选新主，业务几乎无感知。

一、架构设计：三哨兵一主二从

生产环境的标准阵型是"一主二从三哨兵"。三台机器各跑一个 Redis 节点加一个 Sentinel 进程，Sentinel 统一监听 26379 端口，Redis 统一 6379 端口。

为什么哨兵必须是奇数个？因为故障转移靠投票决策。三个哨兵中至少两个同意主节点挂了，才会触发切换。两个哨兵的话，一比一平局，永远无法决策。这个设计跟 Raft 共识算法一脉相承，少数服从多数，杜绝误判。

服务器规划清晰明了：Node1 做主节点，Node2、Node3 做从节点，每台机器再各跑一个 Sentinel 实例。所有机器关闭防火墙、关闭 SELinux，内存 overcommit 必须设为 1，否则 Redis 启动就报警告。

二、核心配置：五个参数定生死

Sentinel 的配置文件就五个关键参数，错一个整个集群就废。

sentinel monitor：指定监控的主节点名称、IP、端口和 quorum 值。quorum 设为 2，意味着三个哨兵里两个认定主节点下线才动手。

sentinel down-after-milliseconds：多长时间没响应就判下线。生产建议 30 秒，太短容易误杀，太长恢复太慢。

sentinel failover-timeout：故障转移的总超时时间，默认 3 分钟。这段时间内要完成选主、提权、同步切换全流程。

sentinel parallel-syncs：故障转移后最多几个从节点同时同步新主。设为 1 最稳，避免新主被同步请求打垮。

sentinel auth-pass：哨兵连接 Redis 的密码，必须跟 Redis 的 requirepass 一致。

这五个参数在三台机器上完全相同，只有端口号按实例区分。

三、故障转移四步走：从检测到切完不到一分钟

当主节点宕机，Sentinel 的反应链路极其清晰。

第一步：主观下线。 某个 Sentinel 发现主节点 30 秒没响应，标记为"主观下线"，但它不敢独断，得去问别人。

第二步：客观下线。 Sentinel 之间互相通信，当超过 quorum 数量的哨兵都认为主节点挂了，就标记为"客观下线"，此时才具备触发切换的资格。

第三步：选举与切换。 哨兵集群通过 Raft 算法选出一个 leader，由它从从节点中挑一个最优的——优先看复制进度，再看优先级——发送命令将其提升为主节点，同时通知其余从节点更新上游地址。

第四步：通知客户端。 切换完成后，Sentinel 主动推送新主节点地址。Spring Boot 这类框架天然支持哨兵模式，配置文件里填上哨兵节点列表，客户端自动感知切换，无需重启。

四、生产避坑三条铁律

第一，Sentinel 必须跟 Redis 节点物理隔离部署。哨兵挂了不影响 Redis，Redis 挂了哨兵能自动切，但如果哨兵和 Redis 在同一台机器上，机器一倒全完。

第二，开启 AOF 持久化。故障转移期间可能丢失最后几秒数据，AOF 能把损失降到最低。

第三，客户端必须用支持哨兵的连接方式，别直连 Redis IP。直连的话主节点一换，客户端还在往旧地址发请求，切换等于白切。

Sentinel 不复杂，但每一步都关乎生产稳定性。三哨兵、奇数投票、合理超时、客户端感知——这四件事做到位，Redis 高可用就真正落地了。