【分布式缓存-HA篇】Redis Sentinel 模式

        一、 Redis Sentinel 简介

        Redis Sentinel（哨兵）是Redis官方推荐高可用方案，它的作用是对Redis节点进行监控、故障判断、故障转移、故障通知。

        二、 Redis Sentinel 架构

Redis Sentinel 管理架构

        1 工作原理

        对于Redis的主从架构，Sentinel会运行几个sentinel进程，这些进程不操作数据，专门用来进行Redis的故障判断、故障转移，同时多个sentinel进程运行，如果其中一个进程出现问题，还有其它进程可以用来继续监控Redis状况，并保障Redis的高可用。

        对于Redis客户端来说，客户端不会再记录Redis的ip、port等信息，而是从Sentinel获取Redis信息，然后进行连接Redis节点，进行数据操作。

客户端从Sentinel获取Redis信息

        2 故障转移过程

        【步骤一】 主观下线： Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线，如果在约定的时间内没有响应，则该Sentinel节点主观认为这个Redis实例已下线，然后进行客观下线阶段；

        【步骤二】 客观下线：当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线，它会向同样监视这一主服务器的其它Sentinel进行询问，看它们是否也认为主服务器已经进入了下线状态。当从其它Sentinal那里接收到足够数量（quorum配置）的已下线判断后，Sentinel就会将服务器判定为客观下线，开始对主服务器执行故障转移操作，然后进入故障转移阶段；

        【步骤三】 领导选举：每个做了主观下线的Sentinel节点向其它节点发送命令，要求将自己设置为领导者；收到命令的节点如果没有同意过其它节点发送的命令，则会同意这次请求，反之则拒绝；如果Sentinel节点发现自己的得票数已经超过总结点数的一半、并且超过quorum（提前配置好的阀值），则会成为领导者；如果在上述过程中多个Sentinel节点成为领导者，则会进行重新选举；

        【步骤四】 故障转移：从Redis的所有Slave中选举出符合条件的一个节点，作为新的Master节点，然后向剩余Slave节点发送命令，通知它们成为新Master节点的Slave，然后所有Slave都会从新Master同步数据；待出问题的节点（原Master节点）复活后，其也会成为新Master节点的Slave，并从Master节点同步新数据。

Redis Sentinel 模式下的故障转移

        三、Redis Sentinel 中的定时任务

        1  获取主服务器信息

        Sentinel默认会以每十秒一次的频率，通过命令连接向被监视的主服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息。

获取实例信息

        2  Sentinel交换消息

        Sentinel所有节点会以每两秒一次的频率，通过Redis的Master节点的Channel来交换信息，这个过程也叫作发布订阅；

        Redis的Master节点上有一个发布订阅的Channel频道：_sentinel_:hello，用于所有Sentinal之间进行信息交换；Sentinal发布的消息中包含了当前Sentinel自身节点的信息，对其它Sentinel节点的判断、以及对Redis的Master节点和Slave节点的判断，其它Sentinel节点都会收到这条消息；当有新的Sentinel节点加入时，其它Sentinel也是通过这种方式感知到。

Sentinel 交换消息

        3  故障判断

        Sentinel会以每秒一次的频率，向所有与它创建了命令连接的实例发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。

判断是否健康