Redis哨兵（sentinel）

一 定义

哨兵巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务。

作用：

• 监控redis的运行状态，包括master和slave。
• 当master down机后，能自动将slave切换成新的master。

二 功能

2.1 主从监控

监控主从redis库运行是否正常。

2.2 消息通知

哨兵可以将故障转移的结果发送给客户端。

2.3 故障转移

如果Master异常，则会进行主从切换，将其中一个Slave作为新Master。

2.4 配置中心

客户端通过连接哨兵来获得当前Redis服务的主节点地址。

三 实践

3.1 Redis Sentinel架构说明

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

3.2 具体配置

1. /myredis目录下新建或者拷贝sentinel.conf文件，文件绝不能错。

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

3. 重要参数说明

   • bind：服务监听地址，用于客户端连接，默认本机地址。
   • daemonize：是否以后台daemon方式运行。
   • protected-mode：安全保护模式
   • port：端口
   • logfile：日志文件路径
   • pidfile：pid文件路径
   • dir：工作目录
   • sentinel monitor [master-name] [ip] [redis-port] [quorum] : 设置要监控的master服务器，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服务的密码。
   • sentinel down-after-milliseconds mymaster 30000 : 指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线。
   • 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]：客户端重新配置主节点参数脚本。

4. redis sentinel 启动命令：redis-sentinel sentinel26379.conf --sentinel

3.4 结论

• 文件的内容，在运行期间会被sentinel动态进行更改。
• Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变。即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

四 哨兵运行流程和选举原理

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

4.1 三个哨兵监控，一主二从，正常运行中…

4.2 SDown主观下线（Subjectively Down）

• SDOWN(主观不可用)是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。
• sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度。
• 说明：

4.3 ODown客观下线（Objectively Down）

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

4.4 选举出领导者哨兵（哨兵中选出兵王）-leader

• 当主节点被判断客观下线以后，各个哨兵节点会进行协商，会选举出一个领导者哨兵节点（兵王）并由该领导者节点也就是被选举出的兵王进行failover（故障迁移）。
• 问题：哨兵领导者，兵王是如何选出来的呢？

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

4.5 由兵王开始推动故障切换流程并选出一个新master

三个步骤：

1. 新主登基

   • 某个Slave被选中成为新Master
   • 选出新master的规则，剩余slave节点健康前提下：

   redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先级越高）
   复制偏移位置offset最大的从节点
   最小Run ID的从节点，字典顺序，ASCII码。

2. 群臣俯首

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

3. 旧主拜服

   • 老master回来也认怂
   • 将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点。
   • Sentinel leader会让原来的master降级为slave并恢复正常工作。

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

五 哨兵使用建议

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用。
• 哨兵节点的数量应该是奇数
• 各个哨兵节点的配置应一致
• 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射。
• 哨兵集群 + 主从复制，并不能保证数据零丢失。