咱们一块儿牵手学哨兵撒？

有眼光啊，这么多文章你点开了我，缘分，若是我没猜错的话，你是个有梦想的人，是个热爱技术的人，咱们一块儿手牵手撒？

       

 

咱们前面文章说的RDB和AOF是为了解决单机redis的数据存储问题，主从复制能够实现数据冗余，侧重于解决数据的多机热备份。可是主从复制中存在着一个问题就是故障恢复没法自动化，而redis中的哨兵机制，基于Redis主从复制，主要做用即是解决主节点故障恢复的自动化问题，进一步提升系统的高可用性

Redis哨兵Sentinel，核心功能是主节点的自动故障转移，管理多个Redis服务器，哨兵节点不存储数据

 

持久化：持久化最容易理解，主要就是将数据备份，将数据备份到硬盘上，不会由于机器宕机停电等形成数据丢失

 

主从复制：复制主要实现了多个机器的备份，以及对于读操做的负载均衡和简单的故障恢复（哨兵和集群都是在复制的基础上实现高可用的）存在缺陷：存储能力受到单机限制，写操做没法负载均衡，故障没法自动恢复

 

哨兵模式：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操做没法负载均衡；存储能力受到单机的限制。

 

集群：经过集群，Redis解决了写操做没法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

了解哨兵Sentinel

 

提到哨兵，你们想到的是什么呢？（科幻迷的我瞬间想到x战警中无所不能，而后把变种人干趴下的哨兵），在那里边是谁变异了，就干掉谁

 

那么Redis中哨兵是干啥的呢？咱们上节说到主从架构是一主多从，主可写可读，从只能读，那要是这个主节点宕机了，谁来对外提供写服务呢？

       

你不就是主节点挂了吗，我在众多从节点中选出一个作为新的主节点不就OK啦，对了，哨兵就是起这个做用的，那若是原来的主节点忽然好了，这时的主节点是原主节点仍是经过哨兵后选出的主节点呢？答案是经过哨兵选出的节点是主节点，也就意味着主节点宕机以后再次链接便失去了它的主节点的身份了

咱们来看下Redis官方对哨兵功能的介绍：

• 集群监控：监控Redis master主和slave从进程是否正常运行

• 消息通知：从若是Redis实例有故障，哨兵能够发送报警信息和故障转移结果发送到管理员

• 自动故障转移：主节点不能正常工做时，能够将失效主节点其中一个从节点升级为新的主节点

• 配置中心：客户端初始化时经过哨兵来得到Redis服务的主节点地址

其中，集群监控和自动故障转移功能，使得哨兵能够及时发现主节点故障并完成转移，消息通知和配置中心是和客户端的交互中体现

咱们知道了它是干啥的，下一步就是须要了解它是如何作到的，知其然，而后知其因此然~

典型的哨兵架构以下图：

 

由两部分组成，哨兵节点和数据节点：

• 哨兵节点：监哨兵系统由一个或者多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据

• 数据节点：主节点master和从节点slave都是数据节点

关于哨兵的工做原理，主要是理解定时任务、主观下线和客观下线的几个概念

 

1）定时任务：每一个哨兵节点维护了3个定时任务，分别是向主从发送info命

令获取最新的主从结构、经过发布订阅获取其它哨兵节点信息、经过向其它节点发送ping命令进行心跳检测

 

2）主观下线：在心跳检测中，若是其它节点超过必定时间未回复，哨兵节点会将其进行主观下线，即一个哨兵节点主观的判断下线

 

3）客观下线：哨兵节点对主节点进行主观下线以后，会经过sentinel is-master-down-by-addr命令向其它哨兵节点询问该主节点的状态，若是判断该主节点主观下线的哨兵数量达到必定的数值，则对该主节点进行客观下线

 

客观下线是主节点才有的概念！若是从节点和哨兵节点发生故障，被哨兵主观下线以后，不会有后续的客观下线和故障转移操做

 

故障转移流程

 

一、选举哨兵领导者：当主节点被判断主观下线以后，各个哨兵节点会进行协商，选举出一个哨兵领导者，由该领导者进行故障转移操做，监视该主节点的全部哨兵均可能成为领导者，选举使用的算法是Raft算法，基本思想就是先到先得；在一轮选举中，哨兵A向B发送成为领导者的申请，若是B没有赞成过其它哨兵，则会赞成A成为领导者

 

通常来讲，哨兵领导者选择的很快，谁先完成客观下线，通常谁就能成为哨兵领导者

 

二、选择新的主节点：领导者哨兵开始故障转移操做，在从节点中选择出新的主节点；原则是，先过滤掉不健康的从节点，选择优先级最高的从节点（经过slave-priority设置），若优先级没法区分，则选择复制偏移量最大的从节点，若扔没法区分，则选择runid最小的从节点

 

runid是服务器启动时自动生成，必定能找出最小的节点

 

三、更新主从状态：经过slaveof no one命令，让选出来的从节点成为主节点；并经过slaveof命令让其余节点成为其从节点

 

四、设置原主节点：将已经下线的主节点(即6379)设置为新的主节点的从节点，当6379从新上线后，它会成为新的主节点的从节点

 

Redis哨兵切换主备时的数据丢失问题

 

数据丢失主要分为如下两种状况：

• 异步复制致使数据丢失

• 脑裂致使数据丢失

 

异步复制丢失是由于master到slave的复制是异步的，若是数据还未复制完成，master宕机了便会形成数据丢失；脑裂，master所在机器忽然脱离了正常网络，跟别的节点没法链接，可是实际上这个master没有挂掉，还活着，哨兵会认为这个主节点挂掉了，从新选出一个新的主节点，此时便存在两个master节点了

 

此时虽然某个slave被切换成了master，可是可能客户端还未进行切换，仍是链接原来的master，继续向原来master节点发送数据，形成数据丢失

 

解决数据丢失

 

咱们通常经过两个参数来解决：

• min-slaves-to-write 1 

• min-slaves-max-lag 10

 

要求至少有1个slave，数据复制和同步的延迟不能超过10秒，若是说一旦全部slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了。

 1）减小异步复制的数据丢失

有了min-slaves-max-lag这个配置，就能够确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样能够把master宕机时因为部分数据未同步到slave致使的数据丢失下降的可控范围内

 2）减小脑裂的数据丢失

若是一个master出现了脑裂，跟其余slave丢了链接，那么上面两个配置能够确保说，若是不能继续给指定数量的slave发送数据，并且slave超过10秒没有给本身ack消息，那么就直接拒绝客户端的写请求，这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失，上面的配置就确保了，若是跟任何一个slave丢了链接，在10秒后发现没有slave给本身ack，那么就拒绝新的写请求，所以在脑裂场景下，最多就丢失10秒的数据

 

一些其余

• 哨兵至少须要三个实例，来保证本身的健壮性

• 哨兵+主从结构不会保证数据零丢失，只能保证高可用性

• 哨兵节点本质是Redis节点，每一个哨兵节点只须要配置监控主节点，即可以自动发现其余哨兵节点和从节点

• 在哨兵节点启动和故障转移过程当中，哨兵的配置文件会被重写

实战

                      

 

接下来演示一个简单的哨兵系统的部署来帮助你们理解，包含一个主节点，两个从节点和三个哨兵节点，均部署在本机localhost上，经过端口号区别

 

部署主从节点

 

哨兵系统的主从节点和普通的主从节点没啥区别，不须要额外的配置，咱们设置主节点端口号是6379，从节点端口号是6380和6381

 

•  

#redis-6379.confport 6379daemonize yeslogfile "6379.log"dbfilename "dump-6379.rdb"
#redis-6380.confport 6380daemonize nologfile "6380.log"dbfilename "dump-6380.rdb"slaveof localhost 6379
#redis-6381.confport 6381daemonize nologfile "6381.log"dbfilename "dump-6381.rdb"slaveof localhost 6379

 

配置完上面的三个配置文件以后，咱们经过命令启动主从节点

 

•  

redis-server redis-6379.confredis-server redis-6380.confredis-server redis-6381.conf

 

节点启动后，咱们链接主节点，经过info Replication命令查看，能够看到connected_slaves:2，该主节点有两个从节点

 

 

部署哨兵节点

 

哨兵节点本质上就是不含数据的Redis节点，3个哨兵节点的配置几乎是同样的，咱们只须要修改端口号相关便可（1637九、16380、16381）

 

•  

#redis-16379.confport 16379daemonize yeslogfile "16379.log"sentinel monitor mymaster localhost 6379 2

 

其中sentinel monitor mymaster localhost 6379 2配置的含义是，该哨兵节点监控localhost这个主节点，该主节点名字是mymaster，参数2则是和主节点的故障断定有关，至少须要2个哨兵节点赞成，才能断定主节点故障并进行故障转移

 

哨兵节点的启动方式：

 

•  

redis-sentinel redis-16379.confredis-server redis-16379.conf --sentinel

 

咱们链接上端口号16379的客户端，经过info sentinel命令查看从节点和相应的哨兵节点信息（链接命令redis-server.exe -p 16379