Redis7【⑦ Redis哨兵(sentinel)】

Redis哨兵

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

Redis Sentinel 的主要功能如下：

1. 监控 Redis 主节点和从节点的状态，包括节点的可用性、延迟等情况。
2. 自动发现和识别 Redis 主从复制集群的拓扑结构。
3. 在主节点发生故障时，自动将从节点升级为新的主节点，并将其他从节点重新连接到新的主节点。
4. 支持 Redis 集群的自动故障转移、故障恢复和配置管理等功能。
5. 提供监控和管理 Redis 集群的 API 和命令行工具。

---

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

lsof -i|grep redis 可以看到哨兵之间也是有通信的

2.3 测试主从复制

2.4 查看sentinel日志文件

工作中排查问题肯定是要去查日志文件，这里可以发现，每个哨兵都会在日志把主机和从机记录，也会把所有其他哨兵一并记录，日志中写明他们保存在 disk，也就是磁盘里，那么我们要去哪里找到他们呢？
其实这里是重写了conf的配置文件，把相应的关系和信息都写入配置文件里了。

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

了解 Broken pipe

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

2.5 模拟master节点宕机

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

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

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

  

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

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

  

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

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

  

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

  

---

3. 哨兵选举的流程

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

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

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

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

   监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：
   1要票，23没有投过，要票成功，2要票，只能要到1，3要票，要不到，都投过，应该是没人手里一张票，具体高级篇会细致讲解

   

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

   在从节点中选出新的master的规则：
   ①redis.conf中优先级slave-priority或replica-priority高的从节点优先（数值越小优先级越高）
   

   ②复制偏移量(offset)大的从节点优先。
   ③Run ID最小的从节点优先(按字典顺序、ASCII码值比较)，每个redis实例启动后都会随机生成一个40位的run id。

4. 选举出新的master后由Sentinel leader完成failover工作(故障切换)

   • 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点（包括原来的master）成为新主节点的从节点。
   • Sentinel leader会向被重新配置的实例发送一个 CONFIG REWRITE 命令， 从而确保这些配置会持久化在硬盘里(写入配置文件)。
   • 将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线，它会成为新master的从节点，sentinel leader会让原来的master降级为slave并恢复正常工作。不用上线，就已经在log中写为slave，下次上线会对它重新配置。

---

4. 小总结

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

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

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

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

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