网站建设 东莞,网页制作dw软件,苏州工业园区质安监站网址,大连意动网站建设有限公司怎么样一、作用和架构
1. 作用 在介绍哨兵之前#xff0c;首先从宏观角度回顾一下Redis实现高可用相关的技术。它们包括#xff1a;持久化、复制、哨兵和集群#xff0c;其主要作用和解决的问题是#xff1a; 1#xff09;持久化#xff1a;持久化是最简单的高可用方法(有时甚…一、作用和架构
1. 作用 在介绍哨兵之前首先从宏观角度回顾一下Redis实现高可用相关的技术。它们包括持久化、复制、哨兵和集群其主要作用和解决的问题是 1持久化持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)主要作用是数据备份即将数据存储在硬盘保证数据不会因进程退出而丢失。 2复制复制是高可用Redis的基础哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复。缺陷故障恢复无法自动化写操作无法负载均衡存储能力受到单机的限制。 3哨兵在复制的基础上哨兵实现了自动化的故障恢复。缺陷写操作无法负载均衡存储能力受到单机的限制。 4集群通过集群Redis解决了写操作无法负载均衡以及存储能力受到单机限制的问题实现了较为完善的高可用方案。 下面说回哨兵。 Redis Sentinel即Redis哨兵在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。下面是Redis官方文档对于哨兵功能的描述 1监控Monitoring哨兵会不断地检查主节点和从节点是否运作正常。 2自动故障转移Automatic failover当主节点不能正常工作时哨兵会开始自动故障转移操作它会将失效主节点的其中一个从节点升级为新的主节点并让其他从节点改为复制新的主节点。 3配置提供者Configuration provider客户端在初始化时通过连接哨兵来获得当前Redis服务的主节点地址。 4通知Notification哨兵可以将故障转移的结果发送给客户端。 其中监控和自动故障转移功能使得哨兵可以及时发现主节点故障并完成转移而配置提供者和通知功能则需要在与客户端的交互中才能体现。 这里对“客户端”一词在文章中的用法做一个说明在前面的文章中只要通过API访问redis服务器都会称作客户端包括redis-cli、Java客户端Jedis等为了便于区分说明本文中的客户端并不包括redis-cli而是比redis-cli更加复杂redis-cli使用的是redis提供的底层接口而客户端则对这些接口、功能进行了封装以便充分利用哨兵的配置提供者和通知功能。
2. 架构
典型的哨兵架构图如下所示
哨兵节点哨兵系统由一个或多个哨兵节点组成哨兵节点是特殊的redis节点不存储数据。数据节点主节点和从节点都是数据节点。
二、部署 这一部分将部署一个简单的哨兵系统包含1个主节点、2个从节点和3个哨兵节点。方便起见所有这些节点都部署在一台机器上局域网IP192.168.92.128使用端口号区分节点的配置尽可能简化。
1. 部署主从节点 哨兵系统中的主从节点与普通的主从节点配置是一样的并不需要做任何额外配置。下面分别是主节点port6379和2个从节点port6380/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/26381下面以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个作用中配置提供者和通知需要客户端的配合本文将在下一章介绍客户端访问哨兵系统的方法时详细介绍。这一小节将演示当主节点发生故障时哨兵的监控和自动故障转移功能。 1首先使用kill命令杀掉主节点 2如果此时立即在哨兵节点中使用info Sentinel命令查看会发现主节点还没有切换过来因为哨兵发现主节点故障并转移需要一段时间。 3一段时间以后再次在哨兵节点中执行info Sentinel查看发现主节点已经切换成6380节点。 但是同时可以发现哨兵节点认为新的主节点仍然有2个从节点这是因为哨兵在将6380切换成主节点的同时将6379节点置为其从节点虽然6379从节点已经挂掉但是由于哨兵并不会对从节点进行客观下线其含义将在原理部分介绍因此认为该从节点一直存在。当6379节点重新启动后会自动变成6380节点的从节点。下面验证一下。 4重启6379节点可以看到6379节点成为了6380节点的从节点。 5在故障转移阶段哨兵和主从节点的配置文件都会被改写。 对于主从节点主要是slaveof配置的变化新的主节点没有了slaveof配置其从节点则slaveof新的主节点。 对于哨兵节点除了主从节点信息的变化纪元(epoch)也会变化下图中可以看到纪元相关的参数都1了。
4. 总结 哨兵系统的搭建过程有几点需要注意 1哨兵系统中的主从节点与普通的主从节点并没有什么区别故障发现和转移是由哨兵来控制和完成的。 2哨兵节点本质上是redis节点。 3每个哨兵节点只需要配置监控主节点便可以自动发现其他的哨兵节点和从节点。 4在哨兵节点启动和故障转移阶段各个节点的配置文件会被重写(config rewrite)。 5本章的例子中一个哨兵只监控了一个主节点实际上一个哨兵可以监控多个主节点通过配置多条sentinel monitor即可实现。
三、客户端访问哨兵系统 上一小节演示了哨兵的两大作用监控和自动故障转移本小节则结合客户端演示哨兵的另外两个作用配置提供者和通知。
1. 代码示例 在介绍客户端的原理之前先以Java客户端Jedis为例演示一下使用方法下面代码可以连接我们刚刚搭建的哨兵系统并进行各种读写操作代码中只演示如何连接哨兵异常处理、资源关闭等未考虑。
blic static void testSentinel() throws Exception {String masterName mymaster;SetString 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构造JedisSentinelPool对象然后便可以像使用普通redis连接池一样来使用了通过pool.getResource()获取连接执行具体的命令。 在整个过程中我们的代码不需要显式的指定主节点的地址就可以连接到主节点代码中对故障转移没有任何体现就可以在哨兵完成故障转移后自动的切换主节点。之所以可以做到这一点是因为在JedisSentinelPool的构造器中进行了相关的工作主要包括以下两点 1遍历哨兵节点获取主节点信息遍历哨兵节点通过其中一个哨兵节点masterName获得主节点的信息该功能是通过调用哨兵节点的sentinel get-master-addr-by-name命令实现该命令示例如下 一旦获得主节点信息停止遍历因此一般来说遍历到第一个哨兵节点循环就停止了。 2增加对哨兵的监听这样当发生故障转移时客户端便可以收到哨兵的通知从而完成主节点的切换。具体做法是利用redis提供的发布订阅功能为每一个哨兵节点开启一个单独的线程订阅哨兵节点的switch-master频道当收到消息时重新初始化连接池。
3. 总结 通过客户端原理的介绍可以加深对哨兵功能的理解 1配置提供者客户端可以通过哨兵节点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连接自然无法连接。如果哨兵是代理这个问题就不会出现了。 2通知哨兵节点在故障转移完成后会将新的主节点信息发送给客户端以便客户端及时切换主节点。
四、基本原理 前面介绍了哨兵部署、使用的基本方法本部分介绍哨兵实现的基本原理。
1. 哨兵节点支持的命令 哨兵节点作为运行在特殊模式下的redis节点其支持的命令与普通的redis节点不同。在运维中我们可以通过这些命令查询或修改哨兵系统不过更重要的是哨兵系统要实现故障发现、故障转移等各种功能离不开哨兵节点之间的通信而通信的很大一部分是通过哨兵节点支持的命令来实现的。下面介绍哨兵节点支持的主要命令。 1基础查询通过这些命令可以查询哨兵系统的拓扑结构、节点信息、配置信息等。 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哨兵节点之间可以通过该命令询问主节点是否下线从而对是否客观下线做出判断 2增加/移除对主节点的监控 sentinel monitor mymaster2 192.168.92.128 16379 2与部署哨兵节点时配置文件中的sentinel monitor功能完全一样不再详述sentinel remove mymaster2取消当前哨兵节点对主节点mymaster2的监控 3强制故障转移 sentinel failover mymaster该命令可以强制对mymaster执行故障转移即便当前的主节点运行完好例如如果当前主节点所在机器即将报废便可以提前通过failover命令进行故障转移。
2. 基本原理
1定时任务每个哨兵节点维护了3个定时任务。定时任务的功能分别如下通过向主从节点发送info命令获取最新的主从结构通过发布订阅功能获取其他哨兵节点的信息通过向其他节点发送ping命令进行心跳检测判断是否下线。2主观下线在心跳检测的定时任务中如果其他节点超过一定时间没有回复哨兵节点就会将其进行主观下线。顾名思义主观下线的意思是一个哨兵节点“主观地”判断下线与主观下线相对应的是客观下线。3客观下线哨兵节点在对主节点进行主观下线后会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态如果判断主节点下线的哨兵数量达到一定数值则对该主节点进行客观下线。 需要特别注意的是客观下线是主节点才有的概念如果从节点和哨兵节点发生故障被哨兵主观下线后不会再有后续的客观下线和故障转移操作。4选举领导者哨兵节点当主节点被判断客观下线以后各个哨兵节点会进行协商选举出一个领导者哨兵节点并由该领导者节点对其进行故障转移操作。 监视该主节点的所有哨兵都有可能被选为领导者选举使用的算法是Raft算法Raft算法的基本思路是先到先得即在一轮选举中哨兵A向B发送成为领导者的申请如果B没有同意过其他哨兵则会同意A成为领导者。选举的具体过程这里不做详细描述一般来说哨兵选择的过程很快谁先完成客观下线一般就能成为领导者。5故障转移选举出的领导者哨兵开始进行故障转移操作该操作大体可以分为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可以根据不同的网络环境和应用要求来调整值越大对主观下线的判定会越宽松好处是误判的可能性小坏处是故障发现和故障转移的时间变长客户端等待的时间也会变长。例如如果应用对可用性要求较高则可以将值适当调小当故障发生时尽快完成转移如果网络环境相对较差可以适当提高该阈值避免频繁误判。 3sentinel parallel-syncs {masterName} {number} sentinel parallel-syncs与故障转移之后从节点的复制有关它规定了每次向新的主节点发起复制操作的从节点个数。例如假设主节点切换完成之后有3个从节点要向新的主节点发起复制如果parallel-syncs1则从节点会一个一个开始复制如果parallel-syncs3则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. 实践建议
1哨兵节点的数量应不止一个一方面增加哨兵节点的冗余避免哨兵本身成为高可用的瓶颈另一方面减少对下线的误判。此外这些不同的哨兵节点应部署在不同的物理机上。 2哨兵节点的数量应该是奇数便于哨兵通过投票做出“决策”领导者选举的决策、客观下线的决策等。 3各个哨兵节点的配置应一致包括硬件、参数等此外所有节点都应该使用ntp或类似服务保证时间准确、一致。 4哨兵的配置提供者和通知客户端功能需要客户端的支持才能实现如前文所说的Jedis如果开发者使用的库未提供相应支持则可能需要开发者自己实现。 5当哨兵系统中的节点在docker或其他可能进行端口映射的软件中部署时应特别注意端口映射可能会导致哨兵系统无法正常工作因为哨兵的工作基于与其他节点的通信而docker的端口映射可能导致哨兵无法连接到其他节点。例如哨兵之间互相发现依赖于它们对外宣称的IP和port如果某个哨兵A部署在做了端口映射的docker中那么其他哨兵使用A宣称的port无法连接到A。
六、总结 本文首先介绍了哨兵的作用监控、故障转移、配置提供者和通知然后讲述了哨兵系统的部署方法以及通过客户端访问哨兵系统的方法再然后简要说明了哨兵实现的基本原理最后给出了关于哨兵实践的一些建议。 在主从复制的基础上哨兵引入了主节点的自动故障转移进一步提高了Redis的高可用性但是哨兵的缺陷同样很明显哨兵无法对从节点进行自动故障转移在读写分离场景下从节点故障会导致读服务不可用需要我们对从节点做额外的监控、切换操作。 此外哨兵仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题这些问题的解决需要使用集群我将在后面的文章中介绍欢迎关注。
参考文献
深入学习Redis4哨兵 - cnblog
