导语：本文主要围绕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和集群），重启后就会改变。）
■ Sentinel节点对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
■ Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点，复制规则和 parallel-syncs 参数有关。
■ Sentinel节点集合会将原来的主节点更新为从节点，并保持着对它的关注，当其恢复后再命令它去复制新的主节点。
*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。
发布文章
