显示器|Redis高可用架构—哨兵（sentinel）机制详细介绍数码

文章图片

文章图片

什么是Redis sentinel上篇文章Redis高可用方案—主从（masterslave）架构中我们了解了Redis的主从复制模式的原理及其搭建方式，知道了它具有数据的多机备份和数据的读写分离的好处。但主从复制架构有一个缺陷，就是当master节点发生故障后，无法自动实现故障转移，需要人手动从slave节点中选择一个作为master节点继续提供服务。而本篇文章要介绍的Redis哨兵机制就解决了这一问题。
哨兵（sentinel）在Redis主从架构中是一个非常重要的组件，是在Redis2.8版本引入的。它的主要作用就是监控所有的Redis实例，并实现master节点的故障转移。哨兵是一个特殊的redis服务，它不负责数据的读写，只用来监控Redis实例。
Redis sentinel工作原理在哨兵模式架构中， client端在首次访问Redis服务时，实际上访问的是哨兵（sentinel）， sentinel会将自己监控的Redis实例的master节点信息返回给client端， client后续就会直接访问Redis的master节点，并不是每次都从哨兵处获取master节点的信息。
sentinel会实时监控所有的Redis实例是否可用，当监控到Redis的master节点发生故障后，会从剩余的slave节点中选举出一个作为新的master节点提供服务，并将新master节点的地址通知给client端，其他的slave节点会通过slaveof命令重新挂载到新的master节点下。当原来的master节点恢复后，也会作为slave节点挂在新的master节点下。如下图：

一般情况下，为了保证高可用， sentinel也会进行集群部署，防止单节点sentinel挂掉。当sentinel集群部署时，各sentinel除了监控redis实例外，还会彼此进行监控。如下图：

Redis sentinel是如何进行监控的要实现Redis节点的监控， sentinel首先要得到所有的Redis节点的信息。 sentinel通过在配置文件中配置 sentinel monitor 选项来指定要监控的redis master节点的地址，然后在启动sentinel时，会创建与redis master节点的连接并向master节点发送一个info命令， master节点在收到info命令后，会将自身节点的信息和自己下面所有的slave节点的信息返回给sentinel ， sentinel收到反馈后，会与新的slave节点创建连接，接下来就会每隔10秒钟向所有的redis节点发送info命令来获取最新的redis主从结构信息。
有了redis实例的主从信息后， sentinel就会以每秒钟一次的频率向所有redis实例发送一个PING命令，而且如果sentinel是集群部署的话，每个sentinel还会以同样的频率向其他sentinel实例发送PING命令。当redis实例和sentinel实例收到PING命令后，会向sentinel返回一个有效的回复：+PONG 、-LOADING 或者 -MASTERDOWN ，若返回其他的回复，或者在指定时间内（sentinel down-after-milliseconds 选项配置）没有回复，那么sentinel认为实例的回复无效。如果实例在 sentinel down-after-milliseconds 时间内未返回过一次有效的回复，那该实例就会被sentinel标记为主观下线（Subjectively Down ，简称 SDOWN ，指的是单个 sentinel 实例对服务节点做出的下线判断）。
当redis master节点被足够数量（sentinel monitor 选项配置，其中的quorum即为指定的sentinel数量，下面会详细介绍相关参数）的sentinel标记为主观下线后，那么master节点就会被标记为客观下线（Objectively Down ，简称 ODOWN ，指的是多个 sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断。【一个 sentinel 可以通过向另一个 sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线】）。客观下线条件只适用于主服务器：对于任何其他类型的 Redis 实例， sentinel 在将它们判断为下线前不需要进行协商，所以slave服务器或者其他 sentinel 永远不会达到客观下线条件。