石狮网站建设报价,百度爱采购怎么优化排名,水墨风格网站,python 和php网站开发目录 0.前言1.基本概念1.相关名词解释2.主从复制的问题3.人工恢复主节点故障4.哨兵自动恢复主节点故障 0.前言
说明#xff1a;该章节相关操作不需要记忆#xff0c;理解流程和原理即可#xff0c;用的时候能自主查到即可Redis的主从复制模式下#xff0c;⼀旦主节点由于故… 目录 0.前言1.基本概念1.相关名词解释2.主从复制的问题3.人工恢复主节点故障4.哨兵自动恢复主节点故障 0.前言
说明该章节相关操作不需要记忆理解流程和原理即可用的时候能自主查到即可Redis的主从复制模式下⼀旦主节点由于故障不能提供服务需要⼈⼯进⾏主从切换同时⼤量的客⼾端需要被通知切换到新的主节点上对于上了⼀定规模的应⽤来说这种⽅案是⽆法接受的 于是Redis从2.8开始提供了Redis Sentinel(哨兵)加个来解决这个问题 1.基本概念
1.相关名词解释
名词逻辑结构物理结构主节点Redis 主服务一个独立的redis-server进程从节点Redis 从服务一个独立的redis-server进程Redis 数据节点主从节点主节点和从节点的进程哨兵节点监控 Redis 数据节点的节点一个独立的redis-sentinel进程哨兵节点集合若干哨兵节点的抽象组合若干redis-sentinel进程Redis 哨兵(Sentinel)Redis 提供的⾼可⽤⽅案哨兵节点集合和 Redis 主从节点应⽤⽅泛指⼀个多多个客⼾端⼀个或多个连接 Redis 的进程 2.主从复制的问题
主从复制模式可以将主节点的数据改变同步给从节点这样从节点就可以起到两个作⽤ 作为主节点的⼀个备份⼀旦主节点出了故障不可达的情况从节点可以作为后备“顶”上 来并且保证数据尽量不丢失(主从复制表现为最终⼀致性)从节点可以分担主节点上的读压⼒让主节点只承担写请求的处理将所有的读请求负载均衡到各个从节点上 主从复制模式并不是万能的它同样遗留下以下⼏个问题 主节点发⽣故障时进⾏主备切换的过程是复杂的需要完全的⼈⼯参与导致故障恢复时间⽆法保障 Redis哨兵主要解决的问题 主节点可以将读压⼒分散出去但写压⼒/存储压⼒是⽆法被分担的还是受到单机的限制 Redis集群解决的问题 3.人工恢复主节点故障
Redis主从复制模式下主节点故障后需要进⾏的⼈⼯⼯作是⽐较繁琐的 运维⼈员通过监控系统发现Redis主节点故障宕机 运维⼈员从所有节点中选择⼀个(此处选择了slave1)执⾏slaveof no one使其作为新的主 节点 运维⼈员让剩余从节点(此处为slave2)执⾏slaveof {newMasterIp} {newMasterPort}从新主节点开始数据同步 更新应⽤⽅连接的主节点信息到{newMasterIp} {newMasterPort} 如果原来的主节点恢复执⾏slaveof {newMasterIp} {newMasterPort}让其成为⼀个从节点 4.哨兵自动恢复主节点故障 当主节点出现故障时Redis Sentinel能⾃动完成故障发现和故障转移并通知应⽤⽅从⽽实现真正的⾼可⽤ Redis Sentinel是⼀个分布式架构其中包含若⼲个Sentinel节点和Redis数据节点 每个Sentinel节点会对数据节点和其余Sentinel节点进⾏监控当它发现节点不可达时会对节点做下线表⽰如果下线的是主节点它还会和其他的Sentinel节点进⾏“协商”当⼤多数Sentinel节点对 主节点不可达这个结论达成共识之后它们会在内部“选举”出⼀个领导节点来完成⾃动故障转移的⼯作同时将这个变化实时通知给Redis应⽤⽅整个过程是完全⾃动的不需要⼈⼯介⼊ Redis Sentinel相⽐于主从复制模式是多了若⼲(建议保持奇数)Sentinel节点⽤于实现监控数据节 点哨兵节点会定期监控所有节点(包含数据节点和其他哨兵节点) 保持奇数是为了便于投票 针对主节点故障的情况故障转移流程⼤致如下 主节点故障从节点同步连接中断主从复制停⽌哨兵节点通过定期监控发现主节点出现故障哨兵节点与其他哨兵节点进⾏协商达成多数认同主节点故障的共识 这步主要是防⽌该情况出故障的不是主节点⽽是发现故障的哨兵节点该情况经常发⽣于哨兵节点的⽹络被孤⽴的场景下 哨兵节点之间使⽤Raft算法选举出⼀个领导⻆⾊由该节点负责后续的故障转移⼯作哨兵领导者开始执⾏故障转移从节点中选择⼀个作为新主节点让其他从节点同步新主节点通知应⽤层转移到新主节点 综上RedisSentinel具有以下⼏个功能 监控Sentinel节点会定期检测Redis数据节点、其余哨兵节点是否可达故障转移实现从节点晋升(promotion)为主节点并维护后续正确的主从关系通知Sentinel节点会将故障转移的结果通知给应⽤⽅
