Redis——集群之哨兵模式

最新推荐文章于 2024-03-21 08:45:00 发布

一心同学

最新推荐文章于 2024-03-21 08:45:00 发布

阅读量3.4k

点赞数 31

分类专栏： Redis

本文链接：https://blog.csdn.net/Huang_ZX_259/article/details/122857351

版权

Redis 专栏收录该内容

12 篇文章 11 订阅

订阅专栏

📢📢📢📣📣📣

哈喽！大家好，我是【一心同学】，一位上进心十足的【Java领域博主】！😜😜😜

✨【一心同学】的写作风格：喜欢用【通俗易懂】的文笔去讲解每一个知识点，而不喜欢用【高大上】的官方陈述。

✨【一心同学】博客的领域是【面向后端技术】的学习，未来会持续更新更多的【后端技术】以及【学习心得】。

✨如果有对【后端技术】感兴趣的【小可爱】，欢迎关注【一心同学】💞💞💞

❤️❤️❤️感谢各位大可爱小可爱！❤️❤️❤️

一、介绍

🌴 主从模式存在的问题

在主从复制模式中，我们可以发现其系统不具备自动恢复的功能，所以当主服务器（master）宕机后，需要手动把一台从服务器（slave）切换为主服务器。在这个过程中，不仅需要人为干预，而且还会造成一段时间内服务器处于不可用状态，同时数据安全性也得不到保障，因此主从模式的可用性较低，不适用于线上生产环境。

🌴 解决方案之哨兵模式

Redis 官方推荐一种高可用方案，也就是 Redis Sentinel 哨兵模式，它弥补了主从模式的不足。Sentinel 通过监控的方式获取主机的工作状态是否正常，当主机发生故障时， Sentinel 会自动进行 Failover（即故障转移），并将其监控的从机提升主服务器（master），从而保证了系统的高可用性。

二、哨兵模式原理

哨兵模式是一种特殊的模式，Redis 为其提供了专属的哨兵命令，它是一个独立的进程，能够独立运行。其基本原理是：哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

下面使用 Sentinel 搭建 Redis 集群，基本结构图如下所示：

在上图过程中，哨兵主要有两个重要作用：

🚀 第一：哨兵节点会以每秒一次的频率对每个 Redis 节点发送PING命令，并通过 Redis 节点的回复来判断其运行状态。

🚀 第二：当哨兵监测到主服务器发生故障时，会自动在从节点中选择一台将机器，并其提升为主服务器，然后使用 PubSub 发布订阅模式，通知其他的从节点，修改配置文件，跟随新的主服务器。

三、多哨兵模式

在实际生产情况中，哨兵是集群的高可用的保障，为避免一个哨兵节点发生意外，它一般是由 3～5 个节点组成，并且各个哨兵之间还会互相进行监控，这样就算挂了个别节点，该集群仍然可以正常运转。

其结构图如下所示：

3.1 工作过程

我们来对多哨兵模式的工作过程进行讲解：

（1）主观下线

主观下线，适用于主服务器和从服务器。如果在规定的时间内(配置参数：down-after-milliseconds)，Sentinel 节点没有收到目标服务器的有效回复，则判定该服务器为“主观下线”。比如 Sentinel1 向主服务发送了PING命令，在规定时间内没收到主服务器PONG回复，则 Sentinel1 判定主服务器为“主观下线”，这个时候系统并不会马上进行failover过程，因为仅仅是Sentinel1主观的认为主服务器不可用。

（2）客观下线

客观下线，只适用于主服务器。 Sentinel1 发现主服务器出现了故障，它会通过相应的命令，询问其它 Sentinel 节点对主服务器的状态判断。如果超过半数以上的 Sentinel 节点认为主服务器 down 掉，则 Sentinel1 节点判定主服务为“客观下线”。

（3）投票选举

投票选举，所有 Sentinel 节点会通过投票机制，按照谁发现谁去处理的原则，选举 Sentinel1 为领头节点去做 Failover（故障转移）操作。Sentinel1 节点则按照一定的规则在所有从节点中选择一个最优的作为主服务器，然后通过发布订阅功能通知其余的从节点（slave）更改配置文件，跟随新上任的主服务器（master）。至此就完成了主从切换的操作。

3.2 工作流程小结

（1）Sentinel 负责监控主从节点的“健康”状态。当主节点挂掉时，自动选择一个最优的从节点切换为主节点。
（2）客户端来连接 Redis 集群时，会首先连接 Sentinel，通过 Sentinel 来查询主节点的地址，然后再去连接主节点进行数据交互。
（3）当主节点发生故障时，客户端会重新向 Sentinel 要地址，Sentinel 会将最新的主节点地址告诉客户端。因此应用程序无需重启即可自动完成主从节点切换。

四、搭建哨兵模式

由于哨兵模式是基于主从模式上的，所以需要先进行搭建主从模式，主从模式的搭建过程就不在这里讲解了，大家可以看我的上一篇博客【Redis——集群之主从模式】。

（1）配置sentinel哨兵

新建配置文件redis-sentinel.conf,并进行如下配置

port 26379
sentinel monitor myredis 127.0.0.1 6379 1

配置文件说明：

port 26379 #sentinel监听端口，默认是26379，可以更改

sentinel monitor <master-name> <ip> <redis-port> <quorum>

<master-name>:服务器的名称，可以自定义。

<ip>：代表监控的主服务器。

<redis-port>：代表主服务器端口。

<quorum>：是一个数字，表示当有多少个 sentinel 认为主服务器宕机时，它才算真正的宕机掉，例如写2，那么表示只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。通常数量为半数或半数以上才会认为主机已经宕机，<quorum> 需要根据 sentinel 的数量设置。

（2）启动sentienl哨兵

执行命令：

redis-sentinel sentinel.conf

主机是：6379

从机是：6380，6381

（3）停止主服务器服务

我们来模拟主服务意外宕机的情况，首先直接将主服务器的 Redis 服务终止，然后查看从服务器是否被提升为了主服务器。

终止master的redis服务：

127.0.0.1:6379> shutdown

（4）重新查看主从关系

接着我们去查看哨兵的日志，其发现我们的6379主机宕机了，并且过了一会通过选举将我们的从机6381晋升为主机！

我们进入6381的客户端进行查看其主从关系，发现成功变为主机了，并表示其有一个从机6380：

而且我们的sentinel.conf配置文件也发发生了变化：

（5）主机回归

如果我们原来的主机6379重新回来了，那么其只能归并到新的主机下，当做从机。

恢复6379服务器：

redis-server redis79.conf

查看6379的主从关系，发现确实变为从机了：

（6）开启多个哨兵

如果您想开启多个哨兵，只需配置要多个 sentinel.conf 文件即可，然后将端口号进行更改，其他一致，注意<master-name>服务器名字也要一致，然后都启动即可。如下：

哨兵1：

port 26379
sentinel monitor myredis 127.0.0.1 6379 2

哨兵2：

port 26380
sentinel monitor myredis 127.0.0.1 6379 2

由于<quorum>设置为2，所以只有两个哨兵都发现主机宕机了才会进行重写选举。

注：如果要停止哨兵模式只需要：Ctrl+C 即可停止。

五、sentinel.conf配置项

sentinel配置文件说明
配置项	参数类型	说明
dir	文件目录	哨兵进程服务的文件存放目录，默认为 /tmp。
port	端口号	启动哨兵的进程端口号，默认为 26379。
sentinel down-after-milliseconds	<服务名称><毫秒数(整数)>	在指定的毫秒数内，若主节点没有应答哨兵的 PING 命令，此时哨兵认为服务器主观下线，默认时间为 30 秒。
sentinel parallel-syncs	<服务名称><服务器数(整数)>	指定可以有多少个 Redis 服务同步新的主机，一般而言，这个数字越小同步时间越长，而越大，则对网络资源要求就越高。
sentinel failover-timeout	<服务名称><毫秒数(整数)>	指定故障转移允许的毫秒数，若超过这个时间，就认为故障转移执行失败，默认为 3 分钟。
sentinel notification-script	<服务名称><脚本路径>	脚本通知，配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
sentinel auth-pass <master-name> <password>	<服务器名称><密码>	若主服务器设置了密码，则哨兵必须也配置密码，否则哨兵无法对主从服务器进行监控。该密码与主服务器密码相同。

详细使用如下：

#Example sentinel.conf

#哨兵sentinel实例运行的端口 默认26379
port 26379

#哨兵sentinel的工作目录
dir /tmp

#哨兵sentinel监控的redis主节点的 ip port
#master-name可以自己命名的主节点名字，只能由字母A-z、数字0-9、这三个字符".-_"组成。
#quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
#sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
 
#当在Redis实例中开启了requirepass foobared授权密码，这样所有连接Redis实例的客户端都要提供密码 
#设置哨兵sentinel连接主从的密码，注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster XXX
#指定多少毫秒之后主节点没有应答哨兵，此时哨兵主观上认为主节点下线，默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

# 这个配置项指定了在发生failover主备切换（选举）时多可以有多少个slave同时对新的master进行同步，数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1

#故障转移的超时时间failover-timeout可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了#默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

#SCRIPTS EXECUTION

#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。#一个脚本的大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。

#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配 置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无 法正常启动成功。
#通知脚本
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh

#客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
#以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”, # <role>是“leader”或者“observer”中的一个。
#参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

六、哨兵模式的优缺点

🌵 优点

1、哨兵集群，基于主从复制模式，所有的主从配置优点，它都有。
2、主从可以切换，故障可以转移，高可用性的系统。
3、哨兵模式就是主从模式的升级，手动到自动，更加健壮。

🌵 缺点

1、Redis不好在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦。
2、哨兵模式的配置繁琐。

小结

以上就是【一心同学】整理的【Redis集群】中的【哨兵模式】讲解，相比【主从模式】而言，如果【主机宕机】了，不再需要我们进行手动配置了，这在很大程度上提升了我们的【开发效率】！

如果这篇【文章】有帮助到你，希望可以给【一心同学】点个赞👍，创作不易，相比官方的陈述，我更喜欢用【通俗易懂】的文笔去讲解每一个知识点，如果有对【后端技术】感兴趣的小可爱，也欢迎关注❤️❤️❤️ 【一心同学】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】💕💕！