redis哨兵（sentinel）

redis哨兵（sentinel）

简介

        哨兵巡查监控redis的运行状态，包括主机master和从机slave，如果主机故障了根据投票数自动将一个从机转换成一个新主机。一般是主从复制加哨兵或者直接使用redis集群，redis集群更优。

结合以下主从复制的博客：

redis主从复制_@YanM的博客-CSDN博客https://blog.csdn.net/m0_54239478/article/details/132983749?spm=1001.2014.3001.5502

作用：

• 主从监控：哨兵监控redis主从机运行是否正常。
• 消息通知：哨兵可以通过API通知客户端被监视的Redis实例之一出现了异常。
• 自动故障转移：如果master异常，哨兵可以启动一个故障转移进程，其中一个slave被提升为master，其他slave被重新配置为使用新的master，并且使用master的应用程序在连接时被告知使用的新地址。
• 配置中心：客户端通过连接哨兵来获取当前redis服务的主节点地址。

案例演示步骤

架构：三个哨兵（配集群）加一主二从

由于机器硬件问题，这里将三台哨兵都配置进端口为6379这台虚拟机中进行演示。查找6379中的sentinel.conf文件，拷贝到 /usr/local/bin/myredis/ 目录下。

sentinel.conf文件中主要参数说明：

1. bind：服务监听地址，用于客户端连接，默认本机地址
2. daemonize：是否以后台daemon方式运行
3. protected-mode：安全保护模式
4. port：端口
5. logfile：日志文件路径
6. pidfile：pid文件路径
7. dir：工作目录
8. sentinel monitor <master-name> <ip> <redis-port> <quorum>：设置要监控的master服务器，quorum（也称投票数）表示最少有几个哨兵认可主机客观下线，就同意故障迁移。因为网络是不可靠的，有时候一个sentinel会因为网络堵塞导致无法连接master而误以为一个master已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。这就保证了公平性和高可用。
9. sentinel auth-pass <master-name> <password>：master设置了密码，连接master服务的密码
10. sentinel down-after-milliseconds <master-name> <milliseconds>：指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
11. sentinel parallel-syncs <master-name> <nums>：表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
12. sentinel failover-timeout <master-name> <milliseconds>：故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
13. sentinel notification-script <master-name> <script-path> ：配置当某一事件发生时所需要执行的脚本
14. sentinel client-reconfig-script <master-name> <script-path>：客户端重新配置主节点参数脚本

sentinel文件配置

 三个哨兵配置文件如下：

 分别加入以下内容：

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

#sentinel26380.conf
bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/usr/local/bin/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir /usr/local/bin/myredis
sentinel monitor mymaster 192.168.67.100 6379 2
sentinel auth-pass mymaster 123456

#sentinel26381.conf
bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/usr/local/bin/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir /usr/local/bin/myredis
sentinel monitor mymaster 192.168.67.100 6379 2
sentinel auth-pass mymaster 123456

 6379后续可能会变成从机，需要设置访问新主机的密码， 请设置masterauth项，不然后续可能报错master_link_status:down。

启动一主二从，再启动三个哨兵，三台哨兵启动如下

 生成了sentinel的日志文件

 查看日志文件

 查看sentinel26379.conf

我们自己手动关闭6379服务器，模拟master挂了

此时6381变成了主机

 

查看sentinel6379.log，它的主节点已经换成了6381

 之前down机的master机器重启回来,就变成了slave节点了，不会发生冲突，从日志解可以看出。

 

上边的演示中发生了两个小错误，我已经圈了出来

• Error: Server closed the connection
• Error: Broken pipe

其实这两个错误是一样的，Error: Broken pipe是客户端读取超时关闭了连接,这时候服务器端再向客户端已经断开的连接写数据时就发生了broken pipe异常！Error: Server closed the connection是连接直接关闭了，其实对于服务端来说，这两个错误并没有多少影响。因为可能是某个客户端突然中止了进程导致了的，这是因为我们的主机master变了，此时在重试一次就可以了。

对于6379的redis.conf自动添加了一下内容

 redis6381.conf是这样的

它本来有的replicaof 192.168.67.100 6379消失了

 

生产都是不同机房不同服务器，很少出现3个哨兵全挂掉的情况；sentinel可以同时监控多个master。

6381变成了master，可以进行写数据，主从复制也是OK的

6379变成slave，可以读到这个数据但不能写数据

 

哨兵运行流程和选举原理

SDown主观下线(Subjectively Down)

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

sentinel down-after-milliseconds <masterName> <timeout>：表示master被当前sentinel实例认定为失效的间隔时间。
master在多长时间内一直没有给Sentine返回有效信息，则认定该master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。

ODown客观下线(Objectively Down)

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉。

选举领导者哨兵

当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵，并由该领导者哨兵，进行failover(故障迁移)。

领导者哨兵Raft算法进行选举

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

兵王开始推动故障切换流程

新主登基

某个slave被选中为新的master。选出新master规则(剩余slave节点健康前提下)

1. redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)
2. 偏移位置offset最大的从节点
3. 最小Run ID的从节点(字典顺序，ASCII码)

群臣俯首

1. 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
2. Sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点
3. Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave

旧主拜服

将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点

哨兵使用建议

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
• 哨兵节点的数量应该是奇数
• 各个哨兵节点的配置应一致
• 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
• 哨兵集群＋主从复制，并不能保证数据零丢失。当master挂掉的时候，是不能写数据的，哨兵从发现，选出选举算法，从slave中选出新的master，将旧master变成新master的slave等时间间隔内不能写数据，就造成了数据的丢失，因此引入了redis集群。

视频地址：

66_redis哨兵监控之案例实操03_哔哩哔哩_bilibilihttps://www.bilibili.com/video/BV13R4y1v7sP?p=66&spm_id_from=pageDriver&vd_source=282e51f661e6fc136b2286bee19b965c