redis那点事5: 哨兵机制篇

redis大纲: 

    传送

 

我们先来回顾一下redis的主要功能

    哨兵机制、主从复制、支持事务、支持LUA脚本、支持持久化、支持集群  本章就来聊聊哨兵机制!

 

简单的说说哨兵机制的作用: 

    集群监控: 负责监控集群Master和Slave是否正常工作

    消息通知: 如果某个redis实例故障, 哨兵负责发送消息作为警报通知管理员

    故障转移: 如果Master Node挂了, 会自动转移到Slave Node上

    配置中心: 如果发生故障转移, 哨兵会通知client新的master地址

 

简单的说说哨兵的高可用

    当主节点发生故障时, 由哨兵自动完成故障的发现和转移, 并通知应用方, 实现高可用

    

简单的说说哨兵的工作流程 (简单)

    1. 哨兵机制建立了多个哨兵节点(进程), 共同监控数据节点的运行状况

    2. 同时哨兵节点之间也会互相通信, 交换对主从节点的监控状况

    3. 每隔一秒每个哨兵都会向整个集群 (Master节点+Slave节点+其他Sentinel)

        进程发送一次 PING 指令做一次心跳检测

    这就是哨兵节点判断节点是否正常工作的重要依据

    

    最终拓扑结构图: 

    

 

简单的说说哨兵的工作流程 (完整)

    1. 每个哨兵以每秒的频率向发所知的 master、slave、sentinel发送一个 PING 命令

    2. 如果节点响应 PONG 的时间如果超过了 down-after-milliseconds 指定的值, 

        那么这个节点就会被当前哨兵标记为主观下线状态

    3. 如果 master 被标记为主观下线的状态, 那么所有正在监控他的哨兵都会以每秒的速度发送PING指令

        确定是否进入了主观下线的状态

    4. 如果有足够多的 sentinel (大于等于配置的值) 确定 master 为主观下线的状态

        则 master 会被标记为客观下线的状态 

    5. 在一般情况下, sentinel 每10秒向他监控的 master、slave 发送 INFO 命令

    6. 当 master 被 sentinel 标记为客观状态的情况时, sentinel 会向已下线的 master 的所有 slave 

        发送 INFO 命令, 而且频率从每10秒一次变为每1秒一次

    7. 若没有足够多的 sentinel 同意 master下线, master 的客观下线会被移除, 若 master 重新向 sentinel

        发送的 PING 命令有效, master 的主观下线状态会被移除

 

简单的说说主观下线和客观下线的区别:

    主观下线:

        一个哨兵节点判定主节点挂掉是主观下线 (单方面)

    客观下线:

        如果有半数 (配置的值) 哨兵节点都判断主节点主观下线, 此时哨兵节点会交换判定结果,

        才会判断主节点客观下线 (真的下线了)

    原理: 

        哪个哨兵节点最先判断出主节点客观下线就会在各个哨兵节点中发起投票机制 Raft 算法(选举算法),

        最终被投为领导者的哨兵节点会去完成主从自动化切换的过程

 

简单的说说领导者的哨兵节点是如何选举的:

    1.  每个在线的哨兵节点都可以成为领导者, 比如哨兵3确认了主节点主观下线时, 他会向其他

        哨兵节点发送is-master-down-by-addr命令, 征求将自己设置为领导者, 由领导者 (他) 进行失败转移

    2. 当其他节点收到选举命令时可以同意也可以拒绝

    3. 如果哨兵3发现自己的票数大于等于 (sentinels) / 2+1时, 就会成为领导者, 如果没有达到则继续选举

    

    选举流程图:

          

      

简单的说说哨兵是如何进行失败转移的:

    1. 由 sentinel 节点监控主节点是否出现故障, sentinel 会向 master 发送心跳信息PING 来确定

         master是否存活, 如果master在一定时间没没有回复PONG或者回复了一个错误的信息,

        那么当前哨兵会单方面(主观)认为master挂了, 会要求其他sentinel进行确认这个master是否真的挂掉,

        如果确认挂掉, 则认为客观下线

    2. 当master客观下线, sentinel节点之间会进行选举领导者进行失败转移  (领导者一般是主观下线的发现者)

    3. 由哨兵领导者进行故障转移, 过程和主从复制一样, 但是是自动的

    4. 故障转移后会生成新的拓扑结构图

        (1). 过滤掉不健康的(下线或断线)、没有回复哨兵ping响应的从节点

        (2). 选择slave-priority优先级最高的节点

        (3). 如果没选到, 则会选择复制偏移量最大的(复制最完整)的从节点

 

    故障转以后的拓扑结构图:

         

      

简 3ff7 单的说说redis故障转移流程

    1. 将slave1脱离原节点, 升级为主节点 slaveof no one

    2. 将slave2指向新主节点的从节点 slaveof new master

    3. 通知客户端主节点已改变

    4. 将原来的主节点指向新主节点的从节点 slaveof new master

   

    故障转移流程图:

            

      

简单说说如何防止master在不安全的情况下执行写命令:

    配置: min-slaves-to-write 3

             min-slaves-max-lag 10 默认关闭

 

    该配置表示: 从服务器数量小于三个或者从服务器的延迟大于等于10s时, master将拒绝执行写命令,

         lag的值应该是0或1 如果高于1则证明主从连接有问题, slave的 lag 值可以通过 INFO replication命令查看

        在分布式的环境下可以进行配置, 合理的配置可以降低主从架构之间因为网络区间造成的数据不一致问题

      

简单说说redis是如何进行命令丢失检测是:

    如果发生网络故障, 主服务器发送给从服务器的命令丢失, 那么从服务器向主服务器发送

    REPLCONF ACK命令后, 主服务器的复制偏移量就会大于从服务器的复制偏移量,

    然后主服务器会根据从服务器小于自己的复制偏移量在 积压缓冲区 里寻找从服务器丢失的数据,

    并重新发送给从服务器

   

    主服务器向从服务器补发缺失数据的操作原理和部分重同步操作的原理相似,

    区别在于: 补发缺失数据的操作在主从服务器没有断线的情况下执行,

           而重同步操作则在主服务器和从服务器断开后 重新连接完毕后执行

      

简单说说redis心跳检测的作用:

    检测主服务器的网络连接状态, 实现辅助min-slave选项, 检测命令的丢失

      

简单说说redis心跳检测的流程:

    在命令传播阶段, 从服务器默认以每秒的速度向主服务器发送命令

    (REPLCONF ACK <offset>)   offset是从服务器的复制偏移量

 

结束

  这就是我对redis读哨兵机制篇的总结  感觉有用就点个赞吧 如果有错误或更好的方法评论区请多多指出  相互学习共同进步