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操作，这段时间内从节点无法写入数据，造成数据丢失。