Redis进阶：哨兵工作原理（图+文，第一部分）

1 缘起

关于Redis哨兵工作原理，我打算分两部分分享，
第一部分看图说话，作为Redis哨兵原理讲解的排头兵，易于记忆和理解；
第二部分源码讲解，深入学习Redis如何实现哨兵并哨兵实现故障转移。
本文即第一部分，以图讲解Redis哨兵通信以及故障转移，
帮助读者轻松应对知识考核与交流。
第二篇文章：
Redis进阶：源码详解哨兵模式工作原理（图+文+源码，第二部分）:https://blog.csdn.net/Xin_101/article/details/127306613

2 哨兵工作原理

高可用是在线服务可用性的衡量指标，比如可用性99.9%，99.99%，99.999%，
什么意思呢？
按照运行时间计算，服务允许不可用时间计算公式：
$$服务允许不可用时间=总运行时间\ast (1-可用性)$$
比如一天24小时=1440分钟，
可用性99.9%，即服务允许的不可用时间=1440分钟*(100%-99.9%)=1.44分钟，
系统分布式设计即是提高高可用的实际应用，
不同的系统有不同的高可用方案，
本文讲解Redis高可用方案：哨兵Sentinel。

2.1 哨兵集群通信

Redis的哨兵高可用方案有两块核心内容，
第一块是哨兵集群中哨兵通信，
第二块是哨兵与Redis服务实例同信。
这部分讲解哨兵间通信。

• 哨兵间通信目的
  传递Redis服务的信息，然后进行仲裁，决定Rdeis服务的主节点在线与否，如果判定当前主节点ODOWN，则进行故障转移。

• 哨兵间通信结构
  哨兵间通信结构如下图所示，
  由图可知，哨兵间通信通过Channel：__sentinel__:hello。
  

哨兵间传递的消息是肩负着Redis集群高可用的重任，
因此，消息应包含主节点运行状态、主节点主机名和端口、主管下线时长和客观下线时长、从节点信息以及故障转移状态等等，既保证哨兵之间可以定期交换主节点的运行时状态数据，又保证主节点的选举以及故障转移相关操作。
这里挑选了哨兵间传递的部分数据，如下表所示。

序号	属性	描述
1	flags	Sentinel定义的标识位
2	name	主节点名称（哨兵角度）
3	runid	当前实例运行ID或哨兵唯一ID
4	addr	主节点主机名
5	link	哨兵与实例的通信链接
6	s_down_since_time	主管下线时长
7	o_down_since_time	客观下线时长
8	master	从节点保存的主节点信息
9	slaves	从节点信息
10	slave_master_host	INFO报告的主节点主机名
11	slave_master_port	INFO报告的主节点端口
12	slave_master_link_status	INFO报告的主节点状态
13	leader	如果是主节点，leader是应该执行故障转移的哨兵runid
14	failover_state	故障转移状态

2.2 故障转移

2.2.1 哨兵与主节点通信

该部分讲解哨兵与主节点通信。

• 通信目的
  为了确认当前主节点的运行状态，
  哨兵向主节点发送状态诊断过程，称为PING，
  主节点响应哨兵的过程，称为PONG，
  类似乒乓球的一个回合，整个过程如下图所示。
  

• 主节点响应
  每个哨兵都会记录各自与主节点通信的结果，主节点可读的响应结果有三种，分别为：
  PONG、LOADING和MASTERDOWN，哨兵会根据可读的信息做进一步处理，
  PONG：判定主节点正常，无需向其他哨兵确认主节点状态；
  LOADING：主节点正在载入，会周期性向主节点发送诊断信息，如果主节点为PONG则无需其他操作；
  MASTERDOWN：主节点下线，这里有SDOWN（Subjectively Down）和ODOWN（Objectively Down），即主管下线和客观下线，如果发现下线，当前哨兵会与其他哨兵通信，对主节点状态作最终判定，以及故障转移操作。
  如果Redis主节点无响应，主节点会标识自身为BUSY。

2.2.2 哨兵间二次通信

该部分讲解哨兵间二次通信。

• 通信目的
  当哨兵集群需要检测当前主节点的运行状态时，
  哨兵间相互传递获取的主节点信息，
  以此判定当前主节点的运行状态，是SDOWN或者ODOWN。
  为避免偏听偏信，Redis采用兼听则明的施政方针。
  如果某个哨兵发现主节点MASTERDOWN或者无响应，先将该主节点判定为主管下线，然后，再与其他哨兵进行二次通信，交换关于主节点的信息，进一步确认主节点当前的运行状态，这涉及到quorum即同时确认主节点处于相同状态的哨兵个数。
  其中，quorum实在启动哨兵时配置的个数。

• 哨兵二次通信过程
  上面阐述了哨兵间的二次通信目的，这里阐述哨兵间二次通信的流程，完整流程如下图所示。
  由图可知，哨兵先与主节点通信，即PING过程，此时，主节点有两种处理策略，响应或者不响应哨兵的请求。这里从主节点不响应哨兵请求入手，分析哨兵如何确认主节点ODOWN以及故障转移。
  当主节点不响应哨兵的PING时，哨兵A会认定当前主节点SDOWN，此时，哨兵A需要进一步询问哨兵B主节点的状态，哨兵B同样会向主节点发送PING，如果同样没有响应，哨兵B认定主节点SDOWN，哨兵A与哨兵B同时确认主节点SDOWN，quorum达到设定的2，此时认定主节点ODOWN，哨兵会重新选举主节点，完成故障转移。
  

3 小结

（1）Redis保证集群高可用的方案之一：哨兵；
（2）Redis哨兵方案中，有两部分通信：哨兵间通信以及哨兵与主节点的通信；
（3）哨兵间通信用于传递集群中Redis实例的信息以及实现故障转移；
（4）主节点故障时有两种状态：SDOWN和ODOWN，当主节点被quorum个哨兵判断为ODOWN时，才会重新选举主节点，进行故障转移；
（5）哨兵与主节点通信，首先确认SDOWN，然后，哨兵间通信，其他哨兵同时确认主节点为SDOWN，数量达到配置的quorum时，判定主节点ODWON。