很久没更新的Redis系列又来啦~如果没看过这系列的同学，先复习一下先前的两篇(我要你知道的redis（一）和我要你知道的redis（二）)。本篇我们主要讲讲Redis的哨兵模式。

说说高可用

首先，我们来说一个叫高可用的概念。我们在工作中，可能都多多少少听到架构师们在说着自己的服务要实现几个9。那高可用就是指在服务器可以正常访问的时间，衡量的标准是在多长时间内可以提供正常服务，比如99%的时间，99.9%的时间等等，这就是他们口中说的几个9。

在Redis中，实现高可用的技术主要包括持久化、复制、哨兵和集群，下面简单说说它们的作用，以及解决了什么样的问题：

• 持久化：持久化是最简单的高可用方法。它的主要作用是数据备份，就是将数据存在硬盘上，防止数据因为redis异常而丢失。
• 复制：复制是高可用 Redis 的基础，哨兵和集群都是在复制基础上实现高可用的。复制跟我们通俗的理解一致，就是从一台机器拷贝到另一台机器。复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复。但是如果发生故障，无法自动恢复。
• 哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷是写操作无法负载均衡，存储能力受到单机的限制。
• 集群：通过集群，Redis 解决了写操作无法负载均衡以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

哨兵模式高可用架构

讲哨兵模式之前，我们先理解以下几个概念：

• 主节点：redis的主数据库，写入都在这个节点上
• 从节点：redis的从数据库，读取都在这个节点上
• Sentinel节点：哨兵节点，监控各个节点的状态

基于哨兵模式的高可用架构图如下：

在这个架构中，复制主要是将主节点的数据同步到从节点。这么做的主要原因有两个：一旦主节点宕机了，从节点可以作为主节点的备份随时顶上来成为新的主节点；从节点可以为主节点分担读的压力。

但是如果单单只有主从复制这一个保证高可用的话，就会存在以下问题：

• 一旦主节点宕机，从节点晋升成主节点，我们不仅需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
• 主节点的写能力、存储能力受到单机的限制，因为哨兵模式只有一个主节点。
• Redis 复制中断后，从节点会发起 psync。此时如果同步不成功，则会进行 全量同步，主库 执行全量备份的同时，可能会造成毫秒或秒级的卡顿。

为了解决以上问题，高可用架构中有了哨兵进程。

哨兵进程主要做以下几件事：

• 监控：哨兵会不断地检查你的主节点和从节点是否运作正常。
• 提醒：当被监控的某个节点出现问题时, 哨兵可以通过 API 向管理员或者其他应用程序发送通知。（使用较少）
• 自动故障迁移：当主节点不能正常工作时，哨兵会开始一次自动的故障转移操作，它会将其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点。
• 配置提供者：在哨兵模式下，客户端应用在初始化时连接的是哨兵节点集合，从中获取主节点的信息。

哨兵工作流程

那哨兵是怎么工作实现这些功能的呢？

每个哨兵进程以每秒钟一次的频率向整个集群中的主节点，从节点以及其他哨兵进程发送一个 PING 命令，并通过节点的回复来判断节点是否在线。

如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被哨兵进程标记为主观下线。这里的实例包括所有主节点和从节点。

如果一个主节点被标记为主观下线，则正在监视这个主节点的所有哨兵进程要以每秒一次的频率确认主节点的确进入了主观下线状态。

当有足够数量的哨兵进程（大于等于配置文件指定的值）在指定的时间范围内确认主节点进入了主观下线状态，则主节点会被标记为客观下线。客观下线只适用于主节点。

在一般情况下， 每个哨兵进程会以每 10 秒一次的频率向集群中的所有主节点、从节点发送 INFO 命令，INFO命令主要是获取节点信息。

当主节点被哨兵进程标记为客观下线时，哨兵进程向下线的主节点的所有从节点发送 INFO 命令的频率会从 10 秒一次改为每秒一次。

哨兵和其他哨兵协商主节点的状态，如果 主节点处于客观下线状态，则投票自动选出新的主节点，将剩余的从节指向新的主节点进行数据复制。

若没有足够数量的哨兵进程同意主节点下线，主节点的客观下线状态就会被移除。若主节点重新向哨兵进程发送 PING 命令返回有效答复，主节点的主观下线状态就会被移除。

那是不是判断完主节点已经下线，就立马开始故障转移了呢？其实不是。那么多哨兵经常必须选取出来一个领导哨兵，去做这件事情。

首先，每个在线的哨兵节点都有资格成为领导者。当其中一个哨兵节点A主观判断主节点下线时，就会向其他哨兵节点发送sentinel is-master-down-by-addr命令，并请求将自己设置为领导者。这里，就需要将runid设置为自己的runid。

收到命令的哨兵节点，如果没有同意过其他哨兵节点的sentinel is-master-down-by-addr命令，就会同意该请求，否则拒绝。因为，每个哨兵只有这么一张票，投了别人，就再没有投其他哨兵的机会了。

如果哨兵节点A发现自己的票数已经大于或等于半数，哨兵节点A就成为了领导者。

如果此过程没有选举出领导者，将进行下一次选举。一般，选举过程非常快，谁先完成客观下线判断，谁就是领导者。

本篇关于哨兵模式的介绍就先到这里了，下篇redis系列我们来讲讲集群模式，请持续关注哦~