共计 8823 个字符，预计需要花费 23 分钟才能阅读完成。
本篇文章给大家分享的是有关如何理解 Redis 哨兵技术，丸趣 TV 小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着丸趣 TV 小编一起来看看吧。
丸趣 TV 小编将要介绍的哨兵，它基于 Redis 主从复制，主要作用便是解决主节点故障恢复的自动化问题，进一步提高系统的高可用性。
注：内容基于 Redis 3.0 版本。
一、作用和架构
1. 作用
在介绍哨兵之前，首先从宏观角度回顾一下 Redis 实现高可用相关的技术。它们包括：持久化、复制、哨兵和集群，其主要作用和解决的问题是：
持久化：持久化是最简单的高可用方法（有时甚至不被归为高可用的手段），主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
复制：复制是高可用 Redis 的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷是写操作无法负载均衡；存储能力受到单机的限制。
集群：通过集群，Redis 解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
详细内容可回顾：
下面说回哨兵。
Redis Sentinel，即 Redis 哨兵，在 Redis 2.8 版本开始引入。哨兵的核心功能是主节点的自动故障转移。下面是 Redis 官方文档对于哨兵功能的描述：
监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移（Automatic Failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
配置提供者（Configuration Provider）：客户端在初始化时，通过连接哨兵来获得当前 Redis 服务的主节点地址。
通知（Notification）：哨兵可以将故障转移的结果发送给客户端。
其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。
这里对“客户端”一词在文章中的用法做一个说明：在前面的文章中，只要通过 API 访问 Redis 服务器，都会称作客户端，包括 Redis-cli、Java 客户端 Jedis 等。为了便于区分说明，本文中的客户端并不包括 Redis-cli，而是比 Redis-cli 更加复杂：Redis-cli 使用的是 Redis 提供的底层接口，而客户端则对这些接口、功能进行了封装，以便充分利用哨兵的配置提供者和通知功能。
2. 架构
典型的哨兵架构图如下所示：
它由两部分组成：
哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据。
数据节点：主节点和从节点都是数据节点。
二、部署
这一部分将部署一个简单的哨兵系统，包含 1 个主节点、2 个从节点和 3 个哨兵节点。方便起见，所有这些节点都部署在一台机器上（局域网 IP：192.168.92.128），使用端口号区分；且节点的配置尽可能简化。
1. 部署主从节点
哨兵系统中的主从节点，与普通的主从节点配置是一样的，并不需要做任何额外配置。下面分别是主节点（port=6379）和 2 个从节点（port=6380/6381）的配置文件，配置都比较简单，不再详述：
#redis-6379.conf port 6379 daemonize yes logfile 6379.log dbfilename dump-6379.rdb #redis-6380.conf port 6380 daemonize yes logfile 6380.log dbfilename dump-6380.rdb slaveof 192.168.92.128 6379 #redis-6381.conf port 6381 daemonize yes logfile 6381.log dbfilename dump-6381.rdb slaveof 192.168.92.128 6379配置完成后，依次启动主节点和从节点：
redis-server redis-6379.conf
redis-server redis-6380.conf
redis-server redis-6381.conf
节点启动后，连接主节点查看主从状态是否正常，如下图所示：
2. 部署哨兵节点
哨兵节点本质上是特殊的 Redis 节点。
3 个哨兵节点的配置几乎是完全一样的，主要区别在于端口号的不同（26379 / 26380 / 263 81），下面以 26379 节点为例介绍节点的配置和启动方式；配置部分尽量简化，更多配置会在后面介绍：
#sentinel-26379.conf port 26379 daemonize yes logfile 26379.log sentinel monitor mymaster 192.168.92.128 6379 2其中，sentinel monitor mymaster 192.168. 92.128 6379 2 配置的含义是：该哨兵节点监控 192.168.92.128:6379 这个主节点，该主节点的名称是 mymaster，*** 的 2 的含义与主节点的故障判定有关：至少需要 2 个哨兵节点同意，才能判定主节点故障并进行故障转移。
哨兵节点的启动有两种方式，二者作用是完全相同的：
redis-sentinel sentinel-26379.conf
redis-server sentinel-26379.conf –sentinel
按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过 Redis-cli 连接哨兵节点进行验证，如下图所示：可以看出 26379 哨兵节点已经在监控 mymaster 主节点（即 192.168.92.128:6379），并发现了其 2 个从节点和另外 2 个哨兵节点。
此时如果查看哨兵节点的配置文件，会发现一些变化，以 26379 为例：
其中，dir 只是显式声明了数据和日志所在的目录（在哨兵语境下只有日志）；known-slave 和 known-sentinel 显示哨兵已经发现了从节点和其他哨兵；带有 epoch 的参数与配置纪元有关（配置纪元是一个从 0 开始的计数器，每进行一次 *** 哨兵选举，都会 +1；*** 哨兵选举是故障转移阶段的一个操作，在后文原理部分会介绍）。
3. 演示故障转移
哨兵的 4 个作用中，配置提供者和通知需要客户端的配合，本文将在下一章介绍客户端访问哨兵系统的方法时详细介绍。这一小节将演示当主节点发生故障时，哨兵的监控和自动故障转移功能。
Step1：首先，使用 kill 命令杀掉主节点：
Step2：如果此时立即在哨兵节点中使用 info Sentinel 命令查看，会发现主节点还没有切换过来，因为哨兵发现主节点故障并转移，需要一段时间。
Step3：一段时间以后，再次在哨兵节点中执行 info Sentinel 查看，发现主节点已经切换成 6380 节点。
但是同时可以发现，哨兵节点认为新的主节点仍然有 2 个从节点，这是因为哨兵在将 6380 切换成主节点的同时，将 6379 节点置为其从节点；虽然 6379 从节点已经挂掉，但是由于哨兵并不会对从节点进行客观下线（其含义将在原理部分介绍），因此认为该从节点一直存在。当 6379 节点重新启动后，会自动变成 6380 节点的从节点。下面验证一下。
Step4：重启 6379 节点，可以看到 6379 节点成为了 6380 节点的从节点。
Step5：在故障转移阶段，哨兵和主从节点的配置文件都会被改写。
对于主从节点，主要是 slaveof 配置的变化：新的主节点没有了 slaveof 配置，其从节点则 slaveof 新的主节点。
对于哨兵节点，除了主从节点信息的变化，纪元 (epoch) 也会变化，下图中可以看到纪元相关的参数都 + 1 了。
4. 总结
哨兵系统的搭建过程，有几点需要注意：
哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。
哨兵节点本质上是 Redis 节点。
每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。
在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写（Config Rewrite）。
本章的例子中，一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条 sentinel monitor 即可实现。
三、客户端访问哨兵系统
上一小节演示了哨兵的两大作用：监控和自动故障转移，本小节则结合客户端演示哨兵的另外两个作用：配置提供者和通知。
1. 代码示例
在介绍客户端的原理之前，先以 Java 客户端 Jedis 为例，演示一下使用方法：下面代码可以连接我们刚刚搭建的哨兵系统，并进行各种读写操作：
public static void testSentinel throws Exception { String masterName = mymaster Set String sentinels = new HashSet ; sentinels.add( 192.168.92.128:26379 sentinels.add( 192.168.92.128:26380 sentinels.add( 192.168.92.128:26381 JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); // 初始化过程做了很多工作 Jedis jedis = pool.getResource; jedis.set(key1 , value1 pool.close; }（注：代码中只演示如何连接哨兵，异常处理、资源关闭等未考虑）
2. 客户端原理
Jedis 客户端对哨兵提供了很好的支持。如上述代码所示，我们只需要向 Jedis 提供哨兵节点集合和 masterName，构造 Jedis SentinelPool 对象；然后便可以像使用普通 Redis 连接池一样来使用了：通过 pool.getResource 获取连接，执行具体的命令。
在整个过程中，我们的代码不需要显式的指定主节点的地址，就可以连接到主节点；代码中对故障转移没有任何体现，就可以在哨兵完成故障转移后自动的切换主节点。之所以可以做到这一点，是因为在 JedisSentinelPool 的构造器中，进行了相关的工作，主要包括以下两点：
遍历哨兵节点，获取主节点信息：遍历哨兵节点，通过其中一个哨兵节点 +masterName 获得主节点的信息；该功能是通过调用哨兵节点的 sentinel get-master-addr-by-name 命令实现，该命令示例如下：
一旦获得主节点信息，停止遍历（因此一般来说遍历到 *** 个哨兵节点，循环就停止了）。
增加对哨兵的监听：这样当发生故障转移时，客户端便可以收到哨兵的通知，从而完成主节点的切换。具体做法是：利用 Redis 提供的发布订阅功能，为每一个哨兵节点开启一个单独的线程，订阅哨兵节点的 +switch-master 频道，当收到消息时，重新初始化连接池。
3. 总结
通过客户端原理的介绍，可以加深对哨兵功能的理解，如下：
配置提供者：客户端可以通过哨兵节点 +masterName 获取主节点信息，在这里哨兵起到的作用就是配置提供者。
需要注意的是，哨兵只是配置提供者，而不是代理。二者的区别在于：
如果是配置提供者，客户端在通过哨兵获得主节点信息后，会直接建立到主节点的连接，后续的请求（如 set/get）会直接发向主节点；
如果是代理，客户端的每一次请求都会发向哨兵，哨兵再通过主节点处理请求。
举一个例子可以很好的理解哨兵的作用是配置提供者，而不是代理。在前面部署的哨兵系统中，将哨兵节点的配置文件进行如下修改：
sentinel monitor mymaster 192.168.92.128 6379 2
改为
sentinel monitor mymaster 127.0.0.1 6379 2
然后，将前述客户端代码在局域网的另外一台机器上运行，会发现客户端无法连接主节点；这是因为哨兵作为配置提供者，客户端通过它查询到主节点的地址为 127.0.0.1:6379，客户端会向 127.0.0.1:6379 建立 Redis 连接，自然无法连接。如果哨兵是代理，这个问题就不会出现了。
通知：哨兵节点在故障转移完成后，会将新的主节点信息发送给客户端，以便客户端及时切换主节点。
四、基本原理
前面介绍了哨兵部署、使用的基本方法，本部分介绍哨兵实现的基本原理。
1. 哨兵节点支持的命令
哨兵节点作为运行在特殊模式下的 Redis 节点，其支持的命令与普通的 Redis 节点不同。在运维中，我们可以通过这些命令查询或修改哨兵系统；不过更重要的是，哨兵系统要实现故障发现、故障转移等各种功能，离不开哨兵节点之间的通信，而通信的很大一部分是通过哨兵节点支持的命令来实现的。下面介绍哨兵节点支持的主要命令：
基础查询：
通过这些命令，可以查询哨兵系统的拓扑结构、节点信息、配置信息等。
info sentinel：获取监控的所有主节点的基本信息。
sentinel masters：获取监控的所有主节点的详细信息。
sentinel master mymaster：获取监控的主节点 mymaster 的详细信息。
sentinel slaves mymaster：获取监控的主节点 mymaster 的从节点的详细信息。
sentinel sentinels mymaster：获取监控的主节点 mymaster 的哨兵节点的详细信息。
sentinel get – master – addr – by- name mymaster：获取监控的主节点 mymaster 的地址信息，前文已有介绍。
sentinel is-master-down-by-addr：哨兵节点之间可以通过该命令询问主节点是否下线，从而对是否客观下线做出判断。
增加 / 移除对主节点的监控：
sentinel monitor mymaster2 192.168.92.128 16379 2：与部署哨兵节点时配置文件中的 sentinel monitor 功能完全一样，不再详述。
sentinel remove mymaster2：取消当前哨兵节点对主节点 mymaster2 的监控。
强制故障转移：
sentinel failover mymaster：该命令可以强制对 mymaster 执行故障转移，即便当前的主节点运行完好；例如，如果当前主节点所在机器即将报废，便可以提前通过 failover 命令进行故障转移。
2. 基本原理
关于哨兵的原理，关键是了解以下几个概念：
定时任务：每个哨兵节点维护了 3 个定时任务。定时任务的功能分别如下：通过向主从节点发送 info 命令获取 *** 的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送 ping 命令进行心跳检测，判断是否下线。
主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。
客观下线：哨兵节点在对主节点进行主观下线后，会通过 sentinel is-master-down-by-addr 命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。
需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。
选举哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个 *** 哨兵节点，并由该 *** 节点对其进行故障转移操作。
监视该主节点的所有哨兵都有可能被选为 ***，选举使用的算法是 Raft 算法；Raft 算法的基本思路是先到先得：即在一轮选举中，哨兵 A 向 B 发送成为 *** 的申请，如果 B 没有同意过其他哨兵，则会同意 A 成为 ***。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为 ***。
故障转移：选举出的 *** 哨兵，开始进行故障转移操作，该操作大体可以分为 3 个步骤：
在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后选择优先级 *** 的从节点（由 slave-priority 指定）；如果优先级无法区分，则选择复制偏移量 *** 的从节点；如果仍无法区分，则选择 runid 最小的从节点。
更新主从状态：通过 slaveof no one 命令，让选出来的从节点成为主节点；并通过 slaveof 命令让其他节点成为其从节点。
将已经下线的主节点（即 6379）设置为新的主节点的从节点，当 6379 重新上线后，它会成为新的主节点的从节点。
通过上述几个关键概念，可以基本了解哨兵的工作原理。为了更形象的说明，下图展示了 *** 哨兵节点的日志，包括从节点启动到完成故障转移。
五、配置与实践建议
1. 配置
下面介绍与哨兵相关的几个配置。
配置 1：sentinel monitor {masterName} {masterIp} {masterPort} {quorum}
sentinel monitor 是哨兵最核心的配置，在前文讲述部署哨兵节点时已说明，其中：masterName 指定了主节点名称，masterIp 和 masterPort 指定了主节点地址，quorum 是判断主节点客观下线的哨兵数量阈值：当判定主节点下线的哨兵数量达到 quorum 时，对主节点进行客观下线。建议取值为哨兵数量的一半加 1。
配置 2：sentinel down-after-milliseconds {masterName} {time}
sentinel down-after-milliseconds 与主观下线的判断有关：哨兵使用 ping 命令对其他节点进行心跳检测，如果其他节点超过 down-after-milliseconds 配置的时间没有回复，哨兵就会将其进行主观下线。该配置对主节点、从节点和哨兵节点的主观下线判定都有效。
down-after-milliseconds 的默认值是 30000，即 30s；可以根据不同的网络环境和应用要求来调整：值越大，对主观下线的判定会越宽松，好处是误判的可能性小，坏处是故障发现和故障转移的时间变长，客户端等待的时间也会变长。例如，如果应用对可用性要求较高，则可以将值适当调小，当故障发生时尽快完成转移；如果网络环境相对较差，可以适当提高该阈值，避免频繁误判。
配置 3：sentinel parallel – syncs {masterName} {number}
sentinel parallel-syncs 与故障转移之后从节点的复制有关：它规定了每次向新的主节点发起复制操作的从节点个数。例如，假设主节点切换完成之后，有 3 个从节点要向新的主节点发起复制；如果 parallel-syncs=1，则从节点会一个一个开始复制；如果 parallel-syncs=3，则 3 个从节点会一起开始复制。
parallel-syncs 取值越大，从节点完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大；应根据实际情况设置。例如，如果主节点的负载较低，而从节点对服务可用的要求较高，可以适量增加 parallel-syncs 取值。parallel-syncs 的默认值是 1。
配置 4：sentinel failover – timeout {masterName} {time}
sentinel failover-timeout 与故障转移超时的判断有关，但是该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时，例如如果主节点晋升从节点时间超过 timeout，或从节点向新的主节点发起复制操作的时间（不包括复制数据的时间）超过 timeout，都会导致故障转移超时失败。
failover-timeout 的默认值是 180000，即 180s；如果超时，则下一次该值会变为原来的 2 倍。
配置 5：除上述几个参数外，还有一些其他参数，如安全验证相关的参数，这里不做介绍。
2. 实践建议
哨兵节点的数量应不止一个。一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。
哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：*** 选举的决策、客观下线的决策等。
各个哨兵节点的配置应一致，包括硬件、参数等；此外，所有节点都应该使用 ntp 或类似服务，保证时间准确、一致。
哨兵的配置提供者和通知客户端功能，需要客户端的支持才能实现，如前文所说的 Jedis；如果开发者使用的库未提供相应支持，则可能需要开发者自己实现。
当哨兵系统中的节点在 Docker（或其他可能进行端口映射的软件）中部署时，应特别注意端口映射可能会导致哨兵系统无法正常工作，因为哨兵的工作基于与其他节点的通信，而 Docker 的端口映射可能导致哨兵无法连接到其他节点。例如，哨兵之间互相发现，依赖于它们对外宣称的 IP 和 port，如果某个哨兵 A 部署在做了端口映射的 Docker 中，那么其他哨兵使用 A 宣称的 port 无法连接到 A。
在主从复制的基础上，哨兵引入了主节点的自动故障转移，进一步提高了 Redis 的高可用性；但是哨兵的缺陷同样很明显：哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要我们对从节点做额外的监控、切换操作。
以上就是如何理解 Redis 哨兵技术，丸趣 TV 小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注丸趣 TV 行业资讯频道。
