Redis第二十讲 Redis哨兵自动故障转移与优缺点

        sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。
哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)，在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。

哨兵模式优缺点

优点：
1、哨兵集群，基于主从复制模式，所有的主从配置优点，它都有
2、主从可以切换，故障可以转移，高可用性的系统
3、哨兵模式就是主从模式的升级，手动到自动，更加健壮

缺点：
1、Redis不好在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦
2、哨兵模式的配置繁琐
3，资源浪费，Redis 数据节点中 slave 节点作为备份节点不提供服务。
4，Redis Sentinel 主要是针对 Redis 数据节点中的主节点的高可用切换，对 Redis 的数据节点(主节点)做失败判定分为主观下线和客观下线两种，对于 Redis 的从节点做主观下线操作，并不执行故障转移
5，不能解决读写分离问题，实现起来相对复杂。

     

网络抖动，引发误判

问题描述：
哨兵节点监控到主节点超时未响应，主节点不一定是真的宕机。可能是之间的网络拥堵，或者主库自身压力过大，导致响应超时。

如何避免这种情况？
引入哨兵集群，多个哨兵实例一起判断，降低误判率。判断标准就是，假如 n 个哨兵实例，至少有 n/2+1 个判定一致，才可以定论。

注意：
上面的误判只会用在主库，从库只是负责读，如果监测到未响应，直接标记为 ”下线“，并不需要集群投票验证其真实性。
如果是主库超时未响应，则不能这么草率决定，毕竟后面的选主和通知都是一笔不小的开销，所以，标记主库”下线“，一定要慎之又慎。

哨兵原理

关于哨兵的原理，关键是了解以下几个概念。

（1）定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：通过向主从节点发送info命令获取最新的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送ping命令进行心跳检测，判断是否下线。

（2）主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。

（3）客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。

需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

判断客观下线的数量是Sentinel配置参数中的quorum参数，超过这个值就会被认为客观下线。因为各个Sentinel中的quorum参数可能不同，也就是说对同一个实例，有的可能认为它已经下线了，有的认为它没有下线

（4）选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。

（5）故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：

• 在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后看各个节点的打分情况，打分规则分为 从库优先级、从库复制进度、从库ID号。只要有一轮，某个从库得分最高，则选举它为主库。
  • 从库优先级，主要是考虑到不同的机器可能配置不一样，配置高的机器，优先级高一些，通过slave-priority 来配置
  • 从库复制进度，主要是看slave_repl_offset 的值大小，值越大表示已经同步的数据越多，得分越高。
  • 从库ID号，每个Redis 实例启动时，都会生成一个 ID，在优先级和复制进度相同的条件下，ID号最小的从库分数最高，会被选为新主库。
• 更新主从状态：通过replcaof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
• 将已经下线的主节点(即6379)设置为新的主节点的从节点，当6379重新上线后，它会成为新的主节点的从节点。

当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线了，它会向同样监视这一主服务器的其他Sentinel进行询问，看它们是否也认为主服务器已经进入了下线状态（可以是主观下线或者客观下线)。当Sentinel 从其他Sentinel那里接收到足够数量的已下线判断之后，Sentinel就会将从服务器判定为客观下线，并对主服务器执行故障转移操作。
根据其他Sentinel发回的SENTINEL is-master-down-by-addr命令回复，Sentinel将统计其他Sentinel同意主服务器已下线的数量，当这一数量达到配置指定的判断客观下线所需的数量时，Sentinel 会将主服务器实例结构flags属性的SRI_O_DOwN标识打开，表示主服务器已经进入客观下线状态，如下图

哨兵集群之间的投票
 

借助发布/订阅组建哨兵集群
        我们知道Redis 有pub/sub 机制，当一个哨兵与主库建立连接，可以在主库上发布自己的消息（ip、port），当然也可以在主库上订阅其他哨兵发布的消息。有点类似MQ的topic味道，大家基于同一个topic完成数据交换