《Redis开发与运维》笔记-哨兵理论

基本概念

Redis提供了主从复制功能，可以实现Redis多个节点数据存储。Redis的主从机制有个基本原则就是一主准则，不管拓扑结构是怎样，每个从节点都只能拥有一个主节点。问题在于一旦主节点出现故障，就会导致整个Redis系统出现问题，这样就需要去替换主节点，可能就需要人工去维护，这样就会引申出相关问题：

• 判断节点不可达的机制是否健全和标准。
• 如果有多个从节点，怎样保证只有一个被晋升为主节点。
• 通知客户端新的主节点机制是否足够健壮。

为了解决这些问题，Redis就提供了Redis Sentinel方案。 Redis Sentinel能自动的完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。

Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的，不需要人工来介入，所以这套方案很有效的解决了Redis的高可用问题。

实现原理

三个定时监控任务

一套合理的监控机制是Sentinel节点判断节点不可达的重要保证，Redis Sentinel通过三个定时监控任务完成对各个节点发现和监控：

1. 每隔10秒，每个Sentinel节点会向Redis数据主节点和从节点发送info命令获取最新的拓扑结构：
   

例如在主节点发送info replication命令：

# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6382,state=online,offset=12975439,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=12975439,lag=0

Sentinel节点通过对上述结果进行解析就可以找到对应的从节点。
这个定时任务的作用具体可以表现在三个方面：

• 通过向主节点执行info命令，获取从节点的信息，这也是为什么Sentinel节点不需要显示配置监控从节点。
• 当有新的从节点加入时都可以立刻感知出来。
• 节点不可达或者故障转以后，可以通过info命令实时更新节点和拓扑信息。

2. 每隔2秒，每个Sentinel节点会向Redis数据节点的_sentinel_:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及它们对主节点的判断，所以这个定时任务可以完成以下两个工作：

• 发现新的Sentinel节点。通过订阅主节点的_sentinel_:hello了解其他的Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保存起来，并与该Sentinel节点创建连接。
• Sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据。
  

3. 没隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。通过上面的定时任务，Sentinel节点对主节点、从节点、其余Sentinel节点都建立起连接，实现了对每个节点的监控，这个定时任务是节点失败判定的重要依据。
   

主观下线和客观下线

1. 主观下线
   根据每个Sentinel节点每秒会对Redis数据节点和其他Sentinel节点发送ping命令进行心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为就叫主观下线。这种判定机制会存在误判的可能。
   
2. 客观下线

当Sentinel节点主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，这样客观下线的含义就比较明显了，也就是大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的。

领导者Sentinel节点选举

当Sentinel节点对于主节点已经做了客观下线，就可以进行故障转移了。实际上故障转移的工作只需要一个Sentinel节点来完成即可，所以Sentinel节点之间会做一个领导者选举的工作，选出一个Sentinel节点作为领导者进行故障转移的工作。Redis使用了Raft算法实现领导选举。Redis Sentinel进行领导者选举的大致思路：

1. 每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导者。
2. 收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令，将同意该请求，否则拒绝。
3. 如果该Sentinel节点发现自己的票数已经大于等于max (quorum,num(sentinels) / 2 + 1)，那么它将成为领导者。
4. 如果此过程没有选举出领导者，将进入下一次选举。

故障转移

领导者选举出的Sentinel节点负责故障转移，具体步骤如下：

1. 在从节点列表中选出一个节点作为新的主节点，选择方法如下：

• 过滤：“不健康”（主观下线，断线）、5秒内没有回复过Sentinel节点ping响应、与主节点失联超过down-after-milliseconds * 10秒。
• 选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在继续。
• 选择复制偏移量最大的从节点（复制的最完整），如果存在返回，不存在继续。
• 选择runid最小的从节点。
  流程如图：
  

2. Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
3. Sentinel领导者节点会向剩余的从节点发送命令，让他们成为新主节点的从节点，复制规则和parallel-syncs参数有关。
4. Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点。