Redis集群之哨兵模式

最新推荐文章于 2024-06-06 13:15:18 发布

wh柒八九

最新推荐文章于 2024-06-06 13:15:18 发布

阅读量333

点赞数

分类专栏：核心知识点 redis数据库文章标签： redis 分布式缓存

本文链接：https://blog.csdn.net/qq_31960623/article/details/119896490

版权

核心知识点同时被 2 个专栏收录

559 篇文章 89 订阅

订阅专栏

redis数据库

43 篇文章 0 订阅

订阅专栏

本文来说下Redis集群之哨兵模式

文章目录

概述
哨兵模式
什么是哨兵
实现原理
哨兵选举过程
master选举过程
cluster集群模式
cluster集群模式是怎么存放数据的
键是如何和16384个插槽做关联的
插槽是如何和节点做关联的
如何获取与插槽对应的节点
新节点的加入
故障恢复
如何提高redis的读写能力
本文小结

概述

我们知道「主从复制是高可用的基石」，从库宕机依然可以将请求发送给主库或者其他从库，但是 Master 宕机，只能响应读操作，写请求无法再执行。

所以主从复制架构面临一个严峻问题，主库挂了，无法执行「写操作」，无法自动选择一个 Slave 切换为 Master，也就是无法故障自动切换。

在这里插入图片描述

从Redis2.8版本起，提供了一个稳定版本的Sentinel哨兵来解决高可用的问题，它的思路是启动奇数个Sentinel的服务来监控Redis服务器来保证服务的可用性。

启动Sentinel可用用脚本启动，它本质上只是一个运行在特殊模式之下的Redis。Sentinel通过info命令得到被监听Redis机器的master，slave等信息。

./redis-sentinel ../sentinel.conf
# 或者
./redis-server ../sentinel.conf --sentinel

为了保证监控服务器的可用性，我们会对Sentinel做集群部署，Sentinel既监控所有的Redis服务，Sentinel之间也相互监控。 Sentinel本身没有主从之分，地位是平等的，只有Redis服务节点有主从之分。

Sentinel通过Raft共识算法，实现Sentinel选举，选举出一个leader来，由leader完成故障转移。Raft算法的应用很广泛，比如加密货币BTB，Spring Cloud注册中心Consul也用到了Raft算法。Raft算法的核心思想是：先到先得，少数服从多数。Sentinel的Raft实现跟原生的算法是有所区别的，但是大体思想一致。

无论Jedis还是Spring Boot（2.x版本默认是Lettuce），都只需要配置全部的哨兵地址，由哨兵返回当前的master节点地址。

哨兵的不足：主从切换的过程中会丢失数据，因为只有一个master；只能单点写，没有解决水平扩容的问题。

哨兵模式

上文咱们说主从复制，在这种一主多从的结构中，我们让主从数据库做到了读写分离，也让从数据库能够完成数据备份的功能，可是也留下了一个比较严重的问题，当master挂了之后，只能由运维人员重新选择一个slave升级成master，然后继续提供服务。这并不符合我们对 Redis 高可用集群的期望。

那么，是不是有一种方法，可以做到不仅仅读高可用，写一样要高可用，当然有，这就是我们今天要介绍的哨兵模式。

哨兵模式可以理解成主从模式的一个升级版，主从模式 master 节点和 slave 节点是一开始就定好的，而在哨兵模式中， master 节点是可以转移，一旦发现当前的 master 节点挂掉，通过选举可以指定一个 slave 节点晋升成为 master ，保证在任何情况下，都有 master 节点可以支持写入操作，也间接实现了写高可用。

在这里插入图片描述

什么是哨兵

顾名思义，哨兵其实就是放哨的，它主要会有完成两个功能。

监控整个主数据库和从数据库，观察它们是否正常运行
当主数据库发生异常时，自动的将从数据库升级为主数据库，继续保证整个服务的稳定

哨兵其实是一个独立的进程，如下图

在这里插入图片描述
当然，上图只是一个哨兵存在时的情况，但在现实中还会有两个，甚至更多哨兵存在的情况

在这里插入图片描述

实现原理

当一个哨兵进程启动时，它会先通过配置文件，找我们的主数据库，当然，我们这里也只需要配置其监控的主数据库就好，之后哨兵会自动发现所有复制该主数据库的从数据库，当然一个哨兵是可以监控多个redis系统的，同时，多个哨兵也可以同时监控一个redis系统的，这里moon先给大家灌输下这个概念，大家理解下，详细的我会在后文提到。

哨兵进程启动后后会和master建立两条链接

用来获取其他同样在监控着此redis系统的哨兵信息
发送一个info命令来获取此redis系统master本身的信息

当和master完成链接建立后，该哨兵就会定时的做以下三件事情

每10秒会向master和slave发送info命令
每2秒会向master和slave发送自己的信息
每1秒会向master，slave以及其他同样在监控着此redis系统的哨兵发送ping命令

以上三个操作可是说是哨兵的核心了，下面就着重介绍一下这三个命令

首先，info命令可以让哨兵获取到当前数据库的信息，比如运行id，复制信息等等，从而实现新节点的自动发现，从数据库的信息正是从info命令中获取的，获取从数据库信息后，就会和从数据库建立两条链接，和主数据库建立的链接是完全一样的，之后就会每10s向主从数据库发送info命令，当有新的从数据库加入时，就会从info命令中发现了，从而将这个新的slave加入自己的监控列表中。

当然如果有新的哨兵加入到了监控中，其他哨兵也是从这个info命令中获取的。

于此，就完成了对数据库以及其他哨兵的自动发现和监控，是不是很easy呢？？

以上讲了自动发现数据库和其他的哨兵节点，之后哨兵就开始了它的工作，就是去监控这些数据库和节点有没有停止，哨兵就会每隔一段时间向这些节点发送PING命令，如果一段时间没有收到回复后，那么这个哨兵就会认为该节点已经挂了，我们将其称为主观下线。

如果该节点是master，哨兵就会向其他节点询问，看其他节点时候也认为该master挂了，我们可以认为他们在投票，当票数达到了一定的次数，那么哨兵就认为该节点真的挂了，我们成为客观下线，然后哨兵之间就会选举，选出一个领头的哨兵对主从数据库发起故障的修复。