[Redis][哨兵][上]详细讲解

0.前言

• 说明：该章节相关操作不需要记忆，理解流程和原理即可，用的时候能自主查到即可
• Redis的主从复制模式下，⼀旦主节点由于故障不能提供服务，需要⼈⼯进⾏主从切换，同时⼤量的客⼾端需要被通知切换到新的主节点上，对于上了⼀定规模的应⽤来说，这种⽅案是⽆法接受的， 于是Redis从2.8开始提供了Redis Sentinel(哨兵)加个来解决这个问题

1.基本概念

1.相关名词解释

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节点会将故障转移的结果通知给应⽤⽅