Redis哨兵机制

Redis哨兵机制

一. Sentinel介绍

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

二. Sentinel基础知识

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

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

1. 部署架构 1个Master节点，2个Slave节点，且每台Redis几点上都部署一个Sentinel：

在这里插入图片描述

1. 配置 #Sentinel配置，quorum表示多少个Sentinel节点认为Master宕机后，开始进行故障转移。一般quorum=2 sentinel monitor <Master-name> <ip> <redis-port> <quorum>
2. 如果Master宕机了，那么Sentinel2或Sentinel3检测到Master宕机，会发起主观宕机，然后进行一次选举。由于剩余Sentinel数量=2，大于majority，当Sentinel2和Sentinel3都投票通过后，quorum=2，即可以进行故障转移。

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

1. 异步复制导致的数据丢失：
   1. 由于Master到Slave的数据复制是异步的，当Master接受了客户端的一些写请求，将数据写入本地缓存中时，如果在数据复制成功之前Master意外宕机了，数据未成功保存到Slave，就会导致这部分新写入的数据丢失。
2. 集群网络分区导致的数据丢失
   1. 网络分区(脑裂)：指在一个高可用(HA)系统中，当本来处于连接状态的两个节点断开连接时，本来为一个整体的系统，分裂为两个独立的节点时，这两个节点开始竞争共享资源，结果会导致系统混乱，数据损坏。
   2. 在Redis主从环境下，如果某个Master突然脱离了正常的网络，无法与其余Slave保持通信，这时Sentinel节点就会认为Master(实际上Master仍然在运行)，重新将一个Slave选举成Master。但是此时，client仍然将数据写入原来的Master，这样当网络恢复时，原来的Master会作为一个Slave重新加入集群，并从新的Master上同步数据，就会造成新写入的数据的丢失。
3. 解决方案 配置： #当Master向Slave同步数据时，如果有超过N个Slave同步的时间超过M，则Master就会停止对客户端的服务 min-Slaves-to-write N min-Slaves-max-lag M 通过这个配置，限制了Slave与Master之间数据不一致的程度，将数据丢失限制在了一个可控范围内。

五. 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 sdown了，则整个Sentinel集群认为Master客观宕机。
2. Sentinel集群的自动发现机制 哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往_sentinel_:hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在。 每隔2秒钟，每个哨兵都会往自己监控的某个Master+Slaves对应的_sentinel_:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个Master的监控配置。 每个哨兵也会去监听自己监控的每个Master+Slaves对应的_sentinel_:hello channel，然后去感知到同样在监听这个Master+Slaves的其他哨兵的存在。 每个哨兵还会跟其他哨兵交换对Master的监控配置，互相进行监控配置的同步。
3. Slave配置的自动修正 当重新选举出新的Master后，Sentinel会自动修改Slave的配置，指定新的Master的路由。
4. Master选举 如果一个Master odown了，并且majority数量的Sentinel都允许了主从切换，则会由一个Sentinel进行Master的选举和切换。Master选举主要考虑以下因素：
   1. 跟master断开连接的时长：如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master。
   2. 配置的slave优先级：slave priority越小，优先级就越高。
   3. 数据复制的offset：如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset就越大，优先级就越高。
   4. runid：如果上面两个条件都相同，那么选择一个runid比较小的那个slave。
5. 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个哨兵都同意授权，才能执行切换。