🏆 一文 掌握 Redis的哨兵(sentinel)

一、什么是Redis的哨兵

监控后台的预警者负责持续检查主服务器（master主机）的运行状态。一旦发现主服务器出现故障，系统将启动一个自动化的切换机制。这个机制会根据预设的投票规则，从多个备用服务器（从库）中选择一个来接替主服务器的角色。被选中的备用服务器将升级为新的主服务器，并继续无缝地对外提供服务，确保整个系统的持续稳定运行。这种机制有效避免了单点故障带来的风险，并提升了系统的整体可靠性和容错能力。

二、哨兵的作用

1. 主从状态监测：

   • 哨兵系统负责不断检测Redis主服务器及其从服务器的运行状态，确保它们都正常运行。
   • 通过实时的心跳检测和状态检查，哨兵能够迅速发现任何主从节点的问题。

2. 事件通告机制：

   • 在发生主服务器故障转移等重要事件时，哨兵有能力向连接的客户端发送通知。
   • 客户端可以接收到这些事件通知，并据此更新其连接配置或执行其他必要的操作。

3. 自动故障恢复：

   • 一旦检测到主服务器出现异常，哨兵系统会立即启动故障恢复流程。
   • 这个过程涉及将从服务器中的一个提升为新的主服务器，同时更新其他从服务器的配置，使它们跟随新的主服务器。

4. 动态配置服务：

   • 哨兵系统充当了动态配置服务的角色，客户端无需预先知道主服务器的固定地址。
   • 客户端可以通过与哨兵系统的交互，动态获取当前Redis服务的主服务器地址，确保始终连接到正确的节点。

三、哨兵的实战步骤

前置操作

准三台centos虚拟机IP分别为： 129、131、131

实际上线情况，三台哨兵，三台主从六台服务器都是在不同的服务器中

① 将原sentinel.conf 复制一份到myredis文件夹下

cd /java/redis/redis-7.0.2/

ls

pwd

cp sentinel.conf /root/myredis/

② 在129配置启动三个哨兵：实际上线在不同服务器上

1. 在 /root/myredis/ 新建一个sentinel26379.conf

vi sentinel26379.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/root/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /root/myredis
sentinel monitor mymaster 192.168.118.129 6379 2
sentinel auth-pass mymaster 123456

1. 在 /root/myredis/ 新建一个sentinel26381.conf

vi sentinel26381.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/root/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir /root/myredis
sentinel monitor mymaster 192.168.118.129 6379 2
sentinel auth-pass mymaster 123456

1. 在 /root/myredis/ 新建一个sentinel26382.conf

vi sentinel26382.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26382
logfile "/root/myredis/sentinel26382.log"
pidfile /var/run/redis-sentinel26382.pid
dir /root/myredis
sentinel monitor mymaster 192.168.118.129 6379 2
sentinel auth-pass mymaster 123456

④ 修改centos:129的redis6379.conf

新增密码 masterauth 123456

⑤ 修改centos:131的redis6381.conf

新增 replicaof 192.168.118.129 6379

新增 masterauth 123456

⑥ 修改centos:132的redis6382.conf

新增 replicaof 192.168.118.129 6379

新增 masterauth 123456

⑦ 测试三台服务器，redis是否正常启动

1. 在centos:129 启动redis

cd /usr/local/redis/bin/

./redis-server /root/myredis/redis6379.conf

./redis-cli -a 123456 -p 6379

2. 在centos:131 启动redis

cd /usr/local/redis/bin/

./redis-server /root/myredis/redis6381.conf

./redis-cli -a 123456 -p 6381

2. 在centos:132 启动redis

cd /usr/local/redis/bin/

./redis-server /root/myredis/redis6382.conf

./redis-cli -a 123456 -p 6382

⑧ 在centos:129启动三台哨兵

cd /usr/local/redis/bin/

./redis-sentinel /root/myredis/sentinel26379.conf --sentinel

./redis-sentinel /root/myredis/sentinel26381.conf --sentinel

./redis-sentinel /root/myredis/sentinel26382.conf --sentinel

ps -ef|grep redis

查看sentinel26379.log

查看26379.conf

⑨ 关闭centos:129redis

如果centos:129的redis重新启动，master不再改变，仍为centos:131的redis

四、哨兵的工作原理

当某个从服务器（Slave）被哨兵系统选中来升级为新的主服务器（Master）时，遵循以下规则和步骤，确保转换过程的平稳进行：

选出新Master的规则： 在剩余的健康从服务器节点中，选择最适合的一个来升级为新的主服务器。这通常基于预定义的条件，比如从服务器的复制偏移量、网络延迟或手动设置的优先级等。

升级流程：

1. 提权操作： 被选定的从服务器将执行slaveof no one命令，这样它就不再是从服务器，而是作为一个独立的主服务器开始运行。这一步由Sentinel的领导者（Sentinel leader）执行，确保操作的原子性和一致性。
2. 从属重定向： 其他剩余的从服务器将被配置为指向新的主服务器。Sentinel领导者会发送适当的命令（通常是slaveof新主服务器地址 端口号）给这些从服务器，使它们成为新主服务器的从属节点。
3. 旧主降级： 如果原先的主服务器（在故障或不可达状态之后）重新上线，Sentinel领导者会检测到这一事件，并对其进行特殊处理。它会发送命令给原来的主服务器，使其成为新主服务器的从属节点。这样，当老的主服务器重新加入集群时，它会无缝地集成到现有的系统中，并作为一个普通的从服务器工作。

五、哨兵的使用建议

1. 哨兵节点的冗余部署： 为了确保系统的稳健性，应该部署多个哨兵节点，并且这些哨兵节点自身应当形成一个集群，从而增强整体的高可用性。这种集群化的哨兵配置能够抵御单点故障，确保在主节点或任何哨兵节点出现问题时，系统依然能够稳定地提供服务。
2. 奇数哨兵节点的优势： 在配置哨兵节点时，选择奇数个节点是一个明智的做法。这是因为奇数个节点可以在领导者选举过程中有效防止脑裂现象的发生。当网络发生分区时，奇数个节点能够确保只有一侧的多数派能够选出领导者，从而维护了系统的一致性。
3. 哨兵节点配置的一致性要求： 为了保证哨兵集群的正常运作，所有哨兵节点的配置必须保持一致。这涵盖了网络连接设置、主从服务器的识别信息、以及故障检测的相关参数等。通过确保每个节点都使用相同的配置，可以显著降低配置错误的风险，进而提升系统的稳定性和可靠性。

缺点：哨兵在选举新的主机的这段时间内，redis是不能进行写操作的，因此现在很少采用哨兵+主从复制的模式，更多采用的是Redis的集群操作

六、总结

本文介绍了Redis哨兵的作用和实战步骤，包括监控主从状态、故障自动恢复等，保障了系统稳定性。同时，建议部署多个哨兵节点并使用奇数个，确保配置一致性，以提升系统可用性。但需注意，哨兵模式在选举新主机时有写操作限制，现多采用Redis集群方案。