Redis哨兵Sentinel部署

Redis Sentinel（哨兵）是Redis官方提供的高可用方案，它通过监控主从节点并在主节点故障时自动进行故障转移，确保缓存服务持续可用。
如果你正在为单点Redis宕机导致业务中断而烦恼，本文将带你从零完成一套三节点哨兵集群的部署，并验证自动切换效果。

部署前需要准备什么

哨兵集群至少需要三个节点才能构成多数投票机制，推荐使用三台独立服务器或虚拟机。
本文以 一主两从 + 三个哨兵 的经典架构为例，所有节点均运行在Linux环境下（如CentOS 7或Ubuntu 20.04）。

环境规划示例：

• 主节点：192.168.1.10，Redis端口 6379
• 从节点1：192.168.1.11，Redis端口 6379
• 从节点2：192.168.1.12，Redis端口 6379
• 哨兵端口：三台机器均使用 26379

前提条件：

• 三台机器已安装Redis（版本建议5.0及以上，本文以Redis 6.2为例）。
• 确保三台机器时间同步，并且防火墙放行Redis端口和哨兵端口。
• 关闭SELinux或配置相应策略（临时关闭：setenforce 0）。

安装Redis可以使用包管理器或源码编译。
以CentOS为例：

yum install -y redis

安装后先不要启动，我们统一配置主从关系。

配置Redis主从复制

哨兵依赖主从复制，所以先让两个从节点复制主节点数据。

1. 修改主节点配置
编辑 /etc/redis.conf，确保以下项：

bind 0.0.0.0
protected-mode no
port 6379
daemonize yes

启动主节点：systemctl start redis

2. 修改从节点配置
在两个从节点上编辑 /etc/redis.conf，增加：

replicaof 192.168.1.10 6379
masterauth <主节点密码>  # 如果主节点设置了密码
requirepass <从节点密码> # 建议与主节点一致

启动从节点：systemctl start redis

3. 验证主从状态
在主节点执行：

redis-cli info replication

看到 role:master 且 connected_slaves:2，从节点显示 role:slave 且 master_link_status:up 即表示主从同步正常。

编写哨兵配置文件

哨兵需要单独的配置文件，通常命名为 sentinel.conf。
在三台机器上分别创建 /etc/sentinel.conf，内容如下：

port 26379
daemonize yes
logfile "/var/log/sentinel.log"
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel auth-pass mymaster <主节点密码>
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

关键参数解释：

• sentinel monitor mymaster ... 2：表示哨兵集群认为主节点客观下线至少需要2个哨兵同意。
• down-after-milliseconds 5000：5秒内主节点无响应则标记为主观下线。
• failover-timeout 60000：故障转移超时时间60秒。
• parallel-syncs 1：故障转移后，同时向新主节点发起同步的从节点数量。

三台机器的配置完全一致，只需修改 sentinel monitor 中的主节点IP。

启动哨兵并验证集群

分别在三台机器上启动哨兵：

redis-sentinel /etc/sentinel.conf

或者使用 redis-server /etc/sentinel.conf --sentinel。

启动后检查日志 /var/log/sentinel.log，应看到类似输出：

+monitor master mymaster 192.168.1.10 6379 quorum 2
+slave slave 192.168.1.11:6379 ...
+slave slave 192.168.1.12:6379 ...

验证哨兵状态：
连接任意哨兵端口：

redis-cli -p 26379
sentinel master mymaster

输出中应包含 num-other-sentinels 为2，flags 为 master。

模拟故障与自动切换测试

这是检验哨兵是否生效的关键步骤。

1. 手动下线主节点
在主节点执行：

redis-cli -p 6379 shutdown

或者直接 kill 掉Redis进程。

2. 观察哨兵日志
稍等几秒，哨兵日志会显示：

+sdown master mymaster 192.168.1.10 6379
+odown master mymaster 192.168.1.10 6379 #quorum 2/2
+try-failover master mymaster 192.168.1.10 6379
+failover-end master mymaster 192.168.1.10 6379
+switch-master mymaster 192.168.1.10 6379 192.168.1.11 6379

这表示哨兵已将主节点切换到 192.168.1.11。

3. 验证新主节点
连接 192.168.1.11 的Redis：

redis-cli -h 192.168.1.11 -p 6379 info replication

显示 role:master，且原主节点恢复后会自动成为新主节点的从节点。

避坑指南与常见问题

哨兵无法发现从节点？
检查主从复制是否正常，以及哨兵配置中的 auth-pass 是否正确。如果主节点有密码，所有哨兵和从节点都必须配置相同的密码。

故障切换后客户端连不上？
客户端需要使用支持哨兵的连接库（如Jedis、Lettuce），并配置哨兵地址列表。不要直接连接旧的主节点IP。

脑裂风险如何避免？
确保 quorum 值设置为多数哨兵节点数（例如3个哨兵则设为2）。同时，在生产环境中建议至少部署3个哨兵节点，且分布在不同物理机或可用区。

版本兼容性提示：
Redis 5.0之前哨兵命令为 sentinel 子命令，5.0之后配置方式基本一致，但建议使用较新稳定版。具体行为请以官方文档为准。

效果验证与日常维护

部署完成后，你可以通过以下命令快速检查集群健康状态：

redis-cli -p 26379 sentinel sentinels mymaster

这会列出所有哨兵节点及其状态。

日常维护建议：

• 定期查看哨兵日志，关注 +sdown、+odown、+failover 事件。
• 监控哨兵进程存活，可使用 systemctl 或 supervisor 托管。
• 在业务低峰期进行故障演练，确保客户端能正确切换。

总结： Redis哨兵Sentinel部署并不复杂，核心在于正确配置主从复制和哨兵监控参数。
通过三节点集群，你的缓存层可以抵御单点故障，实现自动故障转移。
按照本文步骤操作后，建议再结合业务代码测试客户端重连逻辑，才算真正完成缓存高可用方案落地。