Redis哨兵模式

公司项目中用到了 Redis 哨兵模式,碰巧昨天早上刷掘金看到一篇关于 Reids 哨兵模式的文章,讲解的非常细致。在动手实践了原文的搭建过程后,此处作一转载。原文链接:https://dbaplus.cn/news-158-2278-1.html

在前面分享的《读完这篇文章,就基本搞定了Redis主从复制》中我们曾提到,Redis主从复制的作用有数据热备、负载均衡、故障恢复等;但主从复制存在的一个问题是故障恢复无法自动化。本文将要介绍的哨兵,它基于Redis主从复制,主要作用便是解决主节点故障恢复的自动化问题,进一步提高系统的高可用性。

注:本文内容基于 Redis 3.0 版本。

一、作用和架构

作用

在介绍哨兵之前,首先从宏观角度回顾一下 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 提供的底层接口,而客户端则对这些接口、功能进行了封装,以便充分利用哨兵的配置提供者和通知功能。

架构

典型的哨兵架构图如下所示:

它由两部分组成:

  • 哨兵节点:哨兵系统由一个或多个哨兵节点组成,哨兵节点是特殊的Redis节点,不存储数据。

  • 数据节点:主节点和从节点都是数据节点。

二、部署

这一部分将部署一个简单的哨兵系统,包含 1 个主节点、2 个从节点和3个哨兵节点。方便起见,所有这些节点都部署在一台机器上(局域网IP:192.168.92.128),使用端口号区分;且节点的配置尽可能简化。

1.部署主从节点

哨兵系统中的主从节点,与普通的主从节点配置是一样的,并不需要做任何额外配置。下面分别是主节点(port=6379)和2个从节点(port=6380/6381)的配置文件,配置都比较简单,不再详述:

redis-6379.conf:

1
2
3
4
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"

redis-6380.conf:

1
2
3
4
5
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 192.168.92.128 6379

redis-6381.conf:

1
2
3
4
5
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 192.168.92.128 6379

配置完成后,依次启动主节点和从节点:

1
2
3
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:

1
2
3
4
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 个哨兵节点同意,才能判定主节点故障并进行故障转移

哨兵节点的启动有两种方式,二者作用是完全相同的:

1
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 为例,演示一下使用方法:下面代码可以连接我们刚刚搭建的哨兵系统,并进行各种读写操作:

1
2
3
4
5
6
7
8
9
10
11
public static void testSentinel() throws Exception   {
String masterName = "mymaster";
Set<string style="box-sizing: border-box;"> sentinels = new HashSet<>();</string>
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 )会直接发向主节点;

  • 如果是代理,客户端的每一次请求都会发向哨兵,哨兵再通过主节点处理请求。

举一个例子可以很好的理解哨兵的作用是配置提供者,而不是代理。在前面部署的哨兵系统中,将哨兵节点的配置文件进行如下修改:

1
sentinel monitor   mymaster 192.168.92.128 6379 2

改为

1
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的高可用性;但是哨兵的缺陷同样很明显:哨兵无法对从节点进行自动故障转移,在读写分离场景下,从节点故障会导致读服务不可用,需要我们对从节点做额外的监控、切换操作。

此外,哨兵仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题;这些问题的解决需要使用集群

参考

文章目录
  1. 1. 一、作用和架构
    1. 1.1. 作用
    2. 1.2. 架构
  2. 2. 二、部署
    1. 2.1. 1.部署主从节点
    2. 2.2. 2.部署哨兵节点
    3. 2.3. 3.演示故障转移
    4. 2.4. 4.总结
  3. 3. 三、客户端访问哨兵系统
    1. 3.1. 1.代码示例
    2. 3.2. 2.客户端原理
    3. 3.3. 3.总结
  4. 4. 四、基本原理
    1. 4.1. 1.哨兵节点支持的命令
    2. 4.2. 2.基本原理
  5. 5. 五、配置与实践建议
    1. 5.1. 1.配置
    2. 5.2. 2.实践建议
  6. 6. 六、总结
  7. 7. 参考
|