Redis存储⑫哨兵Sentinel_高可用实现方案
目录
1. 哨兵Sentinel概念
1.1 主从复制的缺点
1.2 人工恢复主节点故障
1.3 哨兵自动恢复主节点故障
2. 重新选举过程
3. 选举原理
3.1 主观下线
3.2 客观下线
3.3 选举出哨兵的 leader
3.4 leader挑选出master
本篇完。
Redis 的主从复制模式下，一旦主节点由于故障不能提供服务，需要人工进行主从切换，同时大量的客户端需要被通知切换到新的主节点上，对于上了一定规模的应用来说，这种方案是无法接受的，于是 Redis 从 2.8 开始提供了 Redis Sentinel（哨兵）加个来解决这个问题。
1. 哨兵Sentinel概念
由于对 Redis 的许多概念都有不同的名词解释，所以在介绍 Redis Sentinel 之前，先对几个名词概念进行必要的说明，如下表所示。
Redis Sentinel 相关名词解释：
Redis Sentinel 是 Redis 的高可用实现方案，在实际的生产环境中，对提高整个系统的高可用是非常有帮助的。
1.1 主从复制的缺点
Redis 的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：
第一，作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备 “顶” 上来，并且保证数据尽量不丢失（主从复制表现为最终一致性）。第二，从节点可以分担主节点上的读压力，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上。
但是主从复制模式并不是万能的，它同样遗留下以下几个问题：
- 主节点发生故障时，进行主备切换的过程是复杂的，需要完全的人工参与，导致故障恢复时间无法保障。
- 主节点可以将读压力分散出去，但写压力 / 存储压力是无法被分担的，还是受到单机的限制。其中第一个问题是高可用问题，即 Redis 哨兵主要解决的问题。第二个问题是属于存储分布式的问题，留给 Redis 集群去解决。
1.2 人工恢复主节点故障
Redis 主从复制模式下，主节点故障后需要进行的人工工作是比较繁琐的，在图中大致展示了整体过程。
1. Redis 主节点故障后需要进行的操作
实际开发过程中，对于服务器后端开发，监控程序是非常重要的。服务器要求要有比较高的可用性，而服务器长期运行总会出现一些 “意外”，但也没法全靠人工来盯着这些服务器运行。所以，此时就可以写一个程序，用程序来盯着服务器的运行状态（监控程序，往往还需要搭配 “报警程序” 来发现服务器的运行出现状态异常）。
步骤解释：
- 运维人员通过监控系统，发现 Redis 主节点故障宕机。
- 运维人员从所有节点中，选择一个（此处选择了 slave 1）执行 slaveof no one，使其作为新的主节点。
- 运维人员让剩余从节点（此处为 slave 2）执行 slaveof {newMasterIp} {newMasterPort}，连上新的主节点，从新的主节点开始数据同步。
- 告知客户端（修改客户的的配置），让客户端能够连接新的主节点，用来完成修改数据的操作，需要更新应用方连接的主节点信息到 {newMasterIp} {newMasterPort}。
- 如果原来挂了的主节点恢复，执行 slaveof {newMasterIp} {newMasterPort}，让其成为⼀个从节点，挂到这组机器中。上述过程可以看到基本需要人工介入，无法被认为架构是高可用的，而这就是 Redis Sentinel 所要做的。
1.3 哨兵自动恢复主节点故障
当主节点出现故障时，Redis Sentinel 能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。
Redis Sentinel 是一个分布式架构，其中包含若干个 Sentinel 节点和 Redis 数据节点，每个 Sentinel 节点会对数据节点和其余 Sentinel 节点进行监控，当它发现节点不可达时，会对节点做下线表示。如果下线的是主节点，它还会和其他的 Sentinel 节点进行 “协商”，当大多数 Sentinel 节点对主节点不可达这个结论达成共识之后，它们会在内部 “选举” 出一个领导节点来完成自动故障转移的工作，同时将这个变化实时通知给 Redis 应用方。整个过程是完全自动的，不需要人工介入。整体的架构如下图所示。
这里的分布式架构是指：Redis 数据节点、Sentinel 节点集合、客户端分布在多个物理节点上，不要与后面将要学习的 Redis Cluster 集群分布式混淆。
Redis Sentinel 相比于主从复制模式是多了若干单独的（建议保持奇数，最少应该是 3 个）Sentinel 节点用于实现监控数据节点，哨兵节点会定期监控（这些进程之间会建立 tcp 长连接，通过这样的长连接定期发送心跳包）所有节点（包含数据节点和其他哨兵节点）。
针对主节点故障的情况，故障转移流程大致如下：
- 主节点故障，从节点同步连接中断，主从复制停止。
- 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进⾏协商，达成多数认同主节点故障的共识。这步主要是防止该情况：出故障的不是主节点，而是发现故障的哨兵节点，该情况经常发生于哨兵节点的网络被孤立的场景下。
- 哨兵节点之间使用 Raft 算法选举出⼀个 leader（领导角色），由该节点负责后续的故障转移工作。
- 哨兵领导者开始执行故障转移：leader 从节点中选择⼀个作为新的主节点，挑选出新的主节点之后，哨兵节点就会自动控制这个被选中的节点，执行 slaveof no one，并且控制其他从节点，修改 slaveof 到新的主节点上，哨兵节点会自动通知客户端程序，告知新的主节点是谁，并且后续客户端再进行写操作，就会针对新的节点进行操作。
通过上面的介绍，可以看出 Redis Sentinel 具有以下几个功能：
- 监控：Sentinel 节点会定期检测 Redis 数据节点、其余哨兵节点是否可达。
- 故障转移：实现从节点晋升（promotion）为主节点并维护后续正确的主从关系。
- 通知：Sentinel 节点会将故障转移的结果通知给应用方。
注意：只有一个 Redis 哨兵节点也是可以的。但是万一这个哨兵节点挂了，后续 Redis 节点也挂了的话，就无法进行自动回复的过程了。而且出现误判的概率也比较高，毕竟网络传输数据容易出现抖动、延迟或者丢包等情况，只有一个哨兵节点出现上述情况影响较大。
基本原则：在分布式系统中，应该避免使用 “单点”。
2. 重新选举master过程
哨兵存在的意义：能够在 Redis 主从结构出现问题（比如主节点挂了）时，哨兵节点自动帮我们重新选出一个主节点来代替之前挂了的节点，保证整个 Redis 仍然是可用状态。
当主节点挂了之后，哨兵节点就开始工作了，哨兵发现了主节点 sdown，进一步的由于主节点宕机得票达到 3/2，达到法定得票，于是 master 被判定为 odown。
- 主观下线（Subjectively Down，SDown）：哨兵感知到主节点没心跳了，判定为主观下线。
- 客观下线（Objectively Down，ODown）：多个哨兵达成一致意见，才能认为 master 确实下线了。
接下来，哨兵们挑选出了一个新的 master。此时，对于 Redis 来说仍然是可以正常使用的。
- Redis 主节点如果宕机，哨兵会把其中的一个从节点，提拔成主节点。
- 当之前的 Redis 主节点重启之后，这个主节点被加入到哨兵的监控中，但是只会被作为从节点使用。
3. 选举master原理
假定当前环境为：三个哨兵（sentenal1、sentenal2、sentenal3），一个主节点（redis-master），两个从节点（redis-slave1、redis-slave2）。
当主节点出现故障，就会触发重新一系列过程。
3.1 主观下线
哨兵节点通过心跳包来判断 Redis 服务器是否正常工作。当 redis-master 宕机，此时 redis-master 和三个哨兵之间的心跳包就没有了。此时，站在三个哨兵的角度来看，redis-master 出现严重故障。此时还不能排除网络波动的影响，因此三个哨兵均会把 redis-master 判定为主观这个 Redis 节点下线（SDown）。
3.2 客观下线
此时，哨兵 sentenal1、sentenal2、sentenal3 均会对主节点故障这件事情进行投票。当故障得票数 >= 配置的法定票数之后，此时意味着 redis-master 故障这个事情被做实了，此时触发客观下线（ODown）。
是否可能出现非常严重的网络波动，而导致所有的哨兵都联系不上 Redis 主节点，而被误判为挂了呢？
是有这个可能的。如果出现这个情况，怕是用户的客户端也连不上 Redis 主节点了，此时这个主节点基本也就无法正常工作了。
“挂了” 不一定是进程崩了，只要是无法访问，都可以被视为是挂了。
3.3 选举出哨兵的 leader
接下来需要哨兵把剩余的 slave 中挑选出一个新的 master，这个工作不需要所有的哨兵都参与，只需要选出个代表（称为 leader），由 leader 负责进行 slave 升级到 master 的提拔过程。这个选举的过程涉及到 Raft 算法。
Raft算法是一种为分布式系统设计的共识算法，旨在简化共识过程的理解与实现。其核心目标是在多个节点间高效达成一致，确保系统在节点故障时仍能可靠运行。
假定一共三个哨兵节点：S1、S2、S3
- 每个哨兵节点都给其他所有哨兵节点，发起⼀个 “拉票请求”（S1 -> S2, S1 -> S3, S2 -> S1, S2 -> S3，S3 -> S1，S3 -> S2）。
- 收到拉票请求的节点，会回复一个 “投票响应”。响应的结果有两种可能，投 / 不投。比如 S1 给 S2 发了个投票请求, S2 就会给 S1 返回投票响应。到底 S2 是否要投 S1 呢？取决于 S2 是否给别⼈投过票了（每个哨兵只有一票）。如果 S2 没有给别⼈投过票，换而言之，S1 是第一个向 S2 拉票的，那么 S2 就会投 S1，否则则不投。
- 一轮投票完成之后, 发现得票超过半数的节点，自动成为 leader。如果出现平票的情况（S1 投 S2，S2 投 S3，S3 投 S1，每人一票），就重新再投一次即可。这也是为啥建议哨兵节点设置成奇数个的原因。如果是偶数个，则增大了平票的概率，带来不必要的开销。
- leader 节点负责挑选一个 slave 成为新的 master，当其他的 sentenal 发现新的 master 出现了，就说明选举结束了。
简而言之，Raft 算法的核心就是 “先下手为强”。谁率先发出了拉票请求，谁就有更大的概率成为 leader。这里的决定因素成了 “网络延时”。网络延时本身就带有一定随机性。
具体选出的哪个节点是 leader，这个并不重要，重要的是能选出一个节点即可 。
3.4 leader挑选出master
leader 挑选出合适的 slave 成为新的 master，挑选规则：
挑选规则：
- 比较优先级。优先级高（数值小的）的上位，优先级是配置文件中的配置项（slave-priority 或者 replica-priority）。
- 比较 replication offset 谁复制的数据多，高的上位。
- 比较 run id，谁的 id 小，谁上位。
当某个 slave 节点被指定为 master 之后，
- leader 指定该节点执行 slave no one，成为 master。
- leader 指定剩余的 slave 节点，都依附于这个新 master。
选举小结：
上述过程都是 “无人值守”，Redis 自动完成的。这样做就解决了主节点宕机之后需要人工干预的问题，提高了系统的稳定性和可用性。
注意事项：
- 哨兵节点不能只有一个，否则哨兵节点挂了也会影响系统可用性。
- 哨兵节点最好是奇数个，方便选举 leader，得票更容易超过半数。
- 哨兵节点不负责存储数据，仍然是 redis 主从节点负责存储。
- 哨兵 + 主从复制解决的问题是 “提高可用性”，不能解决 “数据极端情况下写丢失” 的问题。
- 哨兵 + 主从复制不能提高数据的存储容量。当我们需要存的数据接近或者超过机器的物理内存，这样的结构就难以胜任了。
为了能存储更多的数据，就引入了集群，后面将会详细介绍。
本篇完。
下一篇是Redis存储⑬Redis集群_扩展存储空间。