redis哨兵（redis哨兵模式）

本篇文章给大家谈谈redis哨兵，以及redis哨兵模式对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、搞懂Redis (八) - 哨兵机制
• 2、简介redis之哨兵集群搭建
• 3、Redis哨兵（Sentinel）模式
• 4、redis主从和哨兵
• 5、Redis哨兵模式（故障转移测试）

搞懂Redis (八) - 哨兵机制

哨兵的核心功能是主节点的自动故障转移

下图是一个典型的哨兵集群监控的逻芦配辑图

Redis Sentinel包含了若拍册干个Sentinel 节点，这样做也带来了两个好处：

1、 对于节点的故障判断是由多个sentinel节点共同完成，这样可以有效地防止误判

2、即使个别sentinel节点不可用，整个sentinel集群依然是可用的

哨兵实现了以下功能：

1、监控：每个sentinel节点会对数据节点（Redis master/slave节点）和其余sentinel节点进行监控

2、通知：sentinel节点会将故障转移的结果通知给应用方

3、故障转移：实现slave晋升为master，并维护后续正确的主从关系

4、配置中心：在Redis sentinel模式中，客户端在初始化的时候连接的是sentinel节点集合，从中获取主节点信息

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置中心和通知功能，则需要在与客户端的交互中才能体现

1、原理

监控

sentinel节点需要监控master、slave以及其他sentinel节点的状态。这一过程是通过Redis的pub\sub系统实现的。Redis sentinel一共有三个定时监控任务，完成对各个节点发现和监控：

主观/客观下线

主观下线

每个sentinel节点，每隔1s会对数据节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复时，sentinel节点会对该节点做失败判定，这叫主观下线

客观下线

客观下线，是指当大多数sentinel节点都认为master节点宕机了，那这个判定就是客观的，叫客观下线。

那大多数是指什么呢？ 其实就是分布式协调中的quorum判定啦，大多数就是指半数。 如哨兵数量是5，那大多数就是5/2+1=3个，哨兵数量是10大多数就是10/2+1=6个。

注：sentinel节点的数量至少为3个，否则不满足quorum判定条件

哨兵选举

如果发生了客观袭哗宏下线，那哨兵节点会选举出一个leader来进行实际的故障转移工作。Redis使用了Raft算法来实现哨兵领导者选举，大致思路如下：

故障转移

选举出的leader sentinel节点将负责故障转移，也就是进行master/slave节点的主从切换。故障转移，首先要从slave节点中筛选出一个作为新的master，主要考虑以下slave信息

注：Leader sentinel 节点，会从新的master节点那里得到一个configuration epoch，本质是个version版本号，每次主从切换的version号都必须是唯一的。其他的哨兵都是根据version来更新自己的master配置

[img]

简介redis之哨兵集群搭建

在之前的主从辅助中有提到，如果从库发生故障，从库重连后会借助repl_backlog_buffer这个环形缓冲区实现增量复制，来此谈枣达到数据相同的操作。

但是主库挂了怎么办？我们的redis服务总不可能只提供读服务吧(主库挂了从库仍可读)，redis的哨兵机制有效的解决了这个问题

要开放26379端口为哨兵进程使用(哨兵进程说白了就是个监听主实例运行状况的进程)

分别进入容器运行sentinel

观察日志

查看日志

完成

哨兵进程主要负责三个任务

哨兵检测从库，若从库响应超时则标为 主观下线 ，因为从库的下线对集群影响不大

哨兵检测主库，若主库响应超时则标为 客观下线 ，这个因为网络延迟等不可避免的原因可能被误判，所以为减少误判需要进行多人投票，对应该设置的2，表示要2台从库标记为客观侍散下线

筛选之后按照一定的规则，逐个打分

由于Redis提供的发布/订阅机制(pub/sub)，哨兵实例之间可以互相发现对方

哨兵实例只要和主库建立连接，就可以 在主库上发布自己的连接信息(IP和端口) ，因此他们能获取彼此的IP地址和端口

同时，哨兵也会向主库发送info命令获取集群的主从列表信息，这样就可以和每个从库建立连接并持续监控

注意：如果假设上面的哨兵集群只有2个实例（2从），一个哨兵挂了，另一个想称为leader是不可能的，因为设置决定必须获得2票，而森拆不是自己的一票

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主从和哨兵

主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性

a,配置主从复制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379启动完后再启6380，完成配置；

b,配置主从世数早复制方式二、redis-server --slaveof 192.168.152.128 6379 临时生效

c,查看状态：info replication

d,断开主从复制：在slave节点，执行6380:slaveof no one

e,断开后再变成主从复制：6380: slaveof 192.168.152.128 6379

f,数据较重要的节点，主从复制时使用密码验证： requirepass

e, 从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致

h,传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭

参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景，

参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房

a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响

b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送搜雀一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。

redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制

全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）

部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步

心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主

b)主从复制主节点的写能力单机，能力有限

c)单机节点的存储能力也有限

a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；

b)其它的节点成为新主节点的从节点，并从新毕简节点复制数据；

c)需要人工干预，无法实现高可用。

1. 为什么要有哨兵机制？

原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的

任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线

a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；

b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；

c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

a)由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行

流程：

1. 将slave-1脱离原从节点，升级主节点，

d) 故障转移后的redis sentinel的拓扑结构图

a) 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点

b) 选择salve-priority从节点优先级最高（redis.conf）的

c) 选择复制偏移量最大，指复制最完整的从节点

以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署

1. 前提： 先搭好一主两从redis的主从复制，和之前的主从复制搭建一样，搭建方式如下：

A）主节点6379节点（/usr/local/bin/conf/redis6379.conf）：

修改 requirepass 12345678，注释掉#bind 127.0.0.1

B) 从节点redis6380.conf和redis6381.conf: 配置都一样

修改 requirepass 12345678 ,注释掉#bind 127.0.0.1,

加上访问主节点的密码masterauth 12345678 ,加上slaveof 192.168.152.128 6379

2. redis sentinel哨兵机制核心配置 (也是3个节点)：

将三个文件的端口改成: 26379 26380 26381

然后：sentinel monitor mymaster 192.168.152.128 6379 2 //监听主节点6379

三个配置除端口外，其它一样。

3. 哨兵其它的配置 ：只要修改每个sentinel.conf的这段配置即可：

sentinel monitor mymaster 192.168.152.128 6379 2

//监控主节点的IP地址端口，sentinel监控的master的名字叫做mymaster，2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了

sentinel auth-pass mymaster 12345678 //sentinel连主节点的密码

sentinel config-epoch mymaster 2 //故障转移时最多可以有2从节点同时对新主节点进行数据同步

sentinel leader-epoch mymaster 2

sentinel failover-timeout mymasterA **180000 **//故障转移超时时间180s，

a,如果转移超时失败，下次转移时时间为之前的2倍；

b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过 180S 时，则故障转移失败

c,从节点复制新主节点时间超过 180S 转移失败

sentinel down-after-milliseconds mymasterA 300000 //sentinel节点定期向主节点ping命令，当超过了 300S 时间后没有回复，可能就认定为此主节点出现故障了……

sentinel parallel-syncs mymasterA 1 //故障转移后， 1 代表每个从节点按顺序排队一个一个复制主节点数据，如果为3，指3个从节点同时并发复制主节点数据，不会影响阻塞，但存在网络和IO开销

4. 启动redis服务和sentinel服务:

a)先把之前安装的redis里面的标绿色的文件都拷贝到 usr/local/bin目录下，然后再再bin目录下新建一个conf文件夹存放配置好的redis主从配置文件和哨兵配置文件

b)启动主从复制服务，先启动主再启动从

主：./redis-server conf/redis6379.conf

从：

./redis-server conf/redis6380.conf

./redis-server conf/redis6381.conf

c）启动sentinel服务:

./redis-sentinel conf/sentinel_26381.conf

到此服务全部启动完毕

连接到6379的redis的服务，可看到6379就是主节点，他有6380和6381两个从节点

5. 测试： kill -9 6379 杀掉6379的redis服务

可以看到杀掉6379以后6380变为了主节点，6381变为了6380的从节点

重新启动6379以后变为6380的从节点

看日志是分配6380 是6381的主节点，当6379服务再启动时，已变成从节点

假设6380升级为主节点:进入6380info replication 可以看到role:master

打开sentinel_26379.conf等三个配置，sentinel monitor mymaster 192.168.152.128 6380 2

打开redis6379.conf等三个配置, slaveof 192.168.152.128 6380,也变成了6380

注意：生产环境建议让redis Sentinel部署到不同的物理机上。

a，sentinel节点应部署在多台物理机（线上环境）

b，至少三个且奇数个sentinel节点

c，通过以上我们知道，3个sentinel可同时监控一个主节点或多个主节点

sentinel参考资料：

redis sentinel的机制与用法一：

redis sentinel的机制与用法二：

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

关于redis哨兵和redis哨兵模式的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。