Redis高可用之哨兵模式：Sentinel配置与启动详解（五）

在前几篇文章中，我们介绍了 Redis 主从复制作为数据冗余的基础。然而，主从复制本身并未解决自动故障转移的问题——当主节点宕机时，需要手动干预来提升一个从节点为新的主节点，这会导致服务中断。Redis Sentinel（哨兵模式）正是为了解决这一问题而生的高可用方案。

Sentinel 是一个分布式系统，用于监控 Redis 主从服务器的健康状态，并在主节点发生故障时，自动执行故障检测、故障转移和配置更新。本文将深入探讨 Sentinel 的核心配置项、启动流程、最佳实践以及常见问题，带领您完成一个高可用 Redis 集群的搭建。

目录#

  1. Sentinel 核心概念回顾
  2. Sentinel 配置文件详解
  3. 启动 Sentinel 进程
  4. Sentinel 最佳实践与常见配置
  5. 验证与故障排查
  6. 总结
  7. 参考引用

一、 Sentinel 核心概念回顾#

在开始配置之前，让我们快速回顾几个关键概念：

  • Sentinel 实例： 一个独立运行的 Sentinel 进程。通常，我们需要部署奇数个（如 3 或 5 个） Sentinel 实例来构成一个 Sentinel 集群，通过投票机制达成决策，防止脑裂。
  • 监控目标： Sentinel 负责监控一个主节点。通过自动发现机制，它能找到该主节点下的所有从节点和其他监控同一主节点的 Sentinel 实例。
  • 主观下线： 单个 Sentinel 实例认为某个 Redis 节点不可用。
  • 客观下线： 当足够数量（由 quorum 参数决定）的 Sentinel 实例都认为主节点主观下线时，主节点被标记为客观下线，随后触发故障转移流程。
  • 故障转移： Sentinel 集群从原主节点的从节点中，选举出一个新的主节点，并让其他从节点开始复制新的主节点，同时更新客户端连接信息。

二、 Sentinel 配置文件详解#

每个 Sentinel 实例都需要一个配置文件（例如 sentinel.conf）。这个文件决定了 Sentinel 的行为。下面我们分解一个标准的配置文件。

2.1 基本配置#

# 指定哨兵进程运行的端口，默认为 26379。
# 如果在一台机器上部署多个sentinel，需要指定不同端口。
port 26379
 
# 禁止保护模式。保护模式下 Sentinel 默认只接受回环地址的连接。
# 生产环境若需要远程连接或非回环地址的Sentinel间通信，应设置为 no，并配置密码或绑定IP。
protected-mode no
 
# 以守护进程方式运行（后台运行）
daemonize yes
 
# 指定日志文件路径
logfile "/var/log/redis/sentinel.log"
 
# 指定进程ID文件路径
pidfile "/var/run/redis/sentinel.pid"

2.2 核心监控配置#

这是 Sentinel 配置中最重要的部分。

# 格式：sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 192.168.1.10 6379 2
  • mymaster： 为主节点起一个别名。这个名称在整个 Sentinel 集群中必须一致。客户端连接 Sentinel 时会用到这个名称。
  • 192.168.1.10 和 6379： 被监控主节点的 IP 和端口。
  • quorum： 法定人数。
    • 它有两个作用：
      1. 确认客观下线所需的最小 Sentinel 票数。例如，配置为 2，则需要至少 2 个 Sentinel 认为主节点下线，才会将其标记为客观下线。
      2. 在执行故障转移时，候选 Sentinel 需要获得至少 quorum 数量的赞成票才能被授权执行故障转移。但最终选举 Leader 需要大多数（> N/2） Sentinel 的同意。
    • 最佳实践： 如果有 3 个 Sentinel，quorum 通常设置为 2。这确保了故障转移的可靠性，避免了单点 Sentinel 误判导致的意外切换。

2.3 其他重要配置项#

这些配置项通常不需要手动设置，Sentinel 会在运行时自动重写配置文件。但了解它们至关重要。

# 格式：sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
  • 含义： Sentinel 认为一个 Redis 节点主观下线所需的时间（毫秒）。如果 30 秒内未收到来自主节点的有效回复（如 PING 命令的响应），Sentinel 就会认为该节点主观下线。可以根据网络状况调整。
# 格式：sentinel parallel-syncs <master-name> <numreplicas>
sentinel parallel-syncs mymaster 1
  • 含义： 在故障转移后，同时向新主节点发起数据同步的从节点数量。设置为 1 意味着每次只允许一个从节点进行全量同步，这可以减轻新主节点的负载。如果从节点数据较旧，全量同步会非常消耗资源。
# 格式：sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
  • 含义： 故障转移的超时时间。它不是一个严格的超时限制，而是定义了故障转移过程中多个步骤的“超时”概念。例如：
    • 同一个主节点再次故障转移的间隔时间。
    • 取消正在进行的故障转移的时间。
    • 当故障转移完成后，重新配置从节点指向新主节点的时间。

2.4 安全配置（如果Redis有密码）#

如果您的 Redis 主从节点配置了密码，Sentinel 也需要知道密码才能进行监控和故障转移。

# 格式：sentinel auth-pass <master-name> <password>
# 这设置了 Sentinel 连接主节点和从节点时使用的密码。
sentinel auth-pass mymaster YourStrongPassword123
 
# 如果 Sentinel 实例之间需要密码才能通信（通常只在Sentinel本身有密码时设置）
# sentinel auth-pass <master-name> <sentinel-password>  # 这个指令不标准，通常用下面的方法
# 更常见的做法是使用 requirepass 和 masterauth 来保证所有节点和Sentinel使用同一密码。
# 在每个Redis节点的配置中设置：
requirepass "YourStrongPassword123"
masterauth "YourStrongPassword123"
 
# 在Sentinel配置中，除了上面的 auth-pass，也可以设置自身密码：
requirepass "YourStrongPasswordForSentinel"

三、启动 Sentinel 进程#

配置好 sentinel.conf 后，启动过程非常简单。

3.1 启动命令#

使用 redis-sentinel 程序并指定配置文件路径：

$ redis-sentinel /path/to/your/sentinel.conf

或者，你也可以使用 redis-server 命令，但加上 --sentinel 参数，效果完全相同：

$ redis-server /path/to/your/sentinel.conf --sentinel

3.2 检查启动状态#

启动后，查看日志文件是第一步：

$ tail -f /var/log/redis/sentinel.log

您应该看到类似以下的输出，表明 Sentinel 已经成功启动并开始监控主节点：

# Sentinel ID 和版本信息
X:X Sentinel-ID:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
X:X # Sentinel runid is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
X:X # +monitor master mymaster 192.168.1.10 6379 quorum 2
X:X * +slave slave 192.168.1.11:6379 192.168.1.11 6379 @ mymaster 192.168.1.10 6379
X:X * +slave slave 192.168.1.12:6379 192.168.1.12 6379 @ mymaster 192.168.1.10 6379
X:X * +sentinel sentinel xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 192.168.1.11 26379 @ mymaster 192.168.1.10 6379
X:X * +sentinel sentinel xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 192.168.1.12 26379 @ mymaster 192.168.1.10 6379

关键信息：

  • +monitor： 开始监控主节点。
  • +slave： 发现了从节点。
  • +sentinel： 发现了其他 Sentinel 实例。这表明您的 Sentinel 集群正在正确形成。

3.3 使用 redis-cli 连接 Sentinel#

您可以使用 redis-cli 连接到 Sentinel 实例，并使用特殊的 Sentinel 命令进行查询和管理。

# 连接 Sentinel 实例（注意端口是 26379）
$ redis-cli -p 26379
 
# 查看被监控的主节点状态
127.0.0.1:26379> SENTINEL master mymaster
# 这个命令会返回大量关于主节点的详细信息。
 
# 查看该主节点的所有从节点
127.0.0.1:26379> SENTINEL slaves mymaster
 
# 查看监控同一主节点的所有其他 Sentinel 实例
127.0.0.1:26379> SENTINEL sentinels mymaster
 
# 获取当前主节点的地址（这是客户端最常用的命令）
127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
1) "192.168.1.10"
2) "6379"

四、Sentinel 最佳实践与常见配置#

  1. 部署奇数个 Sentinel 节点： 推荐 3 个或 5 个，并分布在不同的物理机或虚拟机上，避免单一机器故障导致整个 Sentinel 集群不可用。
  2. 合理的 quorum 值：
    • 3 节点 Sentinel 集群： quorum 设置为 2。
    • 5 节点 Sentinel 集群： quorum 设置为 3 或 4（设置为 3 可以容忍 1 个 Sentinel 故障和网络分区；设置为 4 更严格，能进一步防止误切换）。
  3. 网络考虑： 确保 Sentinel 实例之间以及 Sentinel 与 Redis 节点之间的网络延迟低且稳定。不稳定的网络会导致误判。
  4. 配置管理： Sentinel 会在运行时自动重写配置文件（添加发现到的从节点、其他 Sentinel 等信息）。请确保配置文件所在的目录有写权限，并妥善保管这些自动更新的配置文件。
  5. 客户端支持： 确保您使用的 Redis 客户端库支持 Sentinel。客户端需要能够连接 Sentinel 集群来查询当前主节点的地址。

五、验证与故障排查#

5.1 模拟故障转移#

这是验证 Sentinel 是否正常工作的最终测试。

  1. 步骤： 连接到当前主节点（192.168.1.10:6379），执行 DEBUG SEGFAULT 命令使其崩溃，或者直接杀死其进程。
  2. 观察： 立即在 Sentinel 的日志中观察故障转移过程。您会看到 +sdown, +odown, +vote-for-leader, +switch-master 等事件。
  3. 结果： 使用 SENTINEL get-master-addr-by-name mymaster 命令查询，会发现主节点已经切换到了另一个 IP（如 192.168.1.11）。
  4. 恢复： 重启旧的主节点（192.168.1.10），它会以从节点的身份重新加入集群。

5.2 常见问题#

  • Sentinel 无法发现彼此： 检查防火墙是否开放了 Sentinel 端口（26379）和 Redis 服务端口。确认 protected-mode 和 bind 配置正确。
  • 故障转移失败： 检查 quorum 值是否设置正确，以及是否有足够多的 Sentinel 存活。检查 Sentinel 与 Redis 节点之间的认证密码（auth-pass）是否正确。
  • 客户端连接不上新主节点： 确保客户端库正确实现了 Sentinel 协议，并且能够处理 switch-master 事件，及时更新连接池。

六、总结#

通过本文，我们详细解析了 Redis Sentinel 的配置文件和启动流程。Sentinel 的核心在于其分布式的监控和决策能力，通过简单的配置即可实现 Redis 的高可用。记住成功部署的关键点：奇数个 Sentinel 实例、正确的 quorum 值、稳定的网络以及支持 Sentinel 的客户端。

在下一篇文章中，我们将探讨如何让应用程序（客户端）正确地与 Sentinel 集群交互，实现自动化的故障切换感知。

参考引用#

  1. Redis 官方文档 - Redis Sentinel
  2. Redis 官方文档 - Sentinel 命令
  3. 《Redis 设计与实现》—— 黄健宏
2026-03