Redis Sentinel 高可用性方案

Redis Sentinel 是 Redis 官方提供的高可用性解决方案，用于监控 Redis 主从架构，提供自动故障转移、监控告警和配置管理功能。本文档将详细介绍 Redis Sentinel 的核心概念、架构设计、工作原理、配置部署、管理监控以及最佳实践。

Sentinel 架构

1. Sentinel 组件

Redis Sentinel 架构由以下组件组成：

Sentinel 节点：监控 Redis 主从节点，执行故障检测和故障转移
Redis 主节点（Master）：处理客户端写入请求，同步数据到从节点
Redis 从节点（Slave）：复制主节点数据，在主节点故障时可被提升为主节点
客户端（Client）：通过 Sentinel 获取主节点地址，实现高可用连接

2. Sentinel 分布式特性

多个 Sentinel 节点：通常部署 3-5 个 Sentinel 节点，避免单点故障
奇数节点设计：使用奇数个 Sentinel 节点，避免脑裂问题
节点间通信：Sentinel 节点之间通过 Gossip 协议进行通信，交换节点状态信息
共识机制：使用 Raft 算法选举 Sentinel 领导者，执行故障转移

3. Sentinel 部署拓扑

常见的 Sentinel 部署拓扑包括：

3.1 基础部署拓扑

3.2 跨可用区部署拓扑

4. Sentinel 节点部署建议

至少 3 个 Sentinel 节点：确保 Sentinel 自身的高可用性
奇数个 Sentinel 节点：避免脑裂问题
跨物理机器部署：将 Sentinel 节点部署在不同的物理机器或可用区
与 Redis 节点独立部署：避免 Redis 节点故障影响 Sentinel 节点
统一的配置：所有 Sentinel 节点使用相同的配置，确保行为一致

Sentinel 工作原理

1. 故障检测

Sentinel 使用双层故障检测机制：

1.1 主观下线（Subjectively Down, SDOWN）

定义：单个 Sentinel 节点认为 Redis 节点不可用
检测方式：Sentinel 节点定期向 Redis 节点发送 PING 命令
判定条件：如果 Redis 节点在 down-after-milliseconds 时间内未返回有效响应，Sentinel 节点将其标记为主观下线
有效响应：PONG、LOADING 或 MASTERDOWN 响应

1.2 客观下线（Objectively Down, ODOWN）

定义：多个 Sentinel 节点一致认为 Redis 节点不可用
检测方式：Sentinel 节点向其他 Sentinel 节点发送 SENTINEL is-master-down-by-addr 命令，询问主节点状态
判定条件：当同意主节点下线的 Sentinel 节点数达到 quorum 配置值时，主节点被标记为客观下线
仅适用于主节点：客观下线机制仅适用于主节点，从节点和 Sentinel 节点只使用主观下线

2. 领导者选举

当主节点被标记为客观下线后，Sentinel 节点需要选举一个领导者来执行故障转移：

2.1 选举触发条件

主节点被标记为客观下线
没有其他 Sentinel 节点正在执行故障转移
故障转移超时时间已过

2.2 选举过程

Sentinel 节点使用 Raft 算法进行领导者选举：

选举请求：Sentinel 节点向其他 Sentinel 节点发送 SENTINEL is-master-down-by-addr 命令，请求投票
投票响应：其他 Sentinel 节点在选举周期内只能投票给一个 Sentinel 节点
获得多数票：当 Sentinel 节点获得超过半数的投票时，成功当选为领导者
执行故障转移：只有领导者才能执行故障转移操作

2.3 选举规则

每个 Sentinel 节点在一个选举周期内只能投票一次
选举周期由 failover-timeout 配置决定
如果选举失败，将在 failover-timeout 时间后重新选举

3. 故障转移

Sentinel 领导者执行故障转移的过程包括以下步骤：

3.1 选择最优从节点

Sentinel 领导者按照以下优先级选择从节点：

健康状态：从节点必须处于在线状态，与主节点的网络连接正常
复制偏移量：选择复制偏移量最大的从节点，确保数据最完整
从节点优先级：选择 slave-priority 配置值最高的从节点
运行时间：选择运行时间最长的从节点
进程 ID：选择进程 ID 最小的从节点（作为最后选择标准）

3.2 执行故障转移

提升从节点为主节点：Sentinel 领导者向选中的从节点发送 SLAVEOF NO ONE 命令，将其提升为主节点
更新其他从节点：Sentinel 领导者向其他从节点发送 SLAVEOF <new-master-ip> <new-master-port> 命令，让它们复制新主节点
更新主节点信息：Sentinel 领导者更新内部记录的主节点信息
广播新配置：Sentinel 领导者将新的主节点配置广播给其他 Sentinel 节点
通知客户端：Sentinel 节点向客户端发布主节点变更通知

3.3 故障转移超时

failover-timeout：故障转移的超时时间，默认 180 秒
超时处理：如果故障转移超时，将在 failover-timeout 时间后重新尝试
并行故障转移：Sentinel 领导者一次只能执行一个故障转移

4. 配置同步

Sentinel 节点之间通过 Gossip 协议同步配置信息：

配置版本：每个 Sentinel 节点维护一个配置版本号，用于冲突解决
配置传播：Sentinel 节点定期向其他 Sentinel 节点发送配置信息
配置合并：Sentinel 节点接收到新配置后，与本地配置合并，保留较高版本的配置
客户端更新：客户端定期从 Sentinel 节点获取最新的主节点配置

Sentinel 配置

1. 配置文件

Redis Sentinel 使用单独的配置文件，默认名为 redis-sentinel.conf，主要配置项包括：

txt

# Sentinel 监听端口
port 26379

# 监听地址
bind 0.0.0.0

# 保护模式
protected-mode yes

# 日志文件
logfile "sentinel.log"

# 工作目录
dir /tmp

# 监控的主节点配置
# <master-name> <ip> <port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 主节点密码（如果有）
sentinel auth-pass mymaster your_password

# 主观下线时间（毫秒）
sentinel down-after-milliseconds mymaster 30000

# 故障转移超时时间（毫秒）
sentinel failover-timeout mymaster 180000

# 同时进行故障转移的从节点数量
sentinel parallel-syncs mymaster 1

# 从节点优先级
sentinel slave-priority mymaster 100

# 启用脚本通知
sentinel notification-script mymaster /path/to/notification-script.sh

# 启用故障转移后脚本
sentinel client-reconfig-script mymaster /path/to/client-reconfig-script.sh

2. 核心配置参数

配置项	类型	默认值	含义	建议值
`port`	端口	26379	Sentinel 监听端口	26379
`bind`	IP	0.0.0.0	监听地址	0.0.0.0
`protected-mode`	布尔值	yes	保护模式	yes
`sentinel monitor`	配置	-	监控的主节点信息	-
`sentinel auth-pass`	密码	-	主节点密码	-
`sentinel down-after-milliseconds`	毫秒	30000	主观下线时间	10000-30000
`sentinel failover-timeout`	毫秒	180000	故障转移超时时间	180000-360000
`sentinel parallel-syncs`	整数	1	同时同步的从节点数量	1-2
`sentinel slave-priority`	整数	100	从节点优先级	1-100
`sentinel notification-script`	路径	-	通知脚本路径	-
`sentinel client-reconfig-script`	路径	-	客户端重配置脚本路径	-

3. 配置优化建议

down-after-milliseconds：根据网络环境调整，建议 10000-30000 毫秒
quorum：建议设置为 Sentinel 节点数的一半加 1（如 3 个 Sentinel 节点，quorum 设为 2）
parallel-syncs：根据从节点数量调整，建议 1-2，避免同时复制导致网络拥塞
failover-timeout：建议设置为 180000-360000 毫秒
slave-priority：根据从节点性能设置不同优先级，确保最优从节点被提升为主节点

Sentinel 部署

1. 部署前准备

Redis 版本：确保使用 Redis 2.8 及以上版本
主从架构：已部署 Redis 主从架构，确保主从复制正常
网络连通性：确保 Sentinel 节点之间以及与 Redis 节点之间网络连通
防火墙配置：确保 Sentinel 端口（默认 26379）和 Redis 端口（默认 6379）可以访问

2. 部署步骤

2.1 配置 Sentinel 节点

创建配置文件：为每个 Sentinel 节点创建 redis-sentinel.conf 配置文件
配置监控主节点：在配置文件中添加 sentinel monitor 配置
设置密码：如果主节点设置了密码，添加 sentinel auth-pass 配置
调整其他配置：根据实际需求调整其他配置参数

2.2 启动 Sentinel 节点

使用 redis-sentinel 命令启动：

bash

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

使用 redis-server 命令启动：

bash

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

使用 systemd 启动：

创建 /etc/systemd/system/redis-sentinel.service 文件：

ini

[Unit]
Description=Redis Sentinel
After=network.target

[Service]
ExecStart=/usr/local/bin/redis-sentinel /etc/redis/redis-sentinel.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
User=redis
Group=redis
Restart=always

[Install]
WantedBy=multi-user.target

启动并启用服务：

bash

systemctl start redis-sentinel
systemctl enable redis-sentinel

3. 验证部署

检查 Sentinel 状态：

bash

redis-cli -p 26379 sentinel master mymaster

检查从节点状态：

bash

redis-cli -p 26379 sentinel slaves mymaster

检查其他 Sentinel 节点：

bash

redis-cli -p 26379 sentinel sentinels mymaster

模拟故障转移：

杀死主节点进程
观察 Sentinel 日志，确认自动故障转移是否成功
检查新主节点状态

Sentinel 管理

1. 查看 Sentinel 状态

查看主节点信息：

bash

redis-cli -p 26379 sentinel master mymaster

查看从节点信息：

bash

redis-cli -p 26379 sentinel slaves mymaster

查看其他 Sentinel 节点：

bash

redis-cli -p 26379 sentinel sentinels mymaster

查看所有监控的主节点：

bash

redis-cli -p 26379 sentinel masters

2. 添加新的从节点

启动新的从节点：配置新的 Redis 从节点，连接到当前主节点
Sentinel 自动发现：Sentinel 节点会自动发现新的从节点
验证从节点：使用 sentinel slaves mymaster 命令验证新从节点是否被 Sentinel 发现

3. 移除从节点

方法一：使用 Sentinel 命令：

bash

redis-cli -p 26379 sentinel remove <slave-ip>:<slave-port>

方法二：停止从节点：

停止从节点进程
Sentinel 节点会自动移除离线的从节点

4. 添加新的 Sentinel 节点

配置新的 Sentinel 节点：创建配置文件，添加 sentinel monitor 配置
启动 Sentinel 节点：使用 redis-sentinel 或 redis-server 命令启动
Sentinel 自动发现：新 Sentinel 节点会自动被其他 Sentinel 节点发现
验证 Sentinel 节点：使用 sentinel sentinels mymaster 命令验证新 Sentinel 节点是否被发现

5. 移除 Sentinel 节点

方法一：停止 Sentinel 节点：

停止 Sentinel 节点进程
其他 Sentinel 节点会自动移除离线的 Sentinel 节点

方法二：使用 Sentinel 命令：

bash

redis-cli -p 26379 sentinel reset mymaster

6. 手动触发故障转移

在某些情况下，可能需要手动触发故障转移：

bash

redis-cli -p 26379 sentinel failover mymaster

参数说明：

mymaster：主节点名称

Sentinel 监控

1. 监控指标

Sentinel 状态：
- 已监控的主节点数量
- 每个主节点的状态（ok/down）
- 每个主节点的从节点数量
- 每个主节点的 Sentinel 节点数量
故障转移统计：
- 故障转移次数
- 故障转移成功次数
- 故障转移失败次数
- 平均故障转移时间
Sentinel 节点状态：
- Sentinel 节点数量
- Sentinel 节点健康状态
- Sentinel 节点间通信状态

2. 监控工具

Redis 内置命令：
- SENTINEL master：查看主节点状态
- SENTINEL slaves：查看从节点状态
- SENTINEL sentinels：查看其他 Sentinel 节点状态
- INFO sentinel：查看 Sentinel 自身信息
第三方监控工具：
- Prometheus + Grafana：使用 Redis Exporter 采集 Sentinel 指标，在 Grafana 中可视化
- Datadog：提供 Redis Sentinel 监控集成
- New Relic：提供 Redis Sentinel 监控集成
- Zabbix：支持 Redis Sentinel 监控模板

3. 日志监控

Sentinel 日志包含重要的运行信息，建议监控以下内容：

故障检测：主节点被标记为主观下线或客观下线的日志
领导者选举：Sentinel 领导者选举的日志
故障转移：故障转移过程的日志，包括从节点选择、主从切换等
配置变更：Sentinel 配置变更的日志
错误信息：任何错误或异常信息

4. 告警设置

建议设置以下告警：

主节点客观下线：当主节点被标记为客观下线时触发告警
故障转移开始：当开始执行故障转移时触发告警
故障转移完成：当故障转移完成时触发告警
Sentinel 节点离线：当 Sentinel 节点离线时触发告警
从节点离线：当从节点离线时触发告警
故障转移失败：当故障转移失败时触发告警
复制延迟过大：当从节点复制延迟超过阈值时触发告警

Sentinel 最佳实践

1. 部署最佳实践

至少 3 个 Sentinel 节点：确保 Sentinel 自身的高可用性
奇数个 Sentinel 节点：避免脑裂问题
跨物理机器部署：将 Sentinel 节点部署在不同的物理机器或可用区
与 Redis 节点独立部署：避免 Redis 节点故障影响 Sentinel 节点
统一的配置：所有 Sentinel 节点使用相同的配置，确保行为一致

2. 配置最佳实践

合理设置 down-after-milliseconds：根据网络环境调整，建议 10000-30000 毫秒
合理设置 quorum：建议设置为 Sentinel 节点数的一半加 1
合理设置 parallel-syncs：根据从节点数量调整，建议 1-2
合理设置 failover-timeout：建议设置为 180000-360000 毫秒
设置从节点优先级：根据从节点性能设置不同优先级
启用持久化：确保主节点启用 AOF 持久化，保障数据安全
配置密码：为 Redis 节点和 Sentinel 节点设置密码，提高安全性

3. 监控最佳实践

建立完善的监控体系：监控 Sentinel 状态、故障转移情况和日志
设置合理的告警阈值：根据业务需求设置告警阈值
多种告警通知渠道：通过邮件、短信、即时通讯工具等多种渠道发送告警
定期测试故障转移：模拟主节点故障，测试自动故障转移功能是否正常
定期检查 Sentinel 日志：及时发现和处理问题

4. 故障处理最佳实践

制定故障处理流程：明确故障处理的责任分工和操作流程
定期备份数据：定期备份主节点数据，确保数据安全
测试恢复流程：定期测试数据恢复流程，确保能够快速恢复数据
记录故障处理过程：记录故障处理过程，便于分析和优化
持续改进：根据故障处理经验，持续改进 Sentinel 配置和部署

5. 客户端最佳实践

使用支持 Sentinel 的客户端：选择支持 Sentinel 的客户端库，如 Redis-py、Jedis 等
实现客户端重试机制：客户端在收到连接错误时，自动重试连接
缓存主节点信息：客户端定期从 Sentinel 获取最新的主节点信息
处理连接错误：客户端能够正确处理主节点故障导致的连接错误
使用连接池：使用连接池管理客户端连接，减少连接开销

常见问题（FAQ）

Q1: 如何选择合适的 `quorum` 值？

A1: quorum 值的选择需要考虑 Sentinel 节点数量：

3 个 Sentinel 节点：建议设置为 2
5 个 Sentinel 节点：建议设置为 3
一般原则：quorum 值应大于 Sentinel 节点总数的一半

Q2: 如何处理 Sentinel 脑裂问题？

A2: 处理 Sentinel 脑裂问题的方法：

使用奇数个 Sentinel 节点：避免脑裂问题
合理设置 down-after-milliseconds：增加误判的难度
配置 min-slaves-to-write 和 min-slaves-max-lag：确保主节点只有在有足够从节点同步时才能写入
使用外部监控：监控网络分区情况，及时发现脑裂问题

Q3: 如何优化 Sentinel 故障转移速度？

A3: 优化 Sentinel 故障转移速度的方法：

减少 down-after-milliseconds 值：缩短主观下线检测时间
减少 failover-timeout 值：缩短故障转移超时时间
增加 Sentinel 节点数量：提高故障检测和决策速度
优化网络环境：减少节点间通信延迟
合理设置 parallel-syncs：加快从节点同步速度

Q4: 如何迁移 Sentinel 监控的主节点？

A4: 迁移 Sentinel 监控的主节点的方法：

手动故障转移：使用 sentinel failover 命令将从节点提升为主节点
更新配置：在所有 Sentinel 节点中更新 sentinel monitor 配置
重置 Sentinel：使用 sentinel reset mymaster 命令重置 Sentinel 状态
验证迁移：检查 Sentinel 状态，确保新主节点被正确监控

Q5: 如何升级 Sentinel 版本？

A5: 升级 Sentinel 版本的步骤：

备份配置文件：备份所有 Sentinel 节点的配置文件
停止旧版本 Sentinel：逐个停止旧版本 Sentinel 节点
替换二进制文件：将旧版本的 redis-sentinel 或 redis-server 二进制文件替换为新版本
启动新版本 Sentinel：逐个启动新版本 Sentinel 节点
验证升级：检查 Sentinel 状态，确保升级成功

Q6: 如何监控 Sentinel 自身的健康状态？

A6: 监控 Sentinel 自身健康状态的方法：

监控 Sentinel 进程：确保 Sentinel 进程正在运行
监控 Sentinel 端口：确保 Sentinel 端口可以访问
监控 Sentinel 日志：及时发现和处理错误信息
监控 Sentinel 节点数量：确保 Sentinel 节点数量符合预期
监控 Sentinel 间通信：确保 Sentinel 节点间通信正常

Redis Sentinel 高可用性方案 ​

Sentinel 架构 ​

1. Sentinel 组件 ​

2. Sentinel 分布式特性 ​

3. Sentinel 部署拓扑 ​

3.1 基础部署拓扑 ​

3.2 跨可用区部署拓扑 ​

4. Sentinel 节点部署建议 ​

Sentinel 工作原理 ​

1. 故障检测 ​

1.1 主观下线（Subjectively Down, SDOWN） ​

1.2 客观下线（Objectively Down, ODOWN） ​

2. 领导者选举 ​

2.1 选举触发条件 ​

2.2 选举过程 ​

2.3 选举规则 ​

3. 故障转移 ​

3.1 选择最优从节点 ​

3.2 执行故障转移 ​

3.3 故障转移超时 ​

4. 配置同步 ​

Sentinel 配置 ​

1. 配置文件 ​

2. 核心配置参数 ​

3. 配置优化建议 ​

Sentinel 部署 ​

1. 部署前准备 ​

2. 部署步骤 ​

2.1 配置 Sentinel 节点 ​

2.2 启动 Sentinel 节点 ​

3. 验证部署 ​

Sentinel 管理 ​

1. 查看 Sentinel 状态 ​

2. 添加新的从节点 ​

3. 移除从节点 ​

4. 添加新的 Sentinel 节点 ​

5. 移除 Sentinel 节点 ​

6. 手动触发故障转移 ​

Sentinel 监控 ​

1. 监控指标 ​

2. 监控工具 ​

3. 日志监控 ​

4. 告警设置 ​

Sentinel 最佳实践 ​

1. 部署最佳实践 ​

2. 配置最佳实践 ​

3. 监控最佳实践 ​

4. 故障处理最佳实践 ​

5. 客户端最佳实践 ​

常见问题（FAQ） ​

Q1: 如何选择合适的 quorum 值？ ​

Q2: 如何处理 Sentinel 脑裂问题？ ​

Q3: 如何优化 Sentinel 故障转移速度？ ​

Q4: 如何迁移 Sentinel 监控的主节点？ ​

Q5: 如何升级 Sentinel 版本？ ​

Q6: 如何监控 Sentinel 自身的健康状态？ ​

Redis Sentinel 高可用性方案

Sentinel 架构

1. Sentinel 组件

2. Sentinel 分布式特性

3. Sentinel 部署拓扑

3.1 基础部署拓扑

3.2 跨可用区部署拓扑

4. Sentinel 节点部署建议

Sentinel 工作原理

1. 故障检测

1.1 主观下线（Subjectively Down, SDOWN）

1.2 客观下线（Objectively Down, ODOWN）

2. 领导者选举

2.1 选举触发条件

2.2 选举过程

2.3 选举规则

3. 故障转移

3.1 选择最优从节点

3.2 执行故障转移

3.3 故障转移超时

4. 配置同步

Sentinel 配置

1. 配置文件

2. 核心配置参数

3. 配置优化建议

Sentinel 部署

1. 部署前准备

2. 部署步骤

2.1 配置 Sentinel 节点

2.2 启动 Sentinel 节点

3. 验证部署

Sentinel 管理

1. 查看 Sentinel 状态

2. 添加新的从节点

3. 移除从节点

4. 添加新的 Sentinel 节点

5. 移除 Sentinel 节点

6. 手动触发故障转移

Sentinel 监控

1. 监控指标

2. 监控工具

3. 日志监控

4. 告警设置

Sentinel 最佳实践

1. 部署最佳实践

2. 配置最佳实践

3. 监控最佳实践

4. 故障处理最佳实践

5. 客户端最佳实践

常见问题（FAQ）

Q1: 如何选择合适的 `quorum` 值？

Q2: 如何处理 Sentinel 脑裂问题？

Q3: 如何优化 Sentinel 故障转移速度？

Q4: 如何迁移 Sentinel 监控的主节点？

Q5: 如何升级 Sentinel 版本？

Q6: 如何监控 Sentinel 自身的健康状态？