redis哨兵模式原理(redis哨兵模式的实现原理图)

扫码添加渲大师小管家，免费领取渲染插件、素材、模型、教程合集大礼包！

大家好，今天来介绍redis哨兵模式原理(redis的哨兵模式和集群模式的区别)的问题，以下是渲大师小编对此问题的归纳和整理，感兴趣的来一起看看吧！

Redis哨兵模式的实现原理

Redis哨兵此稿模式的实现原理。

关于哨兵的原理，关键是了解以下几个概念：

定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：通过向主从节点发送info命令获取最新的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送ping命令进行心跳检测，判断是否下线。

主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。

客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。

需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进橡茄行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说森如孝，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。

Redis中的哨兵模式

哨兵模式是一种自动选择老大的模式，即在老大宕机之后，哨兵模式会根据哨兵们的内部投票，自动的重新选出一个新的老大。哨兵模式是一种特唯租带殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，如果Redis服务器一直没有响应，说明这个Redis服务器可能已经宕机了，从而监控运行的多个Redis实例。

这里的哨兵有两个作用
1、通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
2、当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下故障切换(failover)的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。如果有三个哨兵，不仅每个哨兵会监视主机和从机，而且哨兵之间也会互相监视，如下图：

配置哨兵配置文件sentinel.conf，如下

当哨兵模式的配置文件配置好之后，就可以启动哨兵模式了，如下图

测试在哨兵模式下如果主机崩了的话会不会从从机中自动选出一个老大，先关闭主机，让主机宕机，如下图：

看看主机宕机之后，哨兵模式中输出日志的新的内容是什么，如下图：

哨兵模式自动选举一个主机这个过程是怎样实现自动化的？哨兵自动选举之前的某个从机为老大，所有的从机都会称新选出的从机为老大，以及原本的老大也会称新选出的老大为老大，这个过程是怎么自动化实现的呢？是通过在对应的redis服务器的配置文件中写内容来实现的，比方说，让我们看一下新老大也即是端口号是6381的redis服务器的配置文件中是怎样改写的，如下图：

再来看一下从机即端口号是6380的redis服指芦务器对应的配置文件是怎样改写的，如下图：

最后看一下原本的主机即端口号是6379的redis服务器的配置文件是怎样改写的。我检查了一下，发现在重新启动原本的老大即重启已经宕机的端口号是6379的redis服务器之前，它对应的配置文件中没有发生任何改变，但是一旦重新启动原本的老大，它对应的配置文件就会发生变化，如下图：

哨兵模式中的主机关闭之后需要特别注意的一个易错点：就是因为现在老大已经换了，所以老大的认证密码也换了，因此型大需要在现任老大的所有从机里面配置主机的认证密码，这个哨兵模式是不会帮我们自动配置的，需要我们自动配置，如下图：

测试哨兵模式结果，如下图：

1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有。

2、主从可以切换，故障可以转移，系统的可用性就会更好。

3、哨兵模式就是主从模式的升级，手动到自动，更加健壮。

1、集群容量一旦到达上限，在线扩容十分麻烦。

2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择。

当Redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤：

Sentinel集群的每一个Sentinel节点会定时对Redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该Redis节点被该Sentinel节点主观下线。

当节点被一个Sentinel节点记为主观下线时，并不意味着该节点肯定故障了，还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。

该Sentinel节点会询问其他Sentinel节点，如果Sentinel集群中超过quorum数量的Sentinel节点认为该Redis节点主观下线，则该redis客观下线。

如果客观下线的redis节点是从节点或者是Sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的Redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。

如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。

每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。

如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/2+1的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。

当Sentinel集群选举出Sentinel Leader后，由Sentinel Leader从redis从节点中选择一个redis节点作为主节点：

详解redis集群选举机制

Redis哨兵（Sentinel）模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。 这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式 。

一、哨兵模式概述

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

Redis哨兵

这里的哨兵有两个作用

通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

当哨兵监测到master宕机，会自动将slave切换成master，然后通过 发布订阅模式 通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程简搜州对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

用文字描述一下 故障切换（failover） 的过程。假设主服务器宕机，哨兵1先检测到这个拦蔽结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线 。这样对于客户端而言，一切都是透明的。

二、Redis配置哨兵模式

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

服务类型是否是主服务器IP地址端口

Redis是192.168.11.1286379

Redis否192.168.11.1296379

Redis否192.168.11.1306379

Sentinel-192.168.11.12826379

Sentinel-192.168.11.12926379

Sentinel-192.168.11.13026379

多哨兵监控Redis

首先配置Redis的主从服务器，修改redis.conf文件如下

上述内容主要是配置Redis服务器，从服务器比主服务器多一个slaveof的配置和密码。

配置3个哨兵，每个哨兵的配置都是一样的。在Redis安漏肢装目录下有一个sentinel.conf文件，copy一份进行修改

上述关闭了保护模式，便于测试。

有了上述的修改，我们可以进入Redis的安装目录的src目录，通过下面的命令启动服务器和哨兵

注意启动的顺序。 首先是主机（192.168.11.128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。

三、Java中使用哨兵模式

    上面是通过Jedis进行使用的，同样也可以使用Spring进行配置RedisTemplate使用。

四、哨兵模式的其他配置项

        sentinel down-after-milliseconds配置项只是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用。对于其他哨兵而言，并不是这样认为。哨兵会记录这个消息，当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。

Redis哨兵机制原理浅析

上一篇文章Redis主从复制原理中简要地说明了主从复制的一个基本原理，包含全量复制、复制积压缓冲区与增量复制等内容，有兴趣的同学可以先看下。

利用主从复制，可以实现读写分离、数据备份等功能。但如果主库宕机后，需要运维人员手动地将一个从库提升为新主库，并将其他从库slaveof新主库，以此来实现故障恢复。

因此， 主从模式的一个缺点，就在于无法实现自动化地故障恢复 。Redis后来引入了哨兵机制，哨兵机制大大提升了系统的高可用性。

哨兵，就是站岗放哨的，时刻监控周围的一举一动，在第一时间发现敌情并发出及时的警报。

Redis中的哨兵（Sentinel）， 则是一个特殊的Redis实例郑雹 ，不过它并不存储数据。也就是说，哨兵在启动时，不会去加载RDB文件。

关于Redis的持久化，可以参考我的另外一篇文章 谈谈Redis的持久化——AOF日志与RDB快照

上图就是一个典型的哨兵架构，由数据节点与哨兵节点构成，通常会部署多个哨兵节点。

哨兵主要具有三个作用， 监控、选主与通知 。

监控：哨兵会利用心跳机制，周期性不断地检测主库与从库的存活性

选主：哨兵检测到主库宕机后，选择一个从库将之切换为新主库

通知：哨兵会将新主库的地址通知到所有从库，使得所有从喊族帆库与旧主库slaveof新主库，也会将新主库的地址通知到客户端上

我会在下文详细讲一下监控与选主的过程

哨兵系统是通过3个定时任务，来完成对主库、从库与哨兵之间的探活。

首先我们会在配置文件中配置主库地址，这样哨兵在启动后，会以 每隔10秒 的频率向主库发送info命令，从而穗和获得当前的主从拓扑关系，这样就拿到了所有从库的地址。

在此基础上，哨兵会 每隔1秒 向主库、从库与其他哨兵节点发送PING命令，因此来进行互相探活。

当某个哨兵在 down-after-milliseconds（默认是30秒） 配置的连续时间内，仍然没有收到主库的正确响应，则当前哨兵会认为主库 主观下线 ，并将其标记为sdown（subjective down）

为了避免当前哨兵对主库的误判，因此这个时候还需要参考其他哨兵的意见。

接着当前哨兵会向其他哨兵发送 sentinel is-master-down-by-addr 命令， 如果有半数以上（由quorum参数决定）的哨兵认为主库确实处于主观下线状态，则当前哨兵认为主库客观下线 ，标记为odown（objective down）

一旦某个主库被认定为客观下线时，这个时候需要进行哨兵选举，选举出一个领导者哨兵，来完成主从切换的过程。

哨兵A在向其他哨兵发送 sentinel is-master-down-by-addr 命令时，同时要求其他哨兵同意将其设置为Leader，也就是想获得其他哨兵的投票。

在每一轮选举中，每个哨兵仅有一票。投票遵循先来先到的原则，如果某个哨兵没有投给别人，就会投给哨兵A。

首先获得半数以上投票的哨兵，将被选举称为Leader。

这里的哨兵选举，采用的是Raft算法。这里不对Raft做详细的探讨，有兴趣的同学，可以参考我的另外一篇文章 22张图，带你入门分布式一致性算法Raft

该文章采用大量的图例，相信你可以从中学习到全新的知识，从而打开分布式一致性算法的大门，大伙们记得等我搞完Paxos与Zab。

过半投票机制也常用于很多算法中，例如RedLock，在半数以上的节点上加锁成功，才代表申请到了分布式锁，具体可参考这篇文章的最后 我用了上万字，走了一遍Redis实现分布式锁的坎坷之路，从单机到主从再到多实例，原来会发生这么多的问题

在Zookeeper选举中，同样也用到了过半投票机制，在这篇文章中 面试官：能给我画个Zookeeper选举的图吗？ 我从源码角度分析了Zookeeper选举的过程。

在选举到领导者哨兵后，将由该哨兵完成故障恢复工作。

故障恢复分为以下两步：

详细说一下第一步，挑选是有条件的。首先要过滤出不 健康 的节点，再按某种规则排序，最后取第一个从库，我们直接从源码入手：

因此，以下从库会被过滤出：

剩下的节点，就是 健康 的节点，此时再执行一次快速排序，排序的规则如下：

本文算是Redis哨兵的一个入门文章，主要讲了哨兵的作用，例如监控、选主和通知。

在Redis读写分离的情况下，使用哨兵可以很轻松地做到故障恢复，提升了整体的可用性。

但哨兵无法解决Redis单机写的瓶颈，这就需要引入集群模式，相应的文章也被列为明年的写作计划中。