Redis哨兵机制

Redis哨兵机制

一. Sentinel介绍

‘’
　　1.Sentinel，中文为哨兵，是Redis集群架构中一个非常重要的组件。
　　2.主要功能：
　　　　１.集群监控　　 负责监控主从服务器进程是否正常工作
　　　　２.故障转移（failover）　　如果master宕机，会自动从slave中选举出新的master,进行主从自动切换。
　　　　３.配置中心 如果发生了故障转移，sentinel负责通知客户端新的master地址。
　　　　４.消息通知如果某个redis节点有故障，sentinel会发生报警消息给系统管理员。
　　3.目前采用的是sentinel2版本，sentinel2相对sentinel1来说，重写了很多代码，主要是让故障转移机制和算法变得更加健壮和简单。

二. Sentinel基础知识

1.sentinel至少要部署2n+1(n>=1)个节点，来保证自身的健壮性。
　　2.sentinel + 主从的部署架构，并不能保证数据的领丢失，只能保证redis集群的高可用性。
　　3.对于sentinel + 主从这种复杂的架构，应尽量在测试环境和生产环境进行充分的测试和演练。

三.经典的3节点的哨兵集群

"
　　 1.部署架构
　　　　１个master和2个slave节点，且每台Redis节点上都部署一个sentinel。
　　　　
2.配置

#Sentinel配置，quorum表示多少个Sentinel节点认为Master宕机后，开始进行故障转移。一般quorum=2
sentinel monitor <Master-name> <ip> <redis-port> <quorum>

3.如果master宕机了，那么sentinel2或sentinel3检测到master宕机，会发生主观宕机，然后进行一次选举。由于剩余的Sentinel数量=2，大于majority,当sentinel2和sentinel3都投票通过后，quorum=2，即可进行故障转移。

四.主从架构下数据丢失问题

"
　　1.异步复制导致数据丢失
　　　　由于master到slave的数据复制是异步的，当master接受了客户端的一些写请求，将数据写入到本地缓存中，如果再数据复制成功之前，master意外宕机了，数据未成功同步到slave，就会导致这部分新写入的数据丢失。
　　２.集群网络分区导致的数据丢失
　　　　ａ.网络分区（脑裂）：指在一个高可用（HA）集群中，当本来处于连接状态的两个节点断开时，本来为一个整体系统，分裂为两个独立的节点，这两个节点开始竞争共享资源，结果导致系统混乱，数据损坏。
　　　　 b.在redis主从环境下，如果某个master突然脱离了正常的网络，无法与其余slave保持通信，这时，slave节点就会认为Master宕机(实际master服务器仍在运行)，重新选举一个slave为master。但此时，可能 client 还没来得及切换到新的 master，还继续向旧 master 写数据。因此旧 master 再次恢复的时候，会被作为一个 slave 挂到新的 master 上去，自己的数据会清空，重新从新的 master 复制数据。而新的 master 并没有后来 client 写入的数据，因此，这部分数据也就丢失了。
　　3.解决方案
　　 配置：

　　  #当Master向Slave同步数据时，如果有超过N个Slave同步的时间超过M，则Master就会停止对客户端的服务
　　　min-Slaves-to-write N
　　　min-Slaves-max-lag M

五. Sentinel底层原理

"
1.sdown VS odown
　　1.sdown:主观宕机，即一个Sentinel节点认为Master宕机了，当Sentinel ping master时，超过is-Master-down-after-milliseconds时间后，没有收到响应，则认为master主观宕机了。
　　2.odown：客观宕机，如果quorum数量的Sentinel都觉得Master宕机了，那么就是客观宕机。如果一个Sentinel在指定的时间内收到quorum数量的Sentinel认为Master宕机了，那整个Sentinel集群就认为Master宕机了。
２.Sentinel集群的自动发现机制
　　哨兵互相之间的发现，是通过redis的pub/sub方式实现的，每个哨兵都会往_sentinel_:hello这个chanel里发送一条消息，这个时候所有其他哨兵都可以消费这个消息，并可以感知到其他哨兵的存在。
每隔2秒钟，逗哥哨兵都会往自己监控的某个Master + slaves对应的_sentinel_:hello里发送一条消息，内容是自己的host、ip和runid,还有对这个Master的监控配置。
　　每个哨兵也会去监听自己监控的每个Master+Slaves对应的_sentinel_:hello channel，然后去感知到同样在监听这个Master+Slaves的其他哨兵的存在。

每个哨兵还会跟其他哨兵交换对Master的监控配置，互相进行监控配置的同步。
３.slave配置的字段修正
　　　当重新选举出新的Master之后，Sentinel会自动修改slave的配置，指定新的Master路由。

４.Master选举

如果一个Master odown了，并且majority数量的Sentinel都允许了主从切换，则会由一个Sentinel进行Master的选举和切换。Master选举主要考虑以下因素：

１.跟master断开连接的时长：如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master。
　　２.配置的slave优先级：slave priority越小，优先级就越高。
　　３.数据复制的offset：如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset就越大，优先级就越高。
　　４.runid：如果上面两个条件都相同，那么选择一个runid比较小的那个slave。
　　
　　
５.quorum & majority

如果Sentinel集群要进行主备切换，首先要有quorum数量的Sentinel任务master sdown。然后需要选举出一个Sentinel来执行主从切换操作。这个被选举出的Sentinel必须获得majority数量的Sentinel的授权后，才能开始执行主从切换操作。

如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换。

但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换。

转载自原文：https://blog.csdn.net/weixin_34452850/article/details/90174389