Redis集群 - Sentinel与RAFT算法

引入

  在主从模型中讲到

一旦Master宕机失效，须要手动将Slave角色提高为Master，不然这个子集群将不可用。

  这个缺陷使得系统可用性大大下降。所以Redis专门提供了一个哨兵机制来实现自动故障检测和转移。

什么是哨兵

  哨兵（Sentinel）是一种特殊的Redis实例，与Redis存储实例同样，哨兵一样是基于配置的。
  你能够经过如下两种方式启动哨兵：

redis-sentinel /path/to/sentinel.conf
    redis-server /path/to/sentinel.conf --sentinel

哨兵须要作什么

• 监控节点状态
• 当Master节点故障时，自动提高Replication（Slave）为Master
• 发送故障通知
• 配置传播（就是把更新后的集群配置传播给其余哨兵进行更新，保持一致性）

怎么实现

• 节点监控
    如图（图中S为Sentinel，M为Master，R为Replication即Slave），Sentinel模型集群中的每一个Sentinel都在监控着每一个节点，每隔一段时间会向每一个节点发送PING，经过返回的PONG信息确认节点正常。
  

  
    Sentinel与监控的节点之间实现了SUB/PUB（发布订阅）机制，每次Sentinel发布PING消息只须要在频道上发布并接收订阅者返回的消息。

• 故障检测与Failover
    在这里有两个重要概念：主观下线（sdown）以及客观下线（odown）。由于Sentinel的数量>=2，而且每一个Sentinel都在监控着每一个节点，所以Sentinel与节点之间的链接都存在着主观性，这个主观性取决于Sentinel与节点之间的网络连通性。对于单个Sentinel而言，当其经过PING发现某个节点无反应时，其认为节点为下线状态，因为这个决定是这个Sentinel主观认为的，所以将此决断称为主观下线（sdown）。当Sentinel中认为某个节点主观下线的数量超过某个值时：
  • 1.投票选举Sentinel
  • 2.选出Slave，提高为Master，并将更新后的配置广播给其余Sentinel，Master将同步下属Slave数据

参考文献

  [1]redisLab.[EB/OL]. https://redis.io/topics/sentinel. 2019.01-2019.03.