显示器|Redis高可用架构—哨兵(sentinel)机制详细介绍

显示器|Redis高可用架构—哨兵(sentinel)机制详细介绍

文章图片

显示器|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 永远不会达到客观下线条件 。
当redis master被标记为客观下线时 , 每个sentinel向其他slave节点发送info命令的频率由之前的10秒钟一次变为1秒钟一次 。 并且会通过raft算法在sentinel中选出一个leader , 由leader节点完成redis的故障转移工作 。