调研Redis高可用两种方案

 

做者 | codedump codedump.info 博主，多年从事互联网服务器后台开发工做。可访问做者博客阅读 codedump 更多文章。

导读：Redis是被普遍使用的基础软件之一。对于工程师和架构师、运维人员来讲，了解Redis的高可用方案和背后的原理，是必备的基础知识。本文做者深刻分析了Redis高可用的方方面面，而且作了有效总结，相信对广大读者能够起到很好的领路做用。

Redis中为了实现高可用（High Availability，简称HA），采用了以下两个方式：

主从复制数据。

采用哨兵监控数据节点的运行状况，一旦主节点出现问题由从节点顶上继续进行服务。

主从复制

Redis中主从节点复制数据有全量复制和部分复制之分。

旧版本全量复制功能的实现

全量复制使用snyc命令来实现，其流程是：

从服务器向主服务器发送sync命令。

主服务器在收到sync命令以后，调用bgsave命令生成最新的rdb文件，将这个文件同步给从服务器，这样从服务器载入这个rdb文件以后，状态就会和主服务器执行bgsave命令时候的一致。

主服务器将保存在命令缓冲区中的写命令同步给从服务器，从服务器执行这些命令，这样从服务器的状态就跟主服务器当前状态一致了。

 

旧版本全量复制功能，其最大的问题是从服务器断线重连时，即使在从服务器上已经有一部分数据了，也须要进行全量复制，这样作的效率很低，因而新版本的Redis在这部分作了改进。

新版本全量复制功能的实现

新版本Redis使用psync命令来代替sync命令，该命令既能够实现完整全同步也能够实现部分同步。

复制偏移量

执行复制的双方，主从服务器，分别会维护一个复制偏移量：

主服务器每次向从服务器同步了N字节数据以后，将修改本身的复制偏移量+N。

从服务器每次从主服务器同步了N字节数据以后，将修改本身的复制偏移量+N。

复制积压缓冲区

主服务器内部维护了一个固定长度的先进先出队列作为复制积压缓冲区，其默认大小为1MB。

在主服务器进行命令传播时，不只会将写命令同步到从服务器，还会将写命令写入复制积压缓冲区。

 

服务器运行ID

每一个Redis服务器，都有其运行ID，运行ID由服务器在启动时自动生成，主服务器会将本身的运行ID发送给从服务器，而从服务器会将主服务器的运行ID保存起来。

从服务器Redis断线重连以后进行同步时，就是根据运行ID来判断同步的进度：

若是从服务器上面保存的主服务器运行ID与当前主服务器运行ID一致，则认为这一次断线重连链接的是以前复制的主服务器，主服务器能够继续尝试部分同步操做。

不然，若是先后两次主服务器运行ID不相同，则认为是完成全同步流程。

psync命令流程

有了前面的准备，下面开始分析psync命令的流程：

若是从服务器以前没有复制过任何主服务器，或者以前执行过slaveof no one命令，那么从服务器就会向主服务器发送psync ? -1命令，请求主服务器进行数据的全量同步。

不然，若是前面从服务器已经同步过部分数据，那么从服务器向主服务器发送psync <runid> <offset>命令，其中runid是上一次主服务器的运行id，offset是当前从服务器的复制偏移量。

前面两种状况主服务器收到psync命令以后，会出现如下三种可能：

主服务器返回+fullresync <runid> <offset>回复，表示主服务器要求与从服务器进行完整的数据全量同步操做。其中，runid是当前主服务器运行id，而offset是当前主服务器的复制偏移量。

若是主服务器应答+continue，那么表示主服务器与从服务器进行部分数据同步操做，将从服务器缺失的数据同步过来便可。

若是主服务器应答-err，那么表示主服务器版本低于2.8，识别不了psync命令，此时从服务器将向主服务器发送sync命令，执行完整的全量数据同步。

 

哨兵机制概述

Redis使用哨兵机制来实现高可用(HA)，其大概工做原理是：

Redis使用一组哨兵（sentinel）节点来监控主从redis服务的可用性。

一旦发现Redis主节点失效，将选举出一个哨兵节点做为领导者（leader）。

哨兵领导者再从剩余的从Redis节点中选出一个Redis节点做为新的主Redis节点对外服务。

以上将Redis节点分为两类：

哨兵节点（sentinel）：负责监控节点的运行状况。

数据节点：即正常服务客户端请求的Redis节点，有主从之分。

以上是大致的流程，这个流程须要解决如下几个问题：

如何对Redis数据节点进行监控？

如何肯定一个Redis数据节点失效？

如何选择出一个哨兵领导者节点？

哨兵节点选择新的主Redis节点的依据是什么？

如下来逐个回答这些问题。

三个监控任务

哨兵节点经过三个定时监控任务监控Redis数据节点的服务可用性。

info命令

每隔10秒，每一个哨兵节点都会向主、从Redis数据节点发送info命令，获取新的拓扑结构信息。

Redis拓扑结构信息包括了：

本节点角色：主或从。

主从节点的地址、端口信息。

这样，哨兵节点就能从info命令中自动获取到从节点信息，所以那些后续才加入的从节点信息不须要显式配置就能自动感知。

 

向__sentinel__:hello频道同步信息

每隔2秒，每一个哨兵节点将会向Redis数据节点的__sentinel__:hello频道同步自身获得的主节点信息以及当前哨兵节点的信息，因为其余哨兵节点也订阅了这个频道，所以实际上这个操做能够交换哨兵节点之间关于主节点以及哨兵节点的信息。

这一操做实际上完成了两件事情： 

* 发现新的哨兵节点：若是有新的哨兵节点加入，此时保存下来这个新哨兵节点的信息，后续与该哨兵节点创建链接。 

* 交换主节点的状态信息，做为后续客观判断主节点下线的依据。

 

向数据节点作心跳探测

每隔1秒，每一个哨兵节点向主、从数据节点以及其余sentinel节点发送ping命令作心跳探测，这个心跳探测是后续主观判断数据节点下线的依据。

 

主观下线和客观下线

主观下线

上面三个监控任务中的第三个探测心跳任务，若是在配置的down-after-milliseconds以后没有收到有效回复，那么就认为该数据节点“主观下线（sdown）”。

 

为何称为“主观下线”？由于在一个分布式系统中，有多个机器在一块儿联动工做，网络可能出现各类情况，仅凭一个节点的判断还不足以认为一个数据节点下线了，这就须要后面的“客观下线”。

客观下线

当一个哨兵节点认为主节点主观下线时，该哨兵节点须要经过”sentinel is-master-down-by addr”命令向其余哨兵节点咨询该主节点是否下线了，若是有超过半数的哨兵节点都回答了下线，此时认为主节点“客观下线”。

 

选举哨兵领导者

当主节点客观下线时，须要选举出一个哨兵节点作为哨兵领导者，以完成后续选出新的主节点的工做。

这个选举的大致思路是：

每一个哨兵节点经过向其余哨兵节点发送”sentinel is-master-down-by addr”命令来申请成为哨兵领导者。

而每一个哨兵节点在收到一个”sentinel is-master-down-by addr”命令时，只容许给第一个节点投票，其余节点的该命令都会被拒绝。

若是一个哨兵节点收到了半数以上的赞成票，则成为哨兵领导者。

若是前面三步在必定时间内都没有选出一个哨兵领导者，将从新开始下一次选举。

能够看到，这个选举领导者的流程很像raft中选举leader的流程。

 

选出新的主节点

在剩下的Redis从节点中，按照如下顺序来选择新的主节点：

过滤掉“不健康”的数据节点：好比主观下线、断线的从节点、五秒内没有回复过哨兵节点ping命令的节点、与主节点失联的从节点。

选择slave-priority（从节点优先级）最高的从节点，若是存在则返回不存在则继续后面的流程。

选择复制偏移量最大的从节点，这意味着这个从节点上面的数据最完整，若是存在则返回不存在则继续后面的流程。

到了这里，全部剩余从节点的状态都是同样的，选择runid最小的从节点。

 

提高新的主节点

选择了新的主节点以后，还须要最后的流程让该节点成为新的主节点：

哨兵领导者向上一步选出的从节点发出“slaveof no one”命令，让该节点成为主节点。

哨兵领导者向剩余的从节点发送命令，让它们成为新主节点的从节点。

哨兵节点集合会将原来的主节点更新为从节点，当其恢复以后命令它去复制新的主节点的数据。

 

若是过程当中哨兵领导者失效怎么办？不妨来6月21-23日即将于深圳举办的GIAC全球互联网架构大会听听掌阅资深架构师，畅销图书《Redis 深度历险：核心原理与应用实践》做者钱文品怎么说，他将做为数据库专场的讲师出席2019年GIAC深圳站，并作关于Redis高性能，高可用方面的的演讲。此外，阿里云前数据库总负责人余峰将做为本专场的出品人，具体议题以下：