【Redis】总结（四）——哨兵模式

一、基本概念：

Redis 的主从复制模式下，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，这种故障处理的方法是效率低下的，无法接受。于是，redis 从2.8开始正式提供了 Redis Sentinel（哨兵）架构来解决这个问题。

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

可以理解为在原来的Redis主从复制模式上增加了几个用于监控的Sentinel节点，当主节点故障时，哨兵会自动地选举出一个最优的从节点切换为主节点。

在 Redis Sentinel 架构中，有3种角色：主节点master、从节点slave、sentinel节点。

二、功能：

• 监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。
• 通知：Sentinel节点会将故障转移的结果通知给应用方。
• 主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。
• 配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。

三、出现故障时，故障转移过程：

• 主节点出现故障，此时两个从节点与主节点失去联系，主从复制失败。
• 每个Sentinel节点通过定期监控发现主节点出现了故障。                   
• 多个Sentinel节点对主节点的故障达成一致，选举出sentinel-3节点作为领导者负责故障转移。
• Sentinel领导者节点执行了故障转移。整个过程基本是跟我们手动调整一致，只不过是自动化完成的。
• 故障转移后整个 Redis Sentinel 的结构，重新选举了新的主节点，并且会通知给客户端。

四、部署Sentinel节点：

1、配置Sentinel节点：

//配置Sentinel节点,节点默认端口为26379
//sentinel-1节点监控127.0.0.1:6379这个主节点
//2代表判断主节点失败至少需要2个Sentinel节点同意
redis-sentinel-26379.conf
port 26379
daemoniza yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 180000
sentinel failover-timeout mymaster 30000

2、启动Sentinel节点，方法有两种

//方法一：使用reids-sentinel命令：
redis-sentinel redis-sentinel-26379.comf

//方法二：使用redis-server命令加--sentinel参数：
redis-server redis-sentinel-26379.conf --sentinel

3、确认

$ redis-cli -h 127.0.0.1 -p 26379 info Sentinel

四、实现原理

1、三个定时监控任务

• 每隔10s，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。
• 每隔2s，每个Sentinel节点会向Redis数据节点的_sentinel_:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及它们对主节点的判断。
• 每隔1s，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。

2、主观下线和客观下线

• 主观下线：某一个Sentinel节点对其他节点进行心跳检测时，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失效判定，这个行为叫做主观下线。
• 客观下线：大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的。

3、领导者Sentinel节点选举

Sentinel节点之间会做一个领导者选举的工作，选出一个Sentinel节点作为领导者进行故障转移的工作。其选举工作使用的是Raft算法。

选举大致思路：

（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）如果此过程没有选举出领导者，将进行下一次选举。

4、故障转移

（1）在从节点列表中选出一个节点作为新的主节点。

（2）Sentinel领导者节点对选出来的从节点执行slaveof no one命令，让其成为主节点。

（3）Sentinel领导者向剩余的从节点发送命令，让它们成为新主节点的从节点。

（4）Sentinel节点集合将原来的主节点更新为从节点，并保持着对其关注，当其恢复后，命令它去复制新的主节点。