Redis学习笔记--哨兵

哨兵

 

是什么？

哨兵是吹哨人，用于巡查主从节点运行状态，查看各节点是否故障，哨兵是不存放数据的，哨兵的出现是为了解决主从复制模式下无法实现高可用导致数据丢失的致命问题，哨兵是建立在主从模式基础上的，如果主节点出现故障会根据投票数自动将一个从节点选举为主节点用来接替已经故障的主节点，继续对外提供服务。俗称，无人值守，高可用哨兵，非集群。哨兵架构图如下：

 

能干嘛？

1、主从监控：监控主从节点运行是否正常。

2、消息通知：哨兵可以将故障转移的消息发送给客户端。

3、故障转移：如果主节点异常，会进行主从切换，在多个正常的从节点中选举出一个新的主节点来

4、配置中心：客户端通过连接哨兵来获取主节点的地址

 

故障转移流程：

以下整个故障转移流程都是Sentinel自动完成的，无需人工干预。

0、当主节点被客观下线后，各个哨兵会进行协商，根据Raft算法选举出一个Sentinel leader，Sentinel leader会处理后续的故障转移（新master的选举）。

1、读取多个从节点的redis.conf文件中配置的优先级（replica-priority）选择优先级最高的当做新的主节点（配置的数字越小优先级越高）如果优先级一致则进行下一轮比较

2、读取多个从节点的复制偏移量offset，选择偏移量最大的那个，因为偏移量大说明从旧的主节点更新的数据多，它的数据会更加完整一些。如果它们的偏移量均一致则进行下一轮比较

3、最小的Run ID获取最大的那个选举它为新的主节点，根据字典顺序Ascii编码，Run ID是在redis启动的时候生成的用于标识当前redis的唯一性。

4、Sentinel leader对新选举出来的主节点做slaveof no one命令，将其提升为master节点。

5、Sentinel leader向其它slave发送命令，让剩余的slave做新master的从节点。

6、后续老的master重新上线，Sentinel leader会让老的master进行降级，做新的master的从节点。

选举流程图

 

主观下线：

主观下线是指单个Sentinel主观的监测到有关master的状态异常，从Sentinel的角度看，在给master发送ping心跳后，在配置文件指定的时间（Sentinel配置文件中down-after-milliseconds设置主观下线时长）内没有得到回复，Sentinel就会主观的认为master异常。这就是主观下线。配置文件如下图所示：

 

客观下线：

客观下线是建立在主观下线的基础上的，当一个Sentinel认定master故障是不可取的，可能因为网络抖动导致主观下线，当一定数量的Sentinel认为master异常，它们在达成一致意见后才能认定master已经出现故障了。quorum这个参数是进行客观下线的一个依据，法定人数/法定票数。至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。

 

优缺点：

优点：

1、故障转移自动化/高可用：哨兵可以持续监控主节点状态，主节点故障后可以选一个新的主节点出来并更新其它从节点配置。

2、集群监控：哨兵可以监控多个redis的主从节点，出现故障可以及时发出警告，方便管理员及时处理。

3、易部署：哨兵配置相对简单，通过配置文件即可实现，易于部署和管理。

 

缺点：

1、功能有限：只能做简单的故障转移，对于一些复杂的场景处理能力有限。

2、不支持多数据中心部署：哨兵通的故障转移依赖节点之间的网络通信，跨数据中心的部署可能因为网络延迟引发通信问题。

3、数据丢失：哨兵监测到主节点故障后，哨兵的Raft算法选举和新主节点的选举需要消耗时间，选举过程中的数据会出现丢失的情况。

从一些我没考虑到的角度来讲解哨兵模式

 

哨兵使用建议：

1、哨兵个数应当是奇数个。便于选举，哨兵本身最好是集群保证高可用

2、部署哨兵的机器在硬件配置上要保持一致，避免因为配置问题引起性能问题，引发不必要的麻烦。

3、哨兵集群+主从模式，是无法保证数据不丢失的