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

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