大厂面试官：Redis哨兵机制，你了解多少？

暮起

于 2024-08-25 18:28:06 发布

阅读量941

点赞数 24

分类专栏： Redis 文章标签： redis 数据库缓存 java 面试大厂后端

本文链接：https://blog.csdn.net/weixin_44213904/article/details/141532486

版权

Redis 专栏收录该内容

16 篇文章 1 订阅

订阅专栏

大厂常问面试题，Redis哨兵机制，你了解多少？

希望大家能关注点赞，创作不易且没收益，您的小小举动却能给予我大大的鼓励，会激励我继续创作出高质量文章😘，更多内容可看我主页～

Redis Sentinel （哨兵）

1、哨兵模式是用来解决什么问题的？

1.1 主要用来应对问题

如果主节点凌晨 3 点突发宕机怎么办？就坐等运维从床上爬起来，然后手工进行从主切换，再通知所有的程序把地址统统改一遍重新上线么？毫无疑问，这样的人工运维效率太低，事故发生时估计得至少 1 个小时才能缓过来。

所以，我们必须有一个高可用方案来抵抗节点故障，当故障发生的时候可以自动进行自动进行从主切换，程序可以不用重启。Redis Sentinel可以通过自动监测和管理Redis数据库主从复制系统的状态，来保证Redis服务的高可用性。

1.2 Redis Sentinel的主要作用可以归纳为以下几个方面

**监控Redis实例的健康状况：**Redis Sentinel可以周期性地对Redis实例进行健康检查，并识别出故障的Redis实例。一旦发现某个Redis实例出现故障，Sentinel就会自动将其标记为不可用状态，并开始进行故障恢复或者故障转移操作。
对Redis实例进行故障恢复和故障转移：当Redis主节点发生故障时，Redis Sentinel会自动将某个从节点升级为新的主节点，并重新配置其它从节点以连接到新的主节点上。这样，即使Redis主节点发生宕机等故障事件，整个Redis集群依然可以继续运行，保持业务的连续性和可用性。
滚动升级和重启Redis实例：Redis Sentinel可以通过观察Redis实例的运行状态，来进行滚动升级和重启Redis实例的操作。这样，就可以在保持服务连续性的同时，完成系统的升级或者维护工作。

1.3 Redis Sentinel的工作过程

如上图所示，我们可以将 Redis Sentinel 集群看成是一个 ZooKeeper 集群，它是集群高可用的心脏，它一般是由 3～5 个节点组成，这样挂了个别节点集群还可以正常运转。
它负责持续监控主从节点的健康，当主节点挂掉时，自动选择一个最优的从节点切换为主节点。**客户端来连接集群时，会首先连接 sentinel，通过 sentinel 来查询主节点的地址，然后再去连接主节点进行数据交互。当主节点发生故障时，客户端会重新向 sentinel 要地址，sentinel 会将最新的主节点地址告诉客户端。**如此应用程序将无需重启即可自动完成节点切换。比如上图的主节点挂掉后，集群将可能自动调整为下图所示结构。

从这张图中我们能看到主节点挂掉了，原先的主从复制也断开了，客户端和损坏的主节点也断开了。从节点被提升为新的主节点，其它从节点开始和新的主节点建立复制关系。客户端通过新的主节点继续进行交互。Sentinel 会持续监控已经挂掉了主节点，待它恢复后，集群会调整为下面这张图。

此时原先挂掉的主节点现在变成了从节点，从新的主节点那里建立复制关系。

从以上所述过程看，个人认为较为重要的就是，客户端在连接Redis集群的时候，先去连接哨兵集群，从哨兵集群那里获取主节点的信息，然后再去连接主节点，这难怪叫哨兵，像极了你去一个机关找人，你首先要在门卫那报道，他给你联系人，确认之后，你才能进去。

1.4 Redis如何应对消息丢失

问题：Redis 主从采用异步复制，意味着当主节点挂掉时，从节点可能没有收到全部的同步消息，这部分未同步的消息就丢失了。如果主从延迟特别大，那么丢失的数据就可能会特别多。

解决：Sentinel 无法保证消息完全不丢失，但是也尽可能保证消息少丢失。它有两个选项可以限制主从延迟过大。

min-slaves-to-write 1
min-slaves-max-lag 10

第一个参数表示主节点必须至少有一个从节点在进行正常复制，否则就停止对外写服务，丧失可用性。
第二个参数是表示判断正常复制的标准，它的单位是秒，表示如果 10s 没有收到从节点的反馈，就意味着从节点同步不正常，要么网络断开了，要么一直没有给反馈。

这可就更好理解了，你去机关找人，门卫说我给你联系下，他打了电话等了十秒没人接，就判定这个人可能不在，然后他就问你，你还有其他人可以联系么，你说有，然后又打了个电话过去，发现还是十秒没人接，就判定这个人也不在，好的吧，门卫说，那你就在外面等着吧，我联系上他们了再通知你。你就只好在那等着，而不是你进去了找了一圈发现没人之后你走了，他们回来之后发现少了一位客人。

2、 Sentinel 基本使用

   接下来我们看看客户端如何使用 sentinel，标准的流程应该是客户端可以通过 sentinel发现主从节点的地址，然后在通过这些地址建立相应的连接来进行数据存取操作。我们来看看 Python 客户端是如何做的。

>>> from redis.sentinel import Sentinel
>>> sentinel = Sentinel([('localhost', 26379)], socket_timeout=0.1)
>>> sentinel.discover_master('mymaster')
('127.0.0.1', 6379)
>>> sentinel.discover_slaves('mymaster')
[('127.0.0.1', 6380)]

sentinel 的默认端口是 26379，不同于 Redis 的默认端口 6379，通过 sentinel 对象的discover_xxx 方法可以发现主从地址，主地址只有一个，从地址可以有多个。

>>> master = sentinel.master_for('mymaster', socket_timeout=0.1)
>>> slave = sentinel.slave_for('mymaster', socket_timeout=0.1)
>>> master.set('foo', 'bar')
>>> slave.get('foo')
'bar

通过 xxx_for 方法可以从连接池中拿出一个连接来使用，因为从地址有多个，redis 客户端对从地址采用轮询方案，也就是 RoundRobin 轮着来。
有个问题是，但 sentinel 进行主从切换时，客户端如何知道地址变更了 ? 通过分析源码，我发现 redis-py 在建立连接的时候进行了主库地址变更判断。

连接池建立新连接时，会去查询主库地址，然后跟内存中的主库地址进行比对，如果变更了，就断开所有连接，重新使用新地址建立新连接。如果是旧的主库挂掉了，那么所有正在使用的连接都会被关闭，然后在重连时就会用上新地址。

但是这样还不够，如果是 sentinel 主动进行主从切换，主库并没有挂掉，而之前的主库连接已经建立了在使用了，没有新连接需要建立，那这个连接是不是一致切换不了？

继续深入研究源码，我发现 redis-py 在另外一个点也做了控制。那就是在处理命令的时候捕获了一个特殊的异常 ReadOnlyError，在这个异常里将所有的旧连接全部关闭了，后续指令就会进行重连。

主从切换后，之前的主库被降级到从库，所有的修改性的指令都会抛出 ReadonlyError。如果没有修改性指令，虽然连接不会得到切换，但是数据不会被破坏，所以即使不切换也没关系。

Redis Sentinel 的优缺点

Redis Sentinel是一种用于提高Redis服务高可用性的解决方案，其主要优点和缺点如下：
优点：

高可用性：Redis Sentinel可以自动检测和处理Master节点的故障，从而实现高可用性的Redis服务。
自动故障转移：当Redis Master节点发生故障时，Redis Sentinel可以自动将Slave节点晋升为新的Master节点，从而保证Redis服务的高可用性。
无需手动介入：Redis Sentinel是自动化运维的一种典型代表。一旦发现Redis Master节点出现故障，它能够立即自动进行故障转移操作，省去了手动介入的麻烦和风险。
配置简单：Redis Sentinel的配置相对简单，可以使用Redis Sentinel提供的命令进行轻松配置。
可扩展性：Redis Sentinel可以通过增加或减少Sentinel节点来提高系统的可扩展性和灵活性。

缺点：