Redis(哨兵模式)

什么是哨兵机制

• 问题: 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