Redis哨兵Sentinel高可用部署

Redis哨兵Sentinel高可用部署的核心目标是：当主节点宕机时，哨兵能自动将一个从节点提升为新主节点，并让其他从节点同步新主，应用端无需人工干预即可恢复缓存读写。
下面从环境准备到故障验证，一步步带你完成整套配置。

部署前的环境与软件准备

开始之前，你需要至少三台Linux服务器（或虚拟机），推荐配置为1核2G以上，操作系统以CentOS 7或Ubuntu 20.04为例。
三台机器分别规划为：

• 192.168.1.101：Redis主节点 + 哨兵1
• 192.168.1.102：Redis从节点 + 哨兵2
• 192.168.1.103：Redis从节点 + 哨兵3

哨兵本身也需要奇数个节点来选举，所以三台机器各启动一个哨兵进程，既节省资源又满足多数派要求。

安装Redis建议使用官方稳定版本，例如Redis 6.2或7.0。
在每台机器上执行：

# Ubuntu/Debian
sudo apt update
sudo apt install redis-server -y

# CentOS/RHEL
sudo yum install epel-release -y
sudo yum install redis -y

安装完成后，先不要急着启动默认服务，因为我们需要自定义配置文件。

配置Redis主从复制

先配置主节点（192.168.1.101）。
编辑/etc/redis/redis.conf，确保以下关键项：

bind 0.0.0.0
protected-mode no
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile /var/log/redis/redis_6379.log
dir /var/lib/redis

保存后启动主节点：

redis-server /etc/redis/redis.conf

接着配置两个从节点（192.168.1.102和192.168.1.103）。
同样编辑/etc/redis/redis.conf，除了上述基础配置外，增加一行：

replicaof 192.168.1.101 6379

注意：Redis 5.0之前使用slaveof，5.0及以上推荐用replicaof。
启动两个从节点：

redis-server /etc/redis/redis.conf

验证主从状态：在主节点执行redis-cli info replication，应看到role:master和两个slave的state=online。
在从节点执行redis-cli info replication，应看到role:slave和master_link_status:up。

部署哨兵Sentinel集群

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

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
dir /tmp
sentinel monitor mymaster 192.168.1.101 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

关键参数解释：

• sentinel monitor mymaster ... 2：监控名为mymaster的主节点，最后一个数字2表示至少需要2个哨兵同意才能判定主节点客观下线。
• down-after-milliseconds 5000：5秒内主节点无响应则标记为主观下线。
• failover-timeout 60000：故障转移超时时间60秒。
• parallel-syncs 1：故障转移后，每次只允许一个从节点同步新主，避免所有从节点同时同步造成阻塞。

注意：三台机器的sentinel.conf中sentinel monitor行必须完全一致，但port和logfile可以相同。
启动哨兵：

redis-sentinel /etc/redis/sentinel.conf

启动后，
用redis-cli -p 26379 info sentinel检查，
应看到master0:
name=mymaster,status=ok,address=192.168.1.101:
6379,slaves=2,sentinels=3。

模拟故障与自动切换验证

现在验证哨兵是否能自动切换。
登录主节点101，直接杀掉Redis进程：

redis-cli -p 6379 shutdown nosave

等待约10-15秒，
观察哨兵日志/var/log/redis/sentinel.log，
会看到类似+switch-master mymaster 192.168.1.101 6379 192.168.1.102 6379的记录，
表示主节点已切换到102。

然后在任意节点执行：

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

应返回新的主节点IP和端口。
同时，在102上执行redis-cli info replication，应看到role:master。
在103上执行redis-cli info replication，应看到master_host:192.168.1.102。

重点结论：哨兵切换成功后，应用端如果使用哨兵地址连接，会自动获取新主节点，无需重启应用。
但需确保客户端支持哨兵模式。

常见避坑与配置建议

• 哨兵节点数量必须为奇数：至少3个，否则无法形成多数派选举。
• 防火墙与安全组：确保所有节点之间6379和26379端口互通，否则哨兵无法通信。
• 配置文件权限：哨兵启动后可能会重写配置文件，建议将sentinel.conf放在可写目录，并确保Redis进程有权限。
• 不要混用不同版本的Redis和哨兵：尽量保持版本一致，避免协议兼容问题。
• 生产环境建议：为Redis设置密码，并在哨兵配置中增加sentinel auth-pass mymaster yourpassword。

切换后应用如何连接

应用端不应直接连接固定的主节点IP，而应连接哨兵集群地址。
以Java Jedis为例：

Set sentinels = new HashSet<>();
sentinels.add("192.168.1.101:26379");
sentinels.add("192.168.1.102:26379");
sentinels.add("192.168.1.103:26379");
JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels);

这样当主节点切换后，客户端会自动从哨兵获取最新主节点地址。

验证清单与日常维护

部署完成后，建议按以下清单逐项检查：

• 三台机器redis-cli info replication角色正确；
• 三台哨兵info sentinel均显示status=ok；
• 手动杀掉主节点后，20秒内完成切换；
• 应用端读写正常，无报错；
• 原主节点恢复后，自动变为从节点并同步新主。

日常维护中，定期查看哨兵日志和Redis慢查询日志，确保没有异常切换。
如果发现频繁切换，检查网络延迟或主节点负载。

常见疑问

哨兵和集群模式有什么区别？
哨兵主要解决主从架构的高可用，数据全量存储在每个节点；Redis Cluster则解决分片和水平扩展，数据分散在多个主节点。如果数据量不大，哨兵足够；数据量大且需要分片，选Cluster。

最少需要几个哨兵？
官方建议至少3个哨兵，且为奇数。2个哨兵无法形成多数派，1个哨兵存在单点故障。

主节点恢复后会自动加入吗？
会。哨兵会将其配置为从节点，并同步新主的数据。但需注意，如果原主节点有未同步的数据，可能会丢失。

哨兵切换期间应用会报错吗？
切换瞬间可能出现短暂连接失败，通常几秒内恢复。建议应用端增加重试机制。

按照以上步骤，你已成功部署Redis哨兵高可用环境，并验证了缓存故障自动切换。
如果遇到切换失败，优先检查哨兵日志和网络连通性。