Redis~Sentinel哨兵(哨兵的高可用性、部署技巧、实现原理、领导选举、故障转移、优缺点)

4. 整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了Redis的高可用问题

• 从逻辑架构上看，Sentinel节点集合会定期对所有节点进行监控，特别是对主节点的故障实现自动转移

Redis Sentinel的几个功能

1. 监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达

2. 通知：Sentinel节点会将故障转移的结果通知给应用方

3. 主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系

4. 配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息

• 同时看到，Redis Sentinel包含了若个Sentinel节点，这样做也带来了两个好处：

对于节点的故障判断是由多个Sentinel节点共同完成，这样可以有效地防止误判

Sentinel节点集合是由若干个Sentinel节点组成的，这样即使个别Sentinel节点不可用，整个Sentinel节点集合依然是健壮的

哨兵的安装与部署

---

• Redis安装目录下有一个sentinel.conf，是默认的Sentinel节点配置文件，配置的参数如下所示：

port 26379

dir /opt/soft/redis/data

sentinel monitor mymaster 127.0.0.1 6379 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

#sentinel auth-pass

#sentinel notification-script

#sentinel client-reconfig-script

• port和dir分别代表Sentinel节点的端口和工作目录

sentinel monitor (重点)

sentinel monitor

本配置说明此Sentinel节点要监控的是一个名字叫做，ip地址和端口为 的主节点

代表要判定主节点最终不可达所需要的票数

参数用于故障发现和判定：例如将quorum配置为2，代表至少有2个Sentinel节点认为主节点不可达，那么这个不可达的判定才是客观的。 对于设置的越小，那么达到下线的条件越宽松，反之越严格。一 般建议将其设置为Sentinel节点的一半加1

• sentinel down-after-milliseconds

每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达，（单位为毫秒）就是超时时间

哨兵实现原理

---

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

三个定时监控任务

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

通过向主节点执行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节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线

• 当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel ismaster-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过个数（quorum是sentinel配置文件中的sentinel monitor配置选项后指定的值），Sentinel节点认为主节点确实有问题，这时该Sentinel节点会 做出客观下线的决定

领导者哨兵节点选举

• 假如Sentinel节点对于主节点已经做了客观下线，那么是不是就可以立即进行故障转移了？当然不是，实际上故障转移的工作只需要一个Sentinel 节点来完成即可，所以Sentinel节点之间会做一个领导者选举的工作，选出 一个Sentinel节点作为领导者进行故障转移的工作

• Redis使用了Raft算法实 现领导者选举，进行领导者选举的大致思路：

1. 每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令， 要求将自己设置为领导者

2. 收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令，将同意该请求，否则拒绝

3. 如果该Sentinel节点发现自己的票数已经大于等于所有哨兵数量的一半，那么它将成为领导者

4. 如果此过程没有选举出领导者，将进入下一次选举

• 总之就是看哪个哨兵与其他哨兵联系更快, 基本上谁先完成客观下线，谁就是领导者

故障转移

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

1. 过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel节点

2. 选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续

3. 选择复制偏移量最大的从节点（复制的最完整），如果存在则返回，不存在则继续

4. 选择runid最小的从节点