1. 课程导入与运维视角

Redis 在互联网系统中常被用作缓存、会话存储、排行榜和分布式锁的底座。单节点 Redis 一旦宕机，依赖它的业务可能在数秒内出现大面积超时。很多团队的第一反应是“加一个从节点”，但主从复制只解决了数据冗余，并没有解决故障后的自动切换问题：主节点挂了，谁来把从节点提升为主？客户端如何知道新主节点的地址？旧主节点恢复后如何重新加入？这些问题正是 Redis Sentinel 要解决的核心命题。

本课程不是单纯讲 Sentinel 的配置项，而是从运维工程视角出发，把 Sentinel 当作一套需要部署、监控、演练和排障的高可用系统来对待。学完本课程，你应该能够独立设计一套三节点 Sentinel 架构，理解主观下线、客观下线、领导者选举和故障转移的完整链路，能够通过日志和命令判断系统当前状态，并在故障发生后快速定位是网络问题、配置问题还是选举问题。

核心对象与知识地图

在 Sentinel 的世界里，有三类核心对象需要始终分清。第一类是被监控的 Redis 数据节点，包括一个主节点和若干从节点，它们负责实际的数据读写和复制。第二类是Sentinel 节点本身，它们不存储业务数据，只负责监控、判断和决策，通常以奇数个组成集群，避免投票平票。第三类是客户端，包括使用 Sentinel 感知地址的 Redis 客户端，以及运维人员使用的 redis-cli、sentinel 命令和监控系统。

这三类对象之间的关系构成了本课程的知识地图。监控层面，Sentinel 通过 PING 和 INFO 命令感知数据节点状态；判断层面，多个 Sentinel 通过 gossip 协议交换信息，对主节点是否下线达成共识；决策层面，Sentinel 内部通过 Raft 风格的选举选出领导者，由领导者执行故障转移；执行层面，领导者选择一个从节点提升为主节点，并通知其他从节点复制新主节点；通知层面，Sentinel 通过发布订阅机制把新主节点地址推送给客户端。整条链路中任何一环出问题，都会表现为“故障没有自动切换”或“切换后客户端连不上”。

实战环境准备

本课程后续所有操作都基于一套可复现的实验环境。建议准备三台 Linux 主机或三个隔离的容器，分别部署 Redis 数据节点和 Sentinel 进程。为了便于观察故障转移，推荐采用“三节点混合部署”方式：每台机器上同时运行一个 Redis 实例和一个 Sentinel 实例，这样任意一台机器宕机，既影响数据节点也影响 Sentinel 节点，更接近真实故障场景。

示例环境规划如下：主机 10.0.0.11 运行 Redis Master（端口 6379）和 Sentinel-1（端口 26379）；主机 10.0.0.12 运行 Redis Slave-1 和 Sentinel-2；主机 10.0.0.13 运行 Redis Slave-2 和 Sentinel-3。三台机器之间需要开放 6379 和 26379 端口，并保证时间同步，否则 Sentinel 的日志时间戳会混乱，增加排障难度。

Redis 数据节点的关键配置包括：主节点设置 bind 0.0.0.0、protected-mode no、requirepass 和 masterauth；从节点额外配置 replicaof 10.0.0.11 6379。Sentinel 节点的配置文件通常命名为 sentinel.conf，核心配置只有一行：sentinel monitor mymaster 10.0.0.11 6379 2，其中最后的数字 2 表示至少需要 2 个 Sentinel 同意才能判定主节点客观下线。此外还需要配置 sentinel auth-pass mymaster <password>，否则 Sentinel 无法通过认证去执行故障转移。

# sentinel.conf 示例（三台机器上除端口外基本一致）
port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
sentinel monitor mymaster 10.0.0.11 6379 2
sentinel auth-pass mymaster Redis@2024
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

启动顺序建议先启动 Redis 主从，确认复制关系正常，再启动三个 Sentinel。验证复制是否正常，可以在主节点执行 redis-cli -a Redis@2024 info replication，观察 connected_slaves 是否为 2，以及每个从节点的 state=online。验证 Sentinel 是否正常，可以执行 redis-cli -p 26379 sentinel master mymaster，观察 flags 字段是否包含 master，以及 num-other-sentinels 是否为 2。

运维视角的关键指标

从运维角度看，Sentinel 系统是否健康，不能只看“有没有切换”，还要关注切换耗时、切换次数和客户端感知延迟。建议重点采集以下指标：Sentinel 日志中 +switch-master 事件的时间戳，用于计算故障转移总耗时；sentinel master mymaster 输出中的 flags 字段，用于判断主节点当前状态；客户端连接池中连接失败和重连的次数，用于判断通知链路是否及时。如果 down-after-milliseconds 设置过小，比如 1000 毫秒，网络抖动就可能触发误切换；设置过大，比如 30000 毫秒，故障恢复时间又会太长。生产环境通常建议设置在 5000 到 10000 毫秒之间，并结合实际网络质量调整。