中电金信技术实践｜Redis哨兵原理及安装部署分享

导语：本文主要围绕redis Sentinel的基本概念、部署Redis Sentinel模式和其相关的API等内容进行介绍，并讲述哨兵与主从关系的区别，以及哨兵机制是怎么实现高可用的，希望可以与各位同仁共同交流探讨。

首先，我们带着以下问题去阅读本篇文章：

1.Redis下怎么实现故障迁移？

2.你对Redis高可用的理解有多少？

3.Sentinel的工作机制是什么？

4.Sentinel有哪些功能？

5.Sentinel的配置过程，主要配置参数是什么？

6.如何从节点中选举新的主节点？

一、基本概念

1. 主从模式下的故障迁移

编辑

■　当主节点发生故障后，客户端连接主节点失败，从节点与主节点连接失败，从而造成复制中断，如果没能及时发现并处理，就会造成一部分数据的丢失。

■　当主节点无法正常提供服务时，需要选出一个从节点，对其执行slaveof no one命令使其成为新的主节点。

■　在切换主节点后，需要人为的去更新应用方的节点信息，更新后需要重启。

■　在客户端建立新的主从关系，使得从节点从新的主节点复制。在原来的主节点恢复后，当作从节点使用，从新的主节点复制信息。

由于整个故障迁移中，大的过程都需要人为的介入，所以不能达到高可用的要求，因此Redis Sebtinel应运而生。

2. Redis Sentinel的高可用

编辑

Redis Sentinel 是一个分布式架构，其中包含若干的Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行控制，当发现节点不可达时，会对节点做下线标识。

如果被标识的节点是主节点，Sentinel会和其他Sentinel进行协商，通过半数以上的Sentinel都认为该主节点不可达时，则开始从从节点中进行选举，从而达到故障迁移的目的。整个过程由Sentinel自动完成。

3. 故障迁移的步骤

编辑

■　主节点出现故障时，从节点会与主节点失去连接，从而导致复制失败；

■　每个Sentinel节点通过定期监控发现主节点故障；

■　多个Sentinel节点对主节点的故障达到一致，选举出一个Sentinel节点去负责故障迁移；

■　Sentinel执行故障迁移，执行故障迁移的过程与主从复制的故障迁移相同，但 Sentinel的故障迁移属于自动完成，无需人工。

4. Redis Sentinel的主要功能

编辑

■　通知：Sentinel节点会将故障转移的结果通知给应用方；

■　主节点故障迁移：实现从节点晋升为主节点并维护后续正确的主从关系；

■　配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息；

■　监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。

二、安装和部署

1. Redis Sentinel的基本拓扑结构

编辑

2. Redis主节点配置

编辑

■　准备工作: 设置静态ip

vi /etc/sysconf ig/network -scr ipts/ ifcfg -ens33

编辑

配置完成后保存退出并执行service network restart来重启网络服务，使得配置生效。

■　准备工作: 传输redis压缩包并解压

tar -zxvf redis-5.0.4.tar.gz（这里我们使用的版本是redis-5.0.4）

编辑

■　准备工作: 执行make和make install对redis进行编译

编辑

■　准备工作: 创建Sentinel文件并将配置文件改名并复制到Sentinel

这些cp命令是在redis根目录下执行

复制redis配置文件

cp redis.conf sentinel/redis.6379.confcp redis.conf sentinel/redis.6380.confcp redis.conf sentinel/redis.6381.conf

复制哨兵配置文件

cp sentinel.conf sentinel/sentinel.26379.confcp sentinel.conf sentinel/sentinel.26380.confcp sentinel.conf sentinel/sentinel.26381.conf

编辑

我们按照之前的拓扑图，将redis.6379.conf作为主节点进行配置。

修改redis.conf配置，这些配置是分散在配置文件中，需要逐个进行修改。

#bind 127.0.0.1 注释掉绑定的IPprotected-mode no 关闭保护模式port 6379 设置端口logfile "redis.6379.log" 配置log日志文件的名称daemonize yes 开启后台启动dbfilename redis.6379.rdb 修改rdb持久化文件的名称dir "/home/redis/redis-5.0.4/sentinel/ 修改rdb持久化文件的位置

我们按照之前的拓扑图，将redis.6380.conf和redis.6381.conf作为从节点进行配置。

Redis从节点配置

#bind 127.0.0.1 注释掉绑定的IPprotected-mode no 关闭保护模式port 6380 设置端口logfile "redis.6380.log" 配置log日志文件的名称daemonize yes 开启后台启动dbfilename redis.6380.rdb 修改rdb持久化文件的名称dir "/home/redis/redis-5.0.4/sentinel/ " 修改rdb持久化文件的位置slaveof 192.168.72.166 6379 配置主节点的挂载

Redis主从节启动

进入redis部署目录，执行：

redis-server redis.6379.confredis-server redis.6380.confredis-server redis.6381.conf

节点启动完成后使用redis-cli -p 6379进入主节点执行info replication查看主从关系。

编辑

Sentinel节点配置

protected-mode no 关闭保护模式port 26379 设置端口daemonize yes 将后台启动设置为yes

sentinel monitor mymaster 192.168.72.166 6379 2 配置Sentinel要监控的节点名称，以及主节点的IP和端口，最后一个数字则是表明Sentinel在进行选举是需要几个Sentinel节点认为该主节点宕机后，进行选举。一般情况下这个数字要大于Sentinel节点的半数。

sentinel down-after-milliseconds mymaster 30000 设置Sentinel认为Redis实例已经失效的时间，即在这个时间段内Sentinel发出的ping没有得到redis返回的pong，那么Sentinel就将这个redis实例标记为主观下线。

sentinel parallel-syncs mymaster 1 设置最多可以有多少个redis从节点同步更新的主节点，这个数字越小，则实现故障迁移的时间就越长。

sentinel failover-timeout mymaster 180000 如果在该时间内没有完成故障迁移，则视为故障迁移失败，重新开始选举新的主节点。

启动并进行确认

redis-sentinel sentinel.26379.confredis-sentinel sentinel.26380.confredis-sentinel sentinel.26381.confredis-cli -h 127.0.0.1 -p 26379 info Sentinel

编辑

三、Redis Sentinel的部署技巧

■　在生产环境下Sentinel节点不应该部署在同一台物理机上。这里强调说明不是虚拟机，而是物理机，我们在学习和测试的过程中会将Sentinel部署在一台或多台虚拟机上，但在生产环境下我们不能这么做，因为一旦物理机出现故障，所有的虚拟机都会受到影响。

■　在部署Sentinel节点时至少部署三个以上的奇数个节点。因为判断和选举时需要半数以上的Sentinel节点进行投票才可以继续故障迁移，而偶数个Sentinel节点可能会出现一半一半的场景，导致故障迁移不能继续进行。

■　在多个主节点部署Sentinel时有以下两个方案：

方案一：部署一套Sentinel，在Sentinel.conf文件中配置多个主节点信息，这样配置的优点在于便于管理和维护。但是缺点也比较明显，即这一套Sentinel出现异常时，可能会对多个redis数据节点造成影响。

方案二：部署多套Sentinel，为每个主节点部署一套Sentinel。这样的话，每套Redis Sentinel是互相隔离的，彼此之间不会互相影响。缺点则是会造成资源的浪费，管理和维护起来比较麻烦。

四、API

■　sentinel masters

展示所有被监控的主节点状态以及相关的统计信息

■　sentinel master<master name>

展示指定名称的主节点状态以及相关的统计信息

■　sentinel slaves<master name>

展示指定主节点名称的从节点状态以及相关的统计信息

■　sentinel sentinels<master name>

展示指定<master name>的Sentinel节点集合（不包含当前Sentinel节点）

■　sentinel get-master-addr-by-name<master name>

返回指定<master name>主节点的IP地址和端口

■　sentinel failover<master name>

对指定<master name>主节点进行强制故障转移（没有和其他Sentinel节点“协商”），当故障转移完成后，其他Sentinel节点按照故障转移的结果更新自身配置。这个命令在Redis Sentinel的日常运维中非常有用。

■　sentinel flushconfig

将Sentinel节点的配置强制刷到磁盘上，这个命令Sentinel节点自身用得比较多，对于开发和运维人员来说，如果出现外部原因（例如磁盘损坏）造成配置文件损坏或者丢失时，这个命令是很有用的。

■　sentinel remove<master name>

取消当前Sentinel节点对于指定<master name>主节点的监控。

■　sentinel monitor<master name><ip><port><quorum>

这个命令和配置文件中的含义是完全一样的，只不过是通过命令的形式来完成Sentinel节点对主节点的监控。

■　sentinel set<master name>

动态修改Sentinel节点配置选项。

五、Jedis客户端连接

@Test public void testSentinel() { Set<String> sentinels = new HashSet<>(); sentinels.add("192.168.72.164:7000"); ........... JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels); Jedis jedis = pool.getResource(); jedis.set("AA1", "AA1"); System.out.println("获取数据："+jedis.get("AA1")); }

六、实现原理

1. 三个定时监控任务

编辑

■　每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。

这个定时任务具体可以体现在以下几个方面：

①通过向主节点执行info命令，获取从节点信息；

②每当有新的从节点加入时可以立刻感知出来；

③节点不可达或者故障迁移后，可以通过info命令来及时更新节点的拓扑信息。

■　每隔2秒，每个Sentinel节点会向Redis数据节点的_sentinel_:hello频道上发送该sentinel节点对于主节点的判断以及当前Sentinel节点的信息。同时每个Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及他们对主节点的判断，这个定时任务可以完成发现新的Sentinel节点和Sentinel节点之间交换主节点状态。

■　每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发出一条ping命令的心跳检测，来确认这些节点当前是否可达。

2. 主观下线和客观下线

编辑

■　主观下线指的是在Sentinel节点发出ping命令做心跳检测时，在超过配置文件中的回复超时时间down-after-milliseconds没有收到任何回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线。

■　客观下线指的是当主观下线的节点是主节点时，该Sentinel节点会向其他Sentinel节点询问对主节点的判断，当超过半数以上的Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的，这种方式就叫做客观下线。

3. 故障迁移

编辑

■　在从节点中选出一个节点作为新的主节点，选择方法如下：

①过滤掉“不健康”（主观下线、断线）、5秒内没有回复Sentinel节点ping响应、与主节点失联超过10秒的；

②选择从节点优先级最高的从节点列表，如果存在则返回，不存在则继续；

③选择复制偏移量最大的从节点（复制最完整），如果存在则返回，不存在则继续；

④选择runid最小的从节点（Redis服务器的随机标识符（用于Sentinel和集群），重启后就会改变。）