第07课：Redis Sentinel 部署和运维

上一篇文章，我们讲了Redis复制的主要内容，但Redis复制有一个缺点，当主机Master宕机以后，我们需要人工解决。那么能不能自动的解决主机宕机的问题呢？RedisSentinel正是为了解决这样的问题而被开发的。RedisSentinel是一个分布式的架构，每一个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当发现某个节点无法到达的时候，会自动标识该节点。如果这个节点是主节点，那么它会和其他Sentinel节点“协商”，大部分节点都认为主节点无法到达的时候，它们会选举一个Sentinel节点来完成自动故障转移，同时会告知Redis的应用方。由于这个过程是自动化的，不需要人工参与，大大提高了Redis的高可用性。接下来，我们将从实现流程、安装配置、客户端连接、实现原理、常见开发运维问题这五个方面来探讨。实现流程如下图所示，Sentinel集群会监控每一个Slave和Master。客户端不再直接从Redis获取信息，而是通过Sentinel集群来获取信息。再看下面这张图，当Master宕机了，Sentinel监控到Master有问题，就会和其他Sentinel进行选举，选举出一个Sentinel作为领导，然后选出一个Slave作为Master，并通知其它Slave。上图Slave1变成了Master，如果原来的Master又连上了，也会变成Slave从机。enterimagedescriptionhere安装与配置我们将从以下两个方面去讲解如何安装和配置主从节点和Sentinel节点。如何配置开启主从节点；如何配置开启Sentinel监控主节点。开启主从节点Sentinel对主节点和从节点的配置是不同的，需要分别配置，我们分开来讲解。主节点配置我们在命令行使用下面的命令进行主节点的启动。redis-serverredis-7000.conf启动完成以后，我们参考下面的配置进行参数的设置。port7000daemonizeyes//守护进程pidfile/var/run/redis-7000.pid//给出pidlogfile“7000.log”//日志查询dir/opt/redis/data//工作目录从节点配置我们在命令行使用下面的命令进行从节点的启动。redis-serverredis-7001.confredis-serverredis-7002.conf启动完成以后，和主节点配置一样，配置下面的参数。这个时候要注意，我们需要分别对Slave节点的每台机器进行配置。Slave1的配置如下。port7001daemonizeyes//守护进程pidfile/var/run/redis-7001.pid//给出pidlogfile“7001.log”//日志查询dir/opt/redis/data//工作目录slaveof127.0.0.17000Slave2的配置如下。port7002daemonizeyes//守护进程pidfile/var/run/redis-7002.pid//给出pidlogfile“7002.log”//日志查询dir/opt/redis/data//工作目录slaveof127.0.0.17000Sentinel监控主要配置开启了主从节点以后，我们需要对Sentinel进行监控上的配置，见下面的配置参数。port端口号dir/opt/redis/data/logfile端口号.logsentinelmonitormymaster127.0.0.170002sentineldown-after-millsecondsmymaster30000sentinelparallel-syncsmymaster1sentinelfailover-timeoutmymaster180000由于需要配置多台Sentinel，从上面配置信息可以看到，除了修改端口号，其他配置都是相同的。重点看最后四个配置，这四个配置是Sentinel的核心配置。我们分别来解释一下这四个配置，斜杠后面是解释该参数的意义。sentinelmonitormymaster127.0.0.170002//监控的主节点的名字、IP和端口，最后一个2的意思是有几台Sentinel发现有问题，就会发生故障转移；sentineldown-after-millsecondsmymaster30000//这个是超时的时间。打个比方，当你去ping一个机器的时候，多长时间后仍ping不通，那么就认为它是有问题；sentinelparallel-syncsmymaster1//指出Sentinel属于并发还是串行。1代表每次只能复制一个，可以减轻Master的压力；sentinelfailover-timeoutmymaster180000//表示故障转移的时间。Sentinel客户端原理我们配置高可用的时候，如果只是配置服务端的高可用是不够的。如果客户端感知不到服务端的高可用，是不会起作用的。所以，我们不但要让服务端高可用，还要让客户端也是高可用的。我们先来看下客户端基本原理。第一步，客户端Client需要遍历Sentinel节点集合，找到一个可用的Sentinel节点，同时需要获取Master主机的masterName。如下图所示。enterimagedescriptionhere第二步，当客户端找到Sentinel-2节点的时候，Client会通过get-master-addr-by-name命令获取masterName，这个时候，Sentinel-2会获取真正的名称和地址。如下图所示。enterimagedescriptionhere第三步，Client获取到Master节点的时候，还会发出role或rolereplication命令，进行一次验证是否是Master节点，Sentinel-2会返回这个节点信息加以验证。如下图所示。enterimagedescriptionhere第四步，如果Sentinel感知到Master宕机了，这时Sentinel集群应该是最先知道的。客户端和Sentinel集群之间其实是发布订阅，客户端Client去订阅某个Sentinel的频道，如果哪个Sentinel发现Master发生了变化，Client是会被通知到这个信息的，如下图所示。但是要注意这个不是代理模式。enterimagedescriptionhere总结一下，以上四步就是客户端和Sentinel集群的基本原理，任何客户端原理都是按照这个流程做的，只是内部的封装不同而已。Jedis我们先通过使用率最高的Java的客户端Jedis讲起。如何通过代码实现Sentinel的访问，让我们来看看代码如何连接Sentinel的资源池。JedisSentinelPoolsentinelPool=newJedisSentinelPool(masterName,sentinelSet,poolConfig,timeout);//内部的本质还是去连接master主机；参数masterName表示master名称，sentinelSet表示sentinel集合，poolConfig配置，和超时时间；Jedisjedis=null;try{//获得redisSentinelPool资源jedis=redisSentinelPool.getResource();//jedis相关的命令}catch(Exceptione){logger.error(e.getMessage(),e);}finally{if(jedis!=null){jedis.close();//jedis归还}}redis-py接下来我们再来看下如何使用Python连Redis客户端的Sentinel，和Jedis一样，我们将直接给出连接Sentinel的代码。fromredis.sentinelimportSentinelsentinel=Sentinel([('localhost',26379),('localhost',26380),('localhost',26381)],socket_time=0.1)//获取可用的Sentinel，并设置超时时间。sentinel.discover_master('mymaster')//获取Master地址('127.0.0.1',7000)sentinel.discover_slaves('mymaster')//获取Slave地址[('127.0.0.1',7001),('127.0.0.1',7002)]Sentinel实现原理讲完了Sentinel的代码实现，很多人对Sentinel还不懂其原理。那么接下来我们就来看下Sentinel的实现原理，主要分为以下三个步骤。1.检测问题，主要讲的是三个定时任务，这三个内部的执行任务可以保证出现问题马上让Sentinel知道。2.发现问题，主要讲的是主观下线和客观下线。当有一台Sentinel机器发现问题时，它就会主观对它主观下线，但是当多个Sentinel都发现有问题的时候，才会出现客观下线。3.找到解决问题的人，主要讲的是领导者选举，如何在Sentinel内部多台节点做领导者选举，选出一个领导者。4.解决问题，主要讲的是故障转移，即如何进行故障转移。我们将分开来进行阐述。三个定时任务首先要讲的是内部Sentinel会执行以下三个定时任务。每10秒每个Sentinel对Master和Slave执行一次InfoReplication。每2秒每个Sentinel通过Master节点的channel交换信息（pub/sub）。每1秒每个Sentinel对其他Sentinel和Redis执行ping。在这里一一解释下。第一个定时任务，指的是RedisSentinel可以对Redis节点做失败判断和故障转移，在Redis内部有三个定时任务作为基础，来InfoReplication发现Slave节点，这个命令可以确定主从关系。第两个定时任务，类似于发布订阅，Sentinel会对主从关系进行判定，通过_sentinel_:hello频道交互。了解主从关系可以帮助更好的自动化操作Redis。然后Sentinel会告知系统消息给其它Sentinel节点，最终达到共识，同时Sentinel节点能够互相感知到对方。第两个定时任务，指的是对每个节点和其它Sentinel进行心跳检测，它是失败判定的依据。主观下线和客观下线我们先来回顾一下Sentinel的配置。sentinelmonitormymaster127.0.0.163793//如不懂意思，请参见上面讲解Sentinel如何配置的解释；3这个配置请记住，我将在后面讲解。sentineldown-after-millisecondsmymaster3000//Sentinel会ping每个节点，如果超过30秒，依然没有回复的话，做下线的判断。那么什么是主观下线呢？每个Sentinel节点对Redis节点失败的“偏见”。之所以是偏见，只是因为某一台机器30秒内没有得到回复。那么如何做到客观下线呢？这个时候需要所有Sentinel节点都发现它30秒内无回复，才会达到共识。领导者选举Sentinel集群会采用领导者选举的方式，完成Sentinel节点的故障转移。通过sentinelis-master-down-by-addr命令都希望成为领导者。领导者选举的三个步骤，请见下。步骤1，每个做主观下线的Sentinel节点向其它节点发送命令，要求将它设置为领导者。步骤2，收到命令的Sentinel节点，如果没有同意通过其它Sentinel节点发送的命令，那么将同意该要求，否则就会拒绝。步骤3，如果Sentinel节点发现自己的票数已经超过Sentinel半数同时也超过Sentinelmonitormymaster127.0.0.163793中的3个的时候，那么它将成为领导者。步骤4，如果有多个Sentinel节点成为领导者，那么