【Redis】Redis Sentinel（哨兵）系统：自动故障恢复与高可用性配置全解

---

哨兵 (Sentinel)

本章节相关操作不需要记忆!!! 后续⼯作中如果⽤到了能查到即可。

重点理解流程和原理。

Redis 的主从复制模式下，⼀旦主节点由于故障不能提供服务，需要⼈⼯进⾏主从切换，同时⼤量的客⼾端需要被通知切换到新的主节点上，对于上了⼀定规模的应⽤来说，这种⽅案是⽆法接受的，于是 Redis 从 2.8 开始提供了 Redis Sentinel（哨兵）加个来解决这个问题。本章主要内容如下：

• Redis Sentinel 的概念
• Redis Sentinel 的部署
• Redis Sentinel 命令
• Redis Sentinel 客⼾端
• Redis Sentinel 实现原理

在复制章节中，我们说了给⼀个⽼师配了⼏个助教。如果⽼师有事请假了⼏天，助教⼜不能上课的话，学⽣们的学习进度就会受到影响。哨兵就是⽤来解决这个问题的。

基本概念

由于对 Redis 的许多概念都有不同的名词解释，所以在介绍 Redis Sentinel 之前，先对⼏个名词概念进⾏必要的说明，如表所⽰。

Redis Sentinel 相关名词解释

redis-sentinel 不负责存储数据，只是对其他的 redis-server 进程起到监控的作用

Redis Sentinel 是 Redis 的⾼可⽤实现⽅案，在实际的⽣产环境中，对提⾼整个系统的⾼可⽤是⾮常有帮助的，本节⾸先整体梳理主从复制模式下故障处理可能产⽣的问题，⽽后引出⾼可⽤的概念，最后重点分析 Redis Sentinel 的基本架构、优势，以及是如何实现⾼可⽤的。

主从复制的问题

Redis 的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作⽤：第⼀，作为主节点的⼀个备份，⼀旦主节点出了故障不可达的情况，从节点可以作为后备 “顶” 上来，并且保证数据尽量不丢失（主从复制表现为最终⼀致性）。第⼆，从节点可以分担主节点上的读压⼒，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上。但是主从复制模式并不是万能的，它同样遗留下以下⼏个问题：

1. 主节点发⽣故障时，进⾏主备切换的过程是复杂的，需要完全的⼈⼯参与，导致故障恢复时间⽆法保障。
2. 主节点可以将读压⼒分散出去，但写压⼒/存储压⼒是⽆法被分担的，还是受到单机的限制。其中第⼀个问题是⾼可⽤问题，即 Redis 哨兵主要解决的问题。第⼆个问题是属于存储分布式的问题，留给 Redis 集群去解决，本章我们集中讨论第⼀个问题。

⼈⼯恢复主节点故障

Redis 主从复制模式下，主节点故障后需要进⾏的⼈⼯工作是⽐较繁琐的，我们在图中⼤致展⽰了整体过程。

Redis 主节点故障后需要进⾏的操作

实际开发中，对于服务器后端开发，监控程序，是非常重要的！

服务器，要求有比较高的可用性，24h运行。但服务器长期运行总有意外发生，也不能全靠人工监控，就用程序盯着服务器的运行状态，这个就是监控程序。这个往往还需要搭配“报警程序”。

1. 运维⼈员通过监控系统，发现 Redis 主节点故障宕机。

   其实到第二步之前可能看看主节点是否能抢救恢复，不能再下一步

2. 运维⼈员从所有节点中，选择⼀个（此处选择了 slave 1）执⾏ slaveof no one，使其作为新的主节点。

3. 运维⼈员让剩余从节点（此处为 slave 2）执⾏ slaveof {newMasterIp} {newMasterPort} 从新主节点开始数据同步。

4. 更新应⽤⽅（客户端）连接的主节点信息到 {newMasterIp} {newMasterPort}。

5. 如果原来的主节点恢复，执⾏ slaveof {newMasterIp} {newMasterPort} 让其成为⼀个从节点。上述过程可以看到基本需要⼈⼯介⼊，⽆法被认为架构是⾼可⽤的。⽽这就是 Redis Sentinel 所要做的。

哨兵⾃动恢复主节点故障

当主节点出现故障时，Redis Sentinel 能⾃动完成故障发现和故障转移，并通知应⽤⽅，从⽽实现真正的⾼可⽤。

Redis Sentinel 是⼀个分布式架构，其中包含若⼲个 Sentinel 节点和 Redis 数据节点，每个Sentinel 节点会对数据节点和其余 Sentinel 节点进⾏监控，当它发现节点不可达时，会对节点做下线表⽰。如果下线的是主节点，它还会和其他的 Sentinel 节点进⾏ “协商”，当⼤多数 Sentinel 节点对主节点不可达这个结论达成共识之后，它们会在内部 “选举” 出⼀个领导节点来完成⾃动故障转移的⼯作，同时将这个变化实时通知给 Redis 应⽤⽅。整个过程是完全⾃动的，不需要⼈⼯介⼊。整体的架构如图所⽰。

这⾥的分布式架构是指：Redis 数据节点、Sentinel 节点集合、客⼾端分布在多个物理节点上，不要与后边章节介绍的 Redis Cluster 分布式混淆。

Redis Sentinel 架构

这里提供了三个单独的 redis sentinel 进程，并且这三个哨兵进程就会监控现有的 redis master 和 slave。

监控：这些进程之间会建立 tcp 长连接，通过这样的长连接，定期发送心跳包

Redis Sentinel 相⽐于主从复制模式是多了若⼲（建议保持奇数）Sentinel 节点⽤于实现监控数据节点，哨兵节点会定期监控所有节点（包含数据节点和其他哨兵节点）。针对主节点故障的情况，故障转移流程⼤致如下：

1. 主节点故障，从节点同步连接中断，主从复制停⽌。（从节点挂了无所谓）
2. 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进⾏协商，达成多数认同主节点故障的共识。这步主要是防⽌该情况：出故障的不是主节点，⽽是发现故障的哨兵节点，该情况经常发⽣于哨兵节点的⽹络被孤⽴的场景下。
3. 哨兵节点之间使⽤ Raft 算法选举出⼀个领导⻆⾊，由该节点负责后续的故障转移⼯作。
4. 哨兵领导者开始执⾏故障转移：从节点中选择⼀个作为新主节点；让其他从节点同步新主节点；通知应⽤层（客户端程序）转移到新主节点。

通过上⾯的介绍，可以看出 Redis Sentinel 具有以下⼏个功能：

• 监控：Sentinel 节点会定期检测 Redis 数据节点、其余哨兵节点是否可达。
• 自动故障转移：实现从节点晋升（promotion）为主节点并维护后续正确的主从关系。
• 通知：Sentinel 节点会将故障转移的结果通知给应⽤⽅。

redis 哨兵节点只有一个也是可以的，只是：

1. 如果只有一个，自身也是很容易出问题的，如果这个哨兵节点挂了，后续 redis 节点也挂了，就无法自动恢复
2. 出现误判的概率提高了，毕竟网络传输是容易出现抖动、延迟、丢包之类的，这单个哨兵节点出问题，影响就大了

基本原则：在分布式系统中，应该避免使用“单点”。

哨兵节点最好搞奇数个，最少是3个，原因：

如果哨兵节点数目为偶数，可能出现两个相等大小的哨兵组认为自己拥有决策权的情况，从而导致系统不能一致地决定哪个Redis实例应该是主节点。这种情况下，两个哨兵组可能会分别选举出不同的主节点，造成数据不一致和应用错误。

安装部署 (基于 docker)

准备⼯作

1）安装 docker 和 docker-compose

以下部分是独立于这一章节的

以下内容在第58到64节

Docker安装

实战目的

掌握如何安装docker

各版本平台⽀持情况

• Server版本

  

• 桌面版本

Server版本安装

CentOS安装

安装依赖

1. ⽀持的操作系统

 CentOS 7
 CentOS 8 (stream)
 CentOS 9 (stream)

2. ⽀持的CPU

 ARM/X86_64

安装Docker

1. 确认操作系统

CentOS Linux release 7.9.2009 (Core)
Derived from Red Hat Enterprise Linux 7.9 (Source)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE&