Redis哨兵机制--redis主从集群的高可用保证

Redis通过主从集群扩充主节点的读能力，同时又一定程度上保证数据的不丢失，但是主从集群由如下的问题：
1、如果主节点故障了，需要手动执行主从切换，没法保证高可用；
2、主从集群只能扩充读能力，并不能扩充主节点的写能力。
本篇博文将介绍redis如果保证主从集群的高可用。

哨兵机制的作用

Redis通过哨兵机制来保证redis集群的高可用，它主要有如下的作用：监控、故障转移、通知。

监控

监控指的是监控主从节点的状态，检测他们是否出现故障。它通过每隔1秒给redis节点与哨兵节点周期性的发送PING消息，同时等待PONG回复，如果在down-after-milliseconds毫秒时间内，没有收到PONG回复，就会标记节点为主观下线。如果哨兵标记为主观下线的节点为主节点，那么就会向其他哨兵节点发送is-master-down-by-addr命令，交换主节点的下线状态。

sentinel is-master-down-by-addr ip port current_epoch runid
ip 是主节点的IP
port 是主节点的端口
current_epoch是当前配置纪元
runid 当其值为*的时候，表示与其他哨兵节点交换主节点的下线状态，当值为哨兵节点的runid时，表示请求其他哨兵节点推举自己为leader进行选主与主从切换

当哨兵收到超过quorum数量的哨兵节点的确认主节点下线应答，就会标记主节点的状态为客观下线。

故障转移

哨兵使用raft算法作为领导者选举的算法。当哨兵标记主节点为客观下线后，会给自己投上一张选票，同时给其他哨兵节点发送is-master-down-by-addr命令，请求其他哨兵节点选择自己为leader，进行主从切换。当哨兵收到超过quorum数量且超过过半数哨兵节点的确认投票，就会推举自己为领导者，进行主从切换。如果哨兵在failover-timeout超时时间内没有选出领导者，就会等待至少2failover-timeout的超时时间再次发起领导者选举。通常领导者选举这个过程很快，因为不同的哨兵节点标记主节点客观下线通常不会再同一时刻。
哨兵实例成为领导者后，遵从如下的规则选择出领导者：
1、优先选择网络状态比较好的从节点。如果哨兵在5秒内没有收到从节点的PONG应答或者从节点与主节点失联超过10down-after-milliseconds，就会被过滤掉。
2、优先选择优先级高的从节点，redis提供了配置参数slave-priority选项，用于控制优先级，redis主从节点我们一般配置相同的硬件，为此他们的值通常都相同。
3、优先选择复制进度靠前的从节点，哨兵通过给从节点，发送info命令得到slave-repl-offset的值，这个值是单调递增的，值最大的节点即为复制进度最靠前的节点。
4、最后选择runid最小的从节点。
哨兵leader选出redis新主节点后，会对其发送slaveof on one命令，使其成为主节点。
然后向其他节点发送命令，让其成为新的主节点的从节点，复制的并行度受参数parallel-sync控制，这个值不能太大，否则会导致主节点压力过大。
最后哨兵集群会标记旧主节点为从节点，当它故障恢复后，命令它为新主节点的从节点。
当如上的步骤都执行完，故障转移完成，主从集群可以正常提供服务。如果redis实例过大，那么整个故障转移的耗时将会很长，为此redis当个实例的规模不能过大，合理的大小是2到4GB。
需要注意的是failover-timeout作用于故障转移的各个阶段：
1、哨兵领导者选举
2、新主节点选择
3、命令新主节点成为主节点
4、命令其他从节点为新主节点的从节点，这里并不包括数据复制的时间。

通知

哨兵本质上也是一个redis实例，它是一个特殊的redis实例，只支持部分命令，它也可以提供发布订阅功能。实际上哨兵就是通过发布订阅功能，实现通知功能。
当哨兵标记节点主观下线、退出主观下线、客观下线、故障转移的各个过程与故障转移完成都会往相应的channel发布消息，客户端或者其他哨兵节点可以通过订阅channel感知到各个状态。
我列出了如下的常用的订阅频道：

频道	说明
+sdown	标记主观下线
-sdown	退出主观下线
+odown	标记客观下线
-odown	退出客观下线
+slave-reconf-sent	领导者命令从节点从新的主节点复制数据
+slave-reconf-proc	从节点成为新的主节点，但正在复制中
+slave-reconf-done	从节点完成了和新主节点的同步
+slave	一个新的从节点被发现
+switch-master	故障转移完成，更新新旧主节点信息
+reset-master	主节点被重置
+try-failover	故障转移开始
+failover-end	故障转移顺利完成
+failover-end-for-timeout	故障转移由于超时而完成

哨兵配置

哨兵提供了如下的配置选项：

port sentinel_port
dir	/opt/redis/data
sentinel monitor master_name master_ip master_port quorum
sentinel down-after-milliseconds master_name 10000
sentinel parallel-sync master_name 2
sentinel failover-timeout master_name 5000

它们的作用上文已经介绍了，这里不再赘述。需要注意的是：
1、如果down-after-milliseconds设置的过小，存在误判的情况，如果设置的过长，故障恢复的时间就会过长。
2、如果failover-timeout设置的过小，故障转移可能会频繁的失败，导致无法完成故障转移，如果过长，故障转移失败可能需要过长时间才检测出。
3、parallel-sync如果设置的过大，故障转移过长中，主实例的压力可能过大，故障转移耗时可能反而变长。

监控原理

1、Redis主节点提供了pubsub channel：

__sentinel__:hello

哨兵会每个2秒向主节点的这个频道发布本哨兵节点的如下信息：

<sentinel_IP> <sentinel_port> <sentinel_runid> <sentinel_current_epoch> <master_name> <master_ip> <master_port> <master_epoch>

哨兵节点同时还会订阅该频道，以获取最新的主节点信息与其他哨兵节点信息。
2、哨兵会每隔10秒，向redis主节点与从节点发送info命令，获取最新的主从集群的拓扑结构。
3、哨兵会每隔1秒，向主节点、从节点与其他哨兵节点发送ping消息，如果他们在down-after-milliseconds毫秒内，没有收到pong答复，就会标记他们为主观下线。
哨兵通过如上的三个监控任务，都发现了所以的哨兵节点与主从节点，并且有他们都建立了连接。

哨兵集群个数

Reds通过哨兵，保证了主从集群的高可用。但是如果哨兵节点的个数如果配置不合理同样会影响哨兵的高可用，从而影响集群的高可用。
我们一般给哨兵集群配置3个或者5个节点，并且设置quorum的个数为哨兵个数+1，也就是设置为2或者3。这样对于3个哨兵节点的集群，就允许一个节点故障。同样的5个哨兵节点的集群，允许2个哨兵节点故障。从而保证哨兵的高可用。