Redis(哨兵模式)
什么是哨兵机制
- 问题: redis 主从复制模式下, 一旦主节点由于故障不能提供服务, 需要人工进行主从切换, 同时大量客户端需要被通知切换到新的主节点上, 对于有一定规模的应用来说, 对于人力的资源消耗会很大.
- 解决: 通过哨兵对主从结构进行监控, 一旦出现主节点挂了的情况, 自动的选举新主节点, 搭建新主从结构, 并主动通知客户端进行主节点切换.
哨兵机制核心功能
- 监控 (哨兵机制通过独立的 redis - sentinel 进程体现, 负责对 redis - server 进程的进行监控)
- 自动的故障转移(主节点挂了哨兵机制能够自动选举新的主节点,重构主从结构)
- 通知
哨兵机制执行流程
哨兵机制对主节点进行 监控 , 当主节点挂了的时候
- 先查看已挂的主节点能否抢救
- 如果不能抢救, 就需要挑一个从节点, 以它为主节点重新建立主从结构
2.1 对选中的从节点, 设置slaveof no one命令,将其设置为主节点
2.2 把其他从节点, 修改slaveof的主节点 ip, port , 让它们连上新的主节点- 通知客户端, 让客户端连接新的主节点 (修改客户端配置)
对于已挂的主节点, 修复完成后, 挂到新的主从结构中作为 从节点 存在
Redis Sentinel 架构
哨兵节点集合监控现有的 redis master 和 slave (通过 TCP 长连接) (监控方式为 心跳包机制)
当哨兵节点集合超半数认为主节点挂了之后 (用集合就是为了方式单个哨兵 误判 )
哨兵集合内部选举出一个 leader ,由 leader 挑选出一个新主节点
哨兵节点控制 新主从结构 的搭建
完成后, leader 主动通知客户端, 告知新的主节点
哨兵重新选举 主节点 流程
- 主观下线
单个哨兵通过心跳包判定 redis 挂了 (可能是真挂了, 可能是网络波动…)- 客观下线
超半数哨兵认为 redis 主节点挂了, 此时就会采取补救措施- 哨兵节点集合 选举 leader
谁的网络延迟小, 最先发现主节点挂了之后, 就会先投自己一票, 并通知其他哨兵节点, 让他们也投自己 (拉票)
(ps: 哨兵节点的个数通常设置为奇数 3/5/7, 就是为了防止选 leader 时出现 1:1 , 2:2 … 的情景, 导致无法选出新 leader )
当某个节点的票数超过法定票数的一半 (2/3 , 4/5 …) , 该哨兵就会晋升为 leader- leader 选举完成, 由 leader 选出一个从节点, 作为新的主节点, 并搭建新的主从结构
leader 挑选 从节点 遵循三个原则:
4.1 优先级 : 在配置文件中:slave-priority, 优先级最高者, 会被选中
4.2 offset : 同步进度最多者, 会被选中
4.3 run id : 每个 redis - server 进程, 会被随机分配一个 run id