Redis 哨兵（sentinel）

官网地址： High availability with Redis Sentinel | Redis

是什么：吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将一个从库转换为新主库，继续对外服务。俗称，无人值守运维。

宏观层面（即大局）的 Sentinel 功能的完整列表：

• 监控：监控主从redis库运行是否正常
• 消息通知：sentinel 可以通知其他redis机器，某一台 Redis 实例出现问题。
• 故障转移：如果Master异常，则会进行主从切换，将其中一个Slave作为新的Master
• 配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址

实际操作：

        架构要求：3个哨兵（自动监控和维护集群，不存放数据，只是吹哨人）；1主2从（用于数    据读取和存放）；共6台机器。

        对于搭建环境，其实就是在已经存在的一主二从的基础上，再找3台配置相同的机器搭建sentinel环境。

将该sentinel.conf 加端口号，分别copy到3台主机的/myredis目录下：

bind 0.0.0.0

daemonize yes

protected-mode no

port 26379  (每台机器的不一样)

logfile "/myredis/xxx.log"

pidfile /var/run/redis-sentinel26379.pid

dir "/myredis"

sentinel monitor mymaster 192.168.217.133 2

sentinel auth-pass mymaster Bejing@123

sentinel.conf配置文件：

bind: 服务监听地址，用于客户端链接，默认本机地址

daemonlze：是否以后台daemon方式运行

protected-mode: 安全保护模式

port：端口

logfile：日志文件路径

pidfile：pid文件路径

dir：工作目录

sentinel monitor <master-name> <ip> <redis-port> <quorum>：设置要监控的master服务器。quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数（quorum：确认客观下线的最少得哨兵数量）。

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

sentinel auth-pass <master-name> <password> : 连接master 服务的密码

在配置时需要注意 之前的master没有配置masterauth（redis6379.conf），做哨兵的时候必须要配置此项。因为master后续可能会从主机变成从机，需要设置访问主机的密码

主从模式的配置请参考之前的文章。sentinel的配置可以先只配置上面的内容进行测试。

配置完成之后，先启动主从架构。

# redis-server /myredis/redis6379.conf 

# redis-cli -a Beijing@123 -p 6379

# redis-server /myredis/redis6380.conf 

# redis-cli -a Beijing@123 -p 6380

# redis-server /myredis/redis6381.conf 

# redis-cli -a Beijing@123 -p 6381

测试主从：

主从测试到此结束。

启动哨兵：

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

# redis-sentinel /myredis/sentinel26380.conf --sentinel

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

查看log： # vim sentinel26379.log

# vim sentinel26379.conf 会发现在原有配置文件的基础上，自动增加了下列配置。

启动哨兵之后，再测试主从：

一切ok。

原有Master挂了~

broken pipe的意思是对端的管道已经断开，往往发生在远端把这个读/写管道关闭了（这里对应我们的Master），你无法对这个管道进行读写操作。其实当该异常产生的时候，对于服务端来说，并没有多少影响。因为可能是某个客户端突然中止了进程导致了该错误。

# cat sentinel26379.log 

redis6381.conf 配置文件中，的replicaof IP  也自动没了。

哨兵会在2个slave之间再选取一个master

结论：文件的内容，在运行期间会被sentinel动态进行更改。

Master-Slave切换后，master_redis.conf、slave_redis.onf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof 的配置，sentinel.conf 的监控目标会随之调换。

哨兵只做监控，不做数据的操作（业务上压力不大）。

哨兵的运行流程和选举原理：

当一个主从配置中的master失效之后，sentinel可以选举出一个新的master，用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致吴切换。

• 三个哨兵监控一主二从，正常运行中
• SDown主观下线（Subjectively Down）：sdown（主观不可用）是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定的时间内没有收到合法的回复，就达到了sdown的条件。sentnel.conf配置文件中的down-after-milliseconds 设置了判断主观下线的时间长度。默认时间30s。
• ODown客观下线（Objectively Down）：odown需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机。quorum这个参数是进行客观下线的一个依据
• 选举出领导者哨兵（哨兵中选出兵王（leader））：当master被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王 leader），被选举出的leader进行failover（故障迁移） 。 根据3个sentinel.log文件对照查看。那么哨兵领导者，是如何选出来的？---Raft算法
• 由兵王开始推动故障切换流程并选出一个新的master：①新主登基， 某个slave被选中成为新的Master。选出新master的规则，剩余slave节点健康前提下：redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先级越高）；复制偏移位置offset最大的从节点；最小Run ID 的从节点（字典顺序，ASCII码）每个redis实例启动后都会随机生成一个40位的runid；②群臣俯首，执行slaveof no one 命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点；sentinel leader会对选举出来的新master执行slaveof no one操作，将其提升为master节点；sentinel leader 向其他slave发送命令（slaveof），让剩余的slave成为新的master节点的slave。③旧主拜服，将之前已下线的老master设置为新选出来的新master的从节点，当老master重新上线后，它会成为新master的从节点。sentinel leader 会让原来的老master降级为slave并恢复正常工作。

上述的failover（故障迁移）均由sentinel自己独立完成，完全无需人工干预。

哨兵使用的建议：

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
• 哨兵节点的数量应该是奇数
• 各个哨兵节点的配置应该一致
• 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
• 哨兵集群+主从复制，并不能保证数据领丢失。当master宕机之后，sentinel从发现到选举出新的master的这段时间肯定会有数据的丢失。故---引出集群。