Redis高可用全景一览 _Redis

正文对于一项技术的学习，我们要对这项技术有一个全局观，下面是一张 redis 全景图，我觉得画得非常全面。

文章插图
图源：极客时间《Redis核心技术与实战》-蒋德均
今天我们主要关注 Redis 的高可用主线。Redis 的高可用性，具体来说，有两方面含义：一是服务少中断，二是数据少丢失。
为了保证服务少中断，通常的做法就是冗余，增加服务的副本，但是当副本多了以后，如何保证副本的数据一致就成了问题。
一、主从库模式在这方面， Redis 提供了主从库模式，主从库之间采用的是读写分离的方式：对于读操作请求，主从库都可以接收；对于写操作，首先到主库执行，然后，主库将写操作同步给从库。

文章插图
Redis读写分离
那么，主从库同步是如何完成的呢？主库数据是一次性传给从库，还是分批同步？要是主从库间的网络断连了，数据还能保持一致吗？
1.1 数据同步的实现细节当我们启动多个 Redis 实例的时候，它们相互之间就可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系。
例如，现在有实例 1（ip：172.16.19.3）和实例 2（ip：172.16.19.5），我们在实例 2 上执行以下这个命令后，实例 2 就变成了实例 1 的从库，并从实例 1 上复制数据：
replicaof 172.16.19.3 6379之后会按照三个阶段完成数据的第一次同步。
第一阶段：主从库间建立连接、协商同步的过程，主要是为全量复制做准备。具体来说，从库给主库发送 psync 命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。psync 命令包含了主库的 runID 和复制进度 offset 两个参数。runID ，是每个 Redis 实例启动时都会自动生成的一个随机 ID ，用来唯一标记这个实例。当从库和主库第一次复制时，因为不知道主库的 runID ，所以将 runID 设为“？” 。offset ，此时设为 -1 ，表示第一次复制。
主库收到 psync 命令后，会用 FULLRESYNC 响应命令带上两个参数：主库 runID 和主库目前的复制进度 offset（这个offset是当前最新的值），返回给从库。从库收到响应后，会记录下这两个参数。
第二阶段：主库将所有数据同步给从库。具体来说，主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。从库接收到 RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。
为什么要先清空当前数据库呢？这是因为从库在通过 replicaof 命令开始和主库同步前，可能保存了其他数据。为了避免之前数据的影响，从库需要先把当前数据库清空。
在主库将数据同步给从库的过程中，主库不会被阻塞，仍然可以正常接收请求。否则， Redis 的服务就被中断了。但是，这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主从库的数据一致性，主库会在内存中用专门的 replication buffer ，记录 RDB 文件生成后收到的所有写操作。
第三阶段：当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。
主从复制整个过程示意图如下所示。

文章插图
主从库第一次同步的三个阶段
这样一来，主从库就实现同步了。不可忽视的是，这个过程中存在着风险点，最常见的就是网络断连或阻塞。如果网络断连，主从库之间就无法进行命令传播了，从库的数据自然也就没办法和主库保持一致了，客户端就可能从从库读到旧数据。
1.2 主从库间网络断了怎么办？在 Redis 2.8 之前，如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。只把主从库网络断连期间主库收到的命令，同步给从库。