redis哨兵模式配置详解(redis 哨兵模式)

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

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

Redis集群哨兵模式配置优化解析

1、sentinel monitor

当所有节点启动后，配置文件中的内容发生了变化。

2、sentinel down-after-milliseconds

每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达，

3、sentinel parallel-syncs

parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。

4、sentinel failover-timeout

ailover-timeout通常被解释成故障转移超时时间，但实际上它作用于故障转移的各个阶段：

a）选出合适从节点。

b）晋升选出的从节点为主节点。

c）命令其余从节点复制新的主节点。

d）等待原主节点恢复后命令它去复制新的主节点。

failover-timeout的作用具体体现在四个方面：

1）如果Redis Sentinel对一个主节点故障转移失败，那么下次再对该主节点做故障转移的起始时间是failover-timeout的2倍。

2）在b）阶段带腊时，如果Sentinel节点向a）阶段选出来的从节点执行slaveof no one一直失败（例如该从节点此时出现故障），当此过程超过failover-timeout时，则故障转移失败。

3）在b）阶段如果执行成功，Sentinel节点还会执行info命令来确认a）阶段选出来的节点确实晋升为主节点，如果此过程执行时间超过failover-timeout时，则故障转移失悄派败。

4）如果c）阶段执行时间超过了failover-timeout（不包含复制时间），则故障转移失败。注意即使超过了这个时间，Sentinel节点也会最终配置从节点去同步最新的主节点。

5、sentinel auth-pass

如果Sentinel监控的主节点配置了密码，sentinel auth-pass配置通过添加主节点的密码，防止Sentinel节点对主节点无法监控。

6、sentinel notification-script

sentinel notification-script的作用是在故障转移期间，当一些警告级别的Sentinel事件发生（指重要事件，例如-sdown：客观下线、-odown：主观下线）时，会触发对应路径的脚本，并向脚本发送相应的事件参数。

7、sentinel client-reconfig-script

sentinel client-reconfig-script的作用是在故障转移结束后，会触发对应路径的脚本，并向脚本发送故障转移结果的相关参数

Redis Sentinel可以同时监控多个主节点，具体拓扑图如下：

配置方法也比较简单，和监控一个主节点配置类型，只需要指定多个masterName来区分不同的主节点即可。

Sentinel节点也支持动态地设置参数，而且和普通的Redis数据节点一样并不是支持所有的参数。

Sentinel节点可以使用sentinel set

支持的参数：

sentinel set命令只对当前Sentinel节点有效,sentinel set命令如果执行成功会立即刷新配置文件，这点和启行贺Redis普通数据节点设置配置需要执行config rewrite刷新到配置文件不同。建议所有Sentinel节点的配置尽可能一致，这样在故障发现和转移时比较容易达成一致。Sentinel对外不支持config命令。

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集群的故障转移。哨兵负责监控集群状态，当redis主节点发生故障，哨兵通过选举，选出替代的master节点。一般需要单数的哨兵进行选举，大多数达成一致。

问题：如果哨兵集群也有部分实例down了，出现偶数哨兵，或者只剩下一个哨兵会如何，还能进行故障转移吗。

为什么会出现这个问题：哨兵其实也是redis实例，一般情况下，哨兵是为了保证redis集群的故障转移。由于资源，以及网络通信的性能考虑，一般哨兵和redis会部署在同一物历唤游理机。如果一台物理机出现了物理故障，哨兵实例和redis服务实例会一起down掉。

本文章针对这个问题做一下实验。

使用3+3模式，3redis+3sentinel。

三台虚拟机，每台虚拟机运行1个redis+1个sentinel

ip、角色规划

    192.168.237.101：master，sentinel

    192.168.237.100：slave，sentinel

    192.168.237.103：slave，sentinel

安装redis、redis sentinel

    apt-get install redis-server

    apt-get install redis-sentinel

redis-server配置修改(/etc/redis/redis.conf)

redis-server slave配置修改

启动redis-server

    /etc/init.d/redis-server restart

查看redis-server主从集群情况

修改sentinel配置(/etc/redis/sentinel.conf)

    sentinel monitor mymaster 192.168.237.101 6379 2

    sentinel known-slave mymaster 192.168.237.100 6379

    protected-mode no

启动sentinel

    /etc/init.d/redis-sentinel start

查看redis-sentinel情况

预期：故障转移，哨兵选举出新的master

关掉redis-server（192.168.237.101）

查看sentinel日志（/链者var/log/redis/redis-sentinel.log）

可以看到，+odown master，哨兵检测master客观下线

然后进行投票：vote-for-leader

选出新的master：switch-master mymaster 192.168.237.101 6379 192.168.237.103 6379

192.168.237.101的sentinel日志：

查看redis和sentinel集群状态，确认master变成了192.168.237.103（master host）

恢复192.168.237.101的redis-server，查看日志，192.168.237.101转换成slave

预期：有两个sentinel，可能会出现，剩下两个slave各得一票的情况，按照哨兵原理，会等待一段时间进行再选举，直到某个slave有两票，完肢销成故障转移。

经过3.1实验，master转换到了192.168.237.103，现在先后关掉103上的sentinel和redis-server

查看两台sentinel的redis-sentinel日志，可以选出master，进行故障转移：

查看redis集群状态，确认master（192.168.237.100）

预期：无法切换

依次关掉两个sentinel，一个redis-server master。3.2节master转移到了100，恢复环境后，依次关掉103,100的sentinel，100的redis-server master

查看101上的sentinel日志，由于只有一个sentinel，只有101上的sentinel投票

恢复一个redis-sentinel，现有两个redis-sentinel

查看sentinel日志，选出101为master

      有两个sentinel或以上可以进行故障切换。单数sentinel更容易选出master，进行故障转移。

+sdown：主观down机

+odown：客观down机

+new-epoch：集群递增版本号

+vote-for-leader：在哨兵集群中投票选举出一个哨兵，作为本次执行故障转移操作的leader

+try-failover：开始对某ip进行故障转移

voted for：另一个哨兵进行投票

+elected-leader：在哨兵集群中再次确认进行即将执行故障转移的leader是哪一个哨兵。 

+selected-slave slave：选出leader

 +failover-state-send-slaveof-noone slaveLeader：向目标slave发送"slaveof-noone"指令，令其不要再做其它任何节点的slave了，从现在开始，它就是老大，完成从slave到master的转换。

+failover-state-wait-promotion slave：等待其它的sentinel确认slave

+promoted-slave slave：其它的sentinel全部确认成功

+failover-state-reconf-slaves：开始对集群中的所有slave做reconf操作(更新配置信息)

+slave-reconf-sent：向指定的slave发送"slaveof"指令，令其跟随新的master

+switch-master：故障转移完毕后，各个sentinel开始监控新的master