redis主从复制[总结向]

---

title: Redis主从复制

date: 2020-03-29

---

欢迎前往个人博客和专栏一块儿交流： 博客 ｜ 知乎专栏

redis主从复制是高可用方案中的一部分，那主从复制是如何进行的？又是如何实现的？怎么支撑了redis的高可用性？在主从模式下Master和Slave节点分别作了哪些事情？

redis高可用方案是什么？

我理解的redis高可用的特色有：

1. 高QPS，主从 => 读写分离
2. 高容量，集群分片 => 高容量
3. 故障转移，sentinel => 故障转移
4. 故障恢复，数据持久 => 故障恢复 ～ 这里我简单的理解（RDB + AOF）= 故障恢复

主从复制

redis 主从复制有两个版本：旧版（Ver2.8-），新版（Ver2.8+，增长PSYNC命令来解决旧版中的问题）

讨论复制时都须要考虑两种场景：

• 场景1：从节点刚刚上线，须要去同步主节点时，这部分能够理解为 全量复制。
• 场景2：从节点掉线，恢复上线后须要同步数据，使本身和主节点达到一致状态。这部分在旧版复制里等价于全量复制，在新版里能够理解为增量复制。

固然你确定会想到若是主节点掉线，这时候会怎么样？这个场景固然也在redis高可用方案中，之时不是本文的重点，属于Sentinel机制的内容了。

旧版主从复制

前文说过了，旧版主从复制只有全量复制用于应付上述两个场景，所以下面的流程也只有一份：

1. 从服务器向主服务器发送sync命令。
2. 主服务器在收到sync命令以后，调用bgsave命令生成最新的rdb文件，将这个文件同步给从服务器，这样从服务器载入这个rdb文件以后，状态就会和主服务器执行bgsave命令时候的一致。
3. 主服务器将保存在命令缓冲区中的写命令同步给从服务器，从服务器执行这些命令，这样从服务器的状态就跟主服务器当前状态一致了。

若是你不知道redis中还有个缓冲区的话，建议系统的了解下redis中缓冲区的设计。这里缓冲区特指命令缓冲区，后面还会讲到复制缓冲区。

可是这样的实如今 **场景2** 下的缺点很明显：若是说从节点断线后迅速上线，这段时间内的产生的写命令不多，却要**全量复制**主库的数据，传输了大量重复数据。

SYNC命令产生的消耗：

1. 主节点生成RDB，须要消耗大量的CPU，内存和磁盘IO
2. 网络传输大量字节数据，须要消耗主从服务器的网络资源
3. 从节点须要从RDB文件恢复，会形成阻塞没法接受客户端请求

优势就是：简单暴力。我的看来在redis架构中不合适的用法，不表明说实际场景中也必定不合适，简单暴力也是一个很大的优势。

新版主从复制

新版的主从复制跟旧版的区别就在于：对场景2的优化。

场景2的缺点上文已经提到过了，那么优化的方向就是“尽可能不使用全量复制；增长增量复制(PSYNC)的功能”。为此还要解决下列问题：

1. 若是某个从节点断线了，从新上线该从节点如何知道本身是否应该全量仍是增量复制呢？
2. 该从节点断线恢复后，又怎么知道本身缺失了哪些数据呢？
3. 主节点又如何补偿该从节点在断线期间丢失的那部分数据呢？旧版的复制除了RDB，还有从命令缓冲区中的写命令来保持数据一致。

为此新版中使用了如下概念：

运行ID - runid

每一个redis服务器都有其runid，runid由服务器在启动时自动生成，主服务器会将本身的runid发送给从服务器，而从服务器会将主服务器的runid保存起来。从服务器redis断线重连以后进行同步时，就是根据runid来判断同步的进度：

1. 若是先后两次主服务器runid一致，则认为这一次断线重连仍是以前复制的主服务器，主服务器能够继续尝试部分同步操做。
2. 若是先后两次主服务器runid不相同，则全同步流程。

复制偏移量 - offset

主从节点，分别会维护一个复制偏移量：

主服务器每次向从服务器同步了N字节数据以后，将修改本身的复制偏移量+N。从服务器每次从主服务器同步了N字节数据以后，将修改本身的复制偏移量+N。经过对比主从节点的偏移量很容易就能够发现，主从节点是否处于一致状态。

复制（积压）缓冲区

一个固定长度（可配置）的FIFO队列，默认大小 = 1MB；预测值 = second * write_size_per_second。当从节点从新连上主节点时候，从节点会经过PSYNC命令将本身的复制偏移量（offset）发送给主服务器，主节点会根据偏移量会判断该执行何种同步：

1. 若是从节点offset以后的数据仍然存在复制缓冲区中，就执行部分重同步。
2. 反之，若是不存在，那么执行彻底重同步。

由于复制缓冲区不可能无限大，所以为了尽量多的利用部分重同步，须要针对真实场景估算出最合适的复制缓冲区大小。

至此，redis新版PSYNC经过上述概念和流程，解决了场景2下旧版复制中的资源浪费问题，流程图和示例图见下文。

示例图以下，ABCD四个从节点，其中A执行部分中同步，D执行了完整重同步。

总结

水平有限，若有错误，欢迎勘误指正🙏。

参考文献

• 《redis设计与实现》
• https://zhuanlan.zhihu.com/p/...