【Redis入门到精通十】Redis哨兵

哨兵（Sentinel）

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

1.哨兵的由来

主从复制模式通过将主节点的数据改变同步给从节点，这样从节点可以起到两个作用：

一.作为主节点的一个备份，一旦主节点出了故障，从节点可以顶替主节点，并且保证数据一致性。二.从节点可以分担主节点的读压力，实现读写分离。

主从复制遇到的难题

1. 主节点发生故障时，进行主备切换的过程十分复杂，需要完全依赖人工参与，导致故障无法及时恢复正常。
2. 主节点可以将读的压力分担，但是写的压力无法分担，收到单机限制。

其中第⼀个问题是⾼可⽤问题，即 Redis 哨兵主要解决的问题。第⼆个问题是属于存储分布式的问题，留给 Redis 集群去解决，本篇文章我们集中讨论第⼀个问题。

哨兵自动恢复主节点故障

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

整体的架构如图所示：

2.哨兵的基本概念

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

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

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

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

3.基于docker安装配置Redis哨兵

1.首先要安装docker和docker-compose （基于unbantu的docker安装全教程）

2.停止之前的Redis服务器（service redis-server stop）

3.使用docker获取到redis的镜像（获取错误需要配置docker镜像加速器详看第一条的安装教程）

如下图所示即获取成功：

4.使用docker-compose进行容器编排

因为此处要设置的Redis集群至少需要六个Redis服务器，每个Redis服务器都需要一个单独的容器进行启动，也就是需要六个docker容器，使用docker对这六个容器一一进行配置，启动非常麻烦，所以我们选择通过一个配置文件，把具体要创建哪些容器，每个容器运行的各种参数都描述清楚，使用docker-compose运行这个配置文件以此达成批量生成docker容器的操作。

创建两个yml格式的配置文件，分别把Redis服务器的配置信息和Redis哨兵的配置信息填入其中，1.1首先启动Redis的主从节点，使用docker-compose时的配置文件名称必须为docke-compose，如下所示：

1.2使用docker-compose up -d 命令启动Redis所在容器。

1.3 查看运行日志使用命令 docker-compose logs

1.4连接主节点，验证是否启动成功

2.1编写redis-sentinel启动所需的配置文件 ，创建 /root/redis-sentinel/docker-compose.yml , 同时 cd 到 yml 所在⽬录中。

确保 redis 主从节点启动之后才启动 redis-sentinel. 如果先启动 redis-sentinel 的话, 可能触发额外的选举过程, 对我们之后观察redis哨兵选举redis主节点的过程造成影响。

2.2在当前目录下创建哨兵的配置文件，创建 sentinel1.conf sentinel2.conf sentinel3.conf 三份⽂件的内容是完全相同的（因为哨兵在运行过程中会自动重写配置文件，如果使用一份文件，会出现修改混乱。）。

其中sentinel monitor命令参数如下：

sentinel monitor 主节点名 主节点ip 主节点端⼝ 法定票数

法定票数即哨兵之间通过通信，当足够票数的哨兵都一致认为主节点瘫痪时，哨兵才会开始工作，选举新的主节点，避免哨兵因为网络波动而出现误判的情况。

其中sentinel down-after-milliseconds 即哨兵监控的节点名称和最长停摆时间。

• 主节点和哨兵之间通过⼼跳包来进⾏沟通. 如果⼼跳包在指定的时间内还没回来, 就视为是节点出现故障

2.3使用docker-compose up -d命令启动所有容器

2.4使用docker-compose logs 命令查看运行日志

3.1手动下线主节点 docker stop redis-master

3.2 观察哨兵日志

可以看到哨兵发现了主节点 sdown, 进⼀步的由于主节点宕机得票达到 3/2 , 达到法定得票, 于是master 被判定为 odown.

• 主观下线 (Subjectively Down, SDown): 哨兵感知到主节点没⼼跳了. 判定为主观下线.
• 客观下线 (Objectively Down, ODown): 多个哨兵达成⼀致意⻅, 才能认为 master 确实下线了.

接下来, 哨兵们挑选出了⼀个新的 master. 在上图中, 是 172.18.04:6379 这个节点。

3.3重启原master节点，可以发现原节点被当成了从节点。

4.哨兵选取主节点的原理

从上述操作过程也可以看出来哨兵在选取主节点的过程大致可以分为四步：

1.主观下线

当 redis-master 宕机, 此时 redis-master 和三个哨兵之间的⼼跳包就没有了.

此时, 站在三个哨兵的⻆度来看, redis-master 出现严重故障. 因此三个哨兵均会把 redis-master 判定为主观下线 (SDown)

2.客观下线

此时, 哨兵 sentenal1, sentenal2, sentenal3 均会对主节点故障这件事情进⾏投票. 当故障得票数>= 配置的法定票数之后， 此时意味着 redis-master 故障这个事情被做实了. 此时触发客观下线(ODown)。

sentinel monitor redis-master 172.22.0.4 6379 2

这个地⽅配置的 2 , 即为法定票数

3.选举出哨兵的leader

选举leader的过程设计Raft算法，具体过程可分为下面四个步骤：

1. 每个哨兵节点都给其他所有哨兵节点, 发起⼀个 "拉票请求". (S1 -> S2, S1 -> S3, S2 -> S1, S2 -> S3, S3 -> S1, S3 -> S2)。
2. 收到拉票请求的节点, 会回复⼀个 "投票响应". 响应的结果有两种可能, 投 or 不投.
3. ⼀轮投票完成之后, 发现得票超过半数的节点, ⾃动成为 leader。
4. leader 节点负责挑选⼀个 slave 成为新的 master. 当其他的 sentenal 发现新的 master 出现了, 就说明选举结束了.

4.leader挑选出合适的slave成为新的master

挑选规则:

1. ⽐较优先级. 优先级⾼(数值⼩的)的上位. 优先级是配置⽂件中的配置项( slave-priority 或者 replica-priority ).
2. ⽐较 replication offset 谁复制的数据多, ⾼的上位.
3. ⽐较 run id , 谁的 id 小, 谁上位。

❤️😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍😍 🍔我是小皮侠，谢谢大家都能看到这里！！ 🦚主页已更新Java基础内容，数据结构基础，数据库，算法，Redis相关内容。 🚕未来会更新Java项目，SpringBoot，docker，mq，微服务以及各种Java路线会用到的技术。 🎃求点赞！求收藏！求评论！求关注！ 🤷‍♀️谢谢大家！！！！！！！！