首页 > 数据库> 文章详细

Redis之哨兵模式

2022-01-09 12:32:43 阅读：176 来源： 互联网

前言

Redis 的主从复制模式下，一旦主节点由于故障不能提供服务，需要手动将从节点晋升为主节点，同时还要通知客户端更新主节点地址，这种故障处理方式从一定程度上是无法接受的。Redis 2.8 以后提供了 Redis Sentinel 哨兵机制来解决这个问题。

正文

1. Redis Sentinel的基本概念

Redis Sentinel 是 Redis 高可用 的实现方案。Sentinel 是一个管理多个 Redis 实例的工具，它可以实现对 Redis 的 监控、通知、自动故障转移。下面先对 Redis Sentinel 的基本概念进行简单的介绍。

基本名词说明：

基本名词	逻辑结构	物理结构
Redis数据节点	主节点和从节点	主节点和从节点的进程
主节点(master)	Redis主数据库	一个独立的Redis进程
从节点(slave)	Redis从数据库	一个独立的Redis进程
Sentinel节点	监控Redis数据节点	一个独立的Sentinel进程
Sentinel节点集合	若干Sentinel节点的抽象组合	若干Sentinel节点进程
Redis Sentinel	Redis高可用实现方案	Sentinel节点集合和Redis数据节点进程
应用客户端	泛指一个或多个客户端	一个或者多个客户端进程或者线程

如图所示，Redis 的主从复制模式和 Sentinel 高可用架构的示意图：

2. Redis主从复制的问题

Redis 主从复制可将主节点数据同步给从节点，从节点此时有两个作用：

一旦 主节点宕机，从节点 作为主节点的备份可以随时顶上来扩展主节点的读能力，分担主节点读压力。

主从复制同时存在以下几个问题：

一旦 主节点宕机，从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。
原生复制的弊端在早期的版本中也会比较突出，比如：Redis 复制中断后，从节点会发起 psync。此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的卡顿。

3. Redis Sentinel深入探究3.1. Redis Sentinel的架构

3.2. Redis Sentinel的主要功能

Sentinel 的主要功能包括主节点存活检测、主从运行情况检测、自动故障转移（failover）、主从切换。Redis 的 Sentinel 最小配置是一主一从。

Redis 的 Sentinel 系统可以用来管理多个 Redis 服务器，该系统可以执行以下四个任务：

监控

Sentinel 会不断的检查主服务器和从服务器是否正常运行。

通知

当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本向管理员或者其他的应用程序发送通知。

自动故障转移

当主节点不能正常工作时，Sentinel 会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点。

配置提供者

在 Redis Sentinel 模式下，客户端应用在初始化时连接的是 Sentinel 节点集合，从中获取主节点的信息。

3.3. 主观下线和客观下线

默认情况下，每个 Sentinel 节点会以 每秒一次 的频率对 Redis 节点和其它的 Sentinel 节点发送 PING 命令，并通过节点的回复来判断节点是否在线。

主观下线

主观下线适用于所有主节点和从节点。如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到目标节点的有效回复，则会判定该节点为 主观下线。

客观下线

客观下线只适用于主节点。如果主节点出现故障，Sentinel 节点会通过 sentinel is-master-down-by-addr 命令，向其它 Sentinel 节点询问对该节点的状态判断。如果超过 <quorum> 个数的节点判定 主节点不可达，则该 Sentinel 节点会判断主节点为 客观下线。

3.4. Sentinel的通信命令

Sentinel 节点连接一个 Redis 实例的时候，会创建 cmd 和 pub/sub 两个连接。Sentinel 通过 cmd 连接给 Redis 发送命令，通过 pub/sub 连接到 Redis 实例上的其他 Sentinel 实例。

Sentinel 与 Redis 主节点和从节点交互的命令，主要包括：

命令	作用
PING	`Sentinel` 向 `Redis` 节点发送 `PING` 命令，检查节点的状态
INFO	`Sentinel` 向 `Redis` 节点发送 `INFO` 命令，获取它的从节点信息
PUBLISH	`Sentinel` 向其监控的 `Redis` 节点 `__sentinel__:hello` 这个 `channel` 发布自己的信息及主节点相关的配置
SUBSCRIBE	`Sentinel` 通过订阅 `Redis` 主节点和从节点的 `__sentinel__:hello` 这个 `channnel`，获取正在监控相同服务的其他 `Sentinel` 节点

Sentinel 与 Sentinel 交互的命令，主要包括：

命令	作用
PING	`Sentinel` 向其他 `Sentinel` 节点发送 `PING` 命令，检查节点的状态
SENTINEL:is-master-down-by-addr	和其他 `Sentinel` 协商主节点的状态，如果主节点处于 `SDOWN` 状态，则投票自动选出新的主节点

3.5. Redis Sentinel的工作原理

每个 Sentinel 节点都需要定期执行以下任务：

每个 Sentinel 以每秒钟一次的频率，向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。

如果一个实例（instance）距离最后一次有效回复 PING命令的时间超过 down-after-milliseconds所指定的值，那么这个实例会被 Sentinel标记为主观下线。

如果一个主服务器被标记为主观下线，那么正在监视这个主服务器的所有 Sentinel节点，要以每秒一次的频率确认主服务器的确进入了主观下线状态。

如果一个主服务器被标记为主观下线，并且有 足够数量的 Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线。

在一般情况下，每个 Sentinel 会以每 10 秒一次的频率，向它已知的所有 主服务器 和 从服务器发送 INFO 命令。当一个主服务器被 Sentinel 标记为 客观下线时，Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率，会从 10 秒一次改为每秒一次。

Sentinel 和其他 Sentinel 协商主节点的状态，如果主节点处于 SDOWN 状态，则投票自动选出新的主节点。将剩余的 从节点指向新的主节点 进行 数据复制。

当没有足够数量的 Sentinel 同意主服务器下线时，主服务器的 客观下线状态就会被移除。当主服务器重新向 Sentinel 的 PING 命令返回有效回复时，主服务器的主观下线状态就会被移除。

注意：一个有效的 PING 回复可以是：+PONG、-LOADING 或者 -MASTERDOWN。如果 服务器 返回除以上三种回复之外的其他回复，又或者在 指定时间 内没有回复 PING 命令， 
那么 Sentinel 认为服务器返回的回复 无效（non-valid）。

4. Redis Sentinel局限性

需要另外部署一套哨兵集群，部署麻烦、原理复杂、浪费资源，从节点作为备份节点不提供服务。
不支持读写分离，实现起来相对复杂。
只支持对主节点的故障转移，不支持对从节点的故障转移。
所有主节点和从节点都包含了 Redis 全量的数据，数据冗余，导致数据存储的数据量有限。

本文链接：https://blog.csdn.net/qq_24313635/article/details/102767793

标签：PING,Redis,模式,哨兵,Sentinel,服务器,下线,节点
来源： https://www.cnblogs.com/sunnycc/p/15780679.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9