10_Redis哨兵

本笔记来源于：尚硅谷Redis零基础到进阶，最强redis7教程，阳哥亲自带练（附redis面试题）
b站视频

文章来自：
https://github.com/loneasing/mynote

Redis哨兵

Redis Sentinel（哨兵）是 Redis 的高可用性解决方案之一，它可以用于监控和管理 Redis 主从复制集群，并在主节点发生故障时自动将从节点升级为新的主节点，从而保证系统的高可用性和可靠性。

Redis Sentinel 的主要功能如下：

主从监控：监控主从redis库运行是否正常
消息通知：哨兵可以将故障转移的结果发送给客户端
故障转移：如果master异常，则会进行主从切换，将其中一个slave作为新master
配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址

---

配置参数说明

Redis Sentinel架构，前提说明

• 3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人
• 1主2从：用于数据读取和存放

操作步骤

1. $\textcolor{red}{/myredis目录下新建或者拷贝sentinel.conf文件按，名字绝对不能错}$

2. 先看看/opt目录下默认的sentinel.conf文件的内容

3. 重要参数项说明
   • bind：服务监听地址，用于客户端连接，默认本机地址
   • daemonize：是否以后台daemon方式运行
   • protected-model：安全保护模式
   • port：端口
   • logfile：日志文件路径
   • pidfile：pid文件路径
   • dir：工作目录
   • $\textcolor{red}{sentinel\ monitor }$ 设置要监控的master服务器
     quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数

网络是不可靠的有时候一个sentinel会因为网络堵塞而误以为master redis已经死掉，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死掉了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为改master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

• $\textcolor{red}{sentinel\ auth-pass }$
  master设置了密码，连接master服务的密码
• 其他
  sentinel down-after-milliseconds <master-name> <milliseconds>：
  指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

sentinel parallel-syncs <master-name> <nums>：
表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据

sentinel failover-timeout <master-name> <milliseconds>：
故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

sentinel notification-script <master-name> <script-path> ：
配置当某一事件发生时所需要执行的脚本

sentinel client-reconfig-script <master-name> <script-path>：
客户端重新配置主节点参数脚本

1. 环境配置

（1）配置三个哨兵实例

三个哨兵实例需要三台虚拟机，考虑到机器性能有限，这里将三个哨兵实例配置到一台虚拟机上(这里配置到主节点的那台虚拟机)，配置三份不同的哨兵配置文件即可：sentinel26379.conf、sentinel26380.conf、sentinel26381.conf，将它们存放到/myredis下。

（2）修改哨兵配置文件的内容

• 基础配置

  • 关闭保护模式：protected-mode no
  • 开启后台运行：daemonize yes
  • 配置哨兵服务端口号：port 26379 （三个文件要不一样）
  • 日志文件路径：logfile "/myredis/sentinel26379.log"
  • pid文件路径：pidfile /var/run/redis-sentinel26379.pid
  • 工作目录：dir /myredis

• 主要配置

  • 设置要监控的master：**master monitor <master-name> <ip> <redis-port> <quorum>**

    master-name：给master取的名字。

    quorum：同意故障迁移的法定票数。即表示有几个哨兵认可主观下线。达到一定票数后认定为客观下线(宕机、不可用)

  • 配置连接master服务的密码：**sentinel-auth-pass <master-name> <password>**

• 其他配置（使用默认即可）

  • sentinel down-after-milliseconds <master-name> <milliseconds>

    指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

  • sentinel parallel-syncs <master-name> <nums>

    表示允许并行同步的slave个数，当master挂了后，哨兵会选出新的master，剩余的slave会向新的master发起同步数据

  • sentinel failover-timeout <master-name> <milliseconds>

    故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

  • sentinel notification-script <master-name> <script-path>

    配置当某一事件发生时所需要执行的脚本

  • sentinel client-reconfig-script <master-name> <script-path>

    客户端重新配置主节点参数脚本

去除配置文件的注释，最终配置文件sentinel26379.conf的内容如下，sentinel26380.conf和sentinel26381.conf稍作修改即可

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

（3）配置主节点的访问密码

主节点宕机后，哨兵会选举一个从节点作为主节点，而之前的主节点会变成从节点，所以需要配置访问新主节点的密码。

这里所有节点都设置为同一密码，方便操作。

2. 实操演示

2.1 启动三个redis实例

2.2 启动三个哨兵实例

启动哨兵服务有两种方式：

这里在redis(6379)那台机器上启动三个哨兵实例。

启动哨兵服务有两种方式：

• 使用redis-sentinel程序启动：redis-sentinel sentinel.conf
• 使用redis-server程序启动：redis-server sentinel.conf --sentinel

2.3 测试主从复制

2.4 查看sentinel日志文件

下面查看sentinel26379.log文件的主要内容：

新配置保存到磁盘的意思就是新配置信息写入到sentinel.conf文件中，下面查看sentinel26379.conf文件新增的内容：

2.4 模拟master节点宕机

关闭master节点后，哨兵会重新选举一个从节点作为新的主节点。

首先三个哨兵实例会投票选举一个哨兵实例作为领导者，然后由该哨兵实例来选举一个新的主节点并且进行故障迁移(failover)

• 查看sentinel26379.log日志文件了解哨兵选举的过程：
  

• 查看redis(6379)实例的redis.conf文件哨兵leader新增的内容：

  redis(6379)实例由之前的主节点变成从节点

• 查看redis1(6380)实例的redis.conf文件哨兵leader修改的内容：

  redis1(6380)实例由之前的从节点变成主节点

  

• 查看redis2(6381)实例的redis.conf文件哨兵leader修改的内容：

  

结论

$\textcolor{red}{文件的内容，在运行期间会被sentinel动态进行更改}$
Master-Slave切换后，master_redis.conf、slave_redis.conf、sentinel.conf的内容都会发生改\变，即master_redis.conf中会多一行slaveof的配置，而升级为master的主机会去掉原来的slaveof配置，\sentinel.conf的监控目标会随之调换

其他备注

生产上都是不同机房不同服务器，很少出现3个哨兵全部挂掉的情况

可以同时启动多个master，一行一个

---

3. 哨兵选举的流程

1. 哨兵检测到主节点不可用：当哨兵检测到主节点不可用时，会将主节点标记为下线状态(sdown)，并向其他哨兵发送通知，通知其他哨兵主节点已经下线，其他哨兵也标记主节点下线后(odown)，确定主节点不可用。

主观下线(sdown)：指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。
主观下线就是说如果服务器在sentinel down-after-milliseconds给定的毫秒数之内没有回应PING命令或者返回一个错误消息， 那么这个Sentinel会主观的(单方面的)认为这个master不可以用了。

客观下线(odown)：客观下线需要多个哨兵达成一致意见才能认为主节点真正不可用。
quorum(票数)这个参数是进行客观下线的一个依据。法定人数/法定票数(quorum)。

quorum这个参数是进行客观下线的一个依据，法定人数/法定票数 意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

2. 哨兵投票选举哨兵leader：哨兵在检测到主节点不可用后，会进入选举状态，此时哨兵将开始选举哨兵的领导者。

当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个$\textcolor{red}{\large 领导者哨兵节点（兵王）}$并由该领导者也即被选举出的兵王进行failover（故障转移）。
哨兵日志文件解读分析

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请、如果B没有同意过其他哨兵，则会同意A成为领导者。

3. 哨兵leader开始推动故障切换流程并选举出一个新的master

1. 新主登基

• 某个Slave被选中成为新Master
• 选出新master的规则，剩余Slave节点健康前提下，会按下图规则进行选举
  

1 . redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)

2 .复制偏移位置offset最大的从节点(也就是在master还没有宕机时，复制到数据比其他Slave要多)

3 . 最小Run ID的从节点，字典顺序，ASCII码

2. 群臣俯首

• $\textcolor{red}{\large 一朝天子一朝臣，换个码头重新拜}$
• 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
• sentinel leader会对选举出的新master执行slaveof on one操作，将其提升为master节点
• sentinel leader向其他slave发送命令，让剩余的slave成为新的master节点的slave

3. 旧主拜服

• $\textcolor{red}{\large 老master回来也认怂，会被降级为slave}$
• 老master重新上线后，会将它设置为新选出的master的从节点
• sentinel leader会让原来的master降级为slave并恢复正常工作

4.小总结

上述的failover操作均由sentinel自己独自完成，完全不需要人工干预

---

4. 哨兵使用建议

• 哨兵实例的数量应为多个，哨兵本身应该集群，保证高可用

• 哨兵实例的个数应该为基数，方便投票选出Sentinel Leader

• 各个哨兵实例的配置应该一致

• 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射

• 哨兵集群+主从复制，并不能保证数据零丢失（引出集群cluster，集群可以解决这一问题）

  master宕机后，哨兵需要在一定时间内选出新的master并执行failover操作，这段时间内从节点无法写入数据，造成数据丢失。