做自适应网站对设计稿的要求今天军事新闻最新消息

什么是哨兵机制

• 问题: redis 主从复制模式下, 一旦主节点由于故障不能提供服务, 需要人工进行主从切换, 同时大量客户端需要被通知切换到新的主节点上, 对于有一定规模的应用来说, 对于人力的资源消耗会很大.
• 解决: 通过哨兵对主从结构进行监控, 一旦出现主节点挂了的情况, 自动的选举新主节点, 搭建新主从结构, 并主动通知客户端进行主节点切换.

哨兵机制核心功能

1. 监控 (哨兵机制通过独立的 redis - sentinel 进程体现, 负责对 redis - server 进程的进行监控)
2. 自动的故障转移(主节点挂了哨兵机制能够自动选举新的主节点,重构主从结构)
3. 通知

哨兵机制执行流程

哨兵机制对主节点进行 监控 , 当主节点挂了的时候

1. 先查看已挂的主节点能否抢救
2. 如果不能抢救, 就需要挑一个从节点, 以它为主节点重新建立主从结构
   2.1 对选中的从节点, 设置 slaveof no one 命令,将其设置为主节点
   2.2 把其他从节点, 修改 slaveof 的主节点 ip, port , 让它们连上新的主节点
3. 通知客户端, 让客户端连接新的主节点 (修改客户端配置)

对于已挂的主节点, 修复完成后, 挂到新的主从结构中作为 从节点 存在

Redis Sentinel 架构

哨兵节点集合监控现有的 redis master 和 slave (通过 TCP 长连接) (监控方式为 心跳包机制)
当哨兵节点集合超半数认为主节点挂了之后 (用集合就是为了方式单个哨兵 误判 )
哨兵集合内部选举出一个 leader ,由 leader 挑选出一个新主节点
哨兵节点控制 新主从结构 的搭建
完成后, leader 主动通知客户端, 告知新的主节点

哨兵重新选举 主节点 流程

1. 主观下线
   单个哨兵通过心跳包判定 redis 挂了 (可能是真挂了, 可能是网络波动…)
2. 客观下线
   超半数哨兵认为 redis 主节点挂了, 此时就会采取补救措施
3. 哨兵节点集合 选举 leader
   谁的网络延迟小, 最先发现主节点挂了之后, 就会先投自己一票, 并通知其他哨兵节点, 让他们也投自己 (拉票)
   (ps: 哨兵节点的个数通常设置为奇数 3/5/7, 就是为了防止选 leader 时出现 1:1 , 2:2 … 的情景, 导致无法选出新 leader )
   当某个节点的票数超过法定票数的一半 (2/3 , 4/5 …) , 该哨兵就会晋升为 leader
4. leader 选举完成, 由 leader 选出一个从节点, 作为新的主节点, 并搭建新的主从结构
   leader 挑选 从节点 遵循三个原则:
   4.1 优先级 : 在配置文件中: slave-priority, 优先级最高者, 会被选中
   4.2 offset : 同步进度最多者, 会被选中
   4.3 run id : 每个 redis - server 进程, 会被随机分配一个 run id