redis 主从集群

为了保证整个系统的高可用，避免单点故障，我们通常需要采用集群的方式来提高 redis 的并发能力，而搭建 redis 主从集群，实现读写分离便是其具体方案。

搭建主从架构

具体搭建流程参考课前资料 《Redis集群方案.md 》

主从同步原理

主从同步是指，为保证主从节点数据一致性，将一台Redis服务器的数据，复制到其他的Redis服务器，前者称为master主节点，后者称为slave从节点。这种复制是单向的，主 ==> 从;

概述

主从同步的作用 主要包括：

  • 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
  • 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
  • 负载均衡：在主从数据一致的基础上，配合读写分离，可以由 主节点提供写服务 ，由 从节点提供读服务 ，分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以 大大提高 Redis 服务器的并发量。
  • 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说 主从复制是 Redis 高可用的基础。

主从库之间采用的是读写分离的方式。

  • 读操作：主库、从库都可以接收；
  • 写操作：首先到主库执行，然后，主库将写操作同步给从库。

image-20210725152037611

原理

  • 全量（同步）复制：比如第一次同步时
  • 增量（同步）复制：只会把主从库网络断连期间主库收到的命令，同步给从库

全量同步

主从第一次建立连接时，会执行 全量同步 ，将master节点的所有数据都拷贝给slave节点，流程：

image-20210725152222497

  • 确立主从关系

    replicaof xx.xx.xx.xx 6379

    这里有一个问题，master 如何得知 salve 是第一次来连接呢？？

    有几个概念，可以作为判断依据：

    • Replication Id：简称 replid，是数据集的标记，id 一致则说明是同一数据集。每一个 redis实例 都有唯一的 replid，slave则会继承 master 节点的 replid
    • offse：偏移量，随着记录在 repl_baklog 中的数据增多而逐渐增大。slave 完成同步时也会记录当前同步的 offset。如果slave 的 offset 小于 master 的 offset ，说明 slave 数据落后于 master，需要更新。

  • 三个阶段

    • 第一阶段是主从库间建立连接、协商同步的过程，主要是为全量复制做准备。在这一步，从库和主库建立起连接，并告诉主库即将进行同步，主库确认回复后，主从库间就可以开始同步了。

      具体来说，从库给主库发送 psync 命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。psync 命令包含了主库的 Replication ID 和复制进度 offset 两个参数。因此 slave 做数据同步，必须向 master 声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据。因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与 master 建立连接时，发送的replid和offset 是自己的 replid 和 offset。master 判断发现 slave 发送来的 replid 与自己的不一致，说明这是一个全新的 slave，就知道要做全量同步了。master 会将自己的 replid 和 offset 都发送给这个 slave，slave 保存这些信息。以后 slave 的 replid 就与 master 一致了。

    • 第二阶段，主库将所有数据同步给从库。从库收到数据后，在本地完成数据加载。这个过程依赖于内存快照生成的 RDB 文件。

      具体来说，主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。从库接收到 RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。这是因为从库在通过 replicaof 命令开始和主库同步前，可能保存了其他数据。为了避免之前数据的影响，从库需要先把当前数据库清空。在主库将数据同步给从库的过程中，主库不会被阻塞，仍然可以正常接收请求。否则，Redis 的服务就被中断了。但是，这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主从库的数据一致性，主库会在内存中用专门的 replication buffer，记录 RDB 文件生成后收到的所有写操作。

    • 第三个阶段，主库会把第二阶段执行过程中新收到的写命令，再发送给从库。具体的操作是，当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。这样一来，主从库就实现同步了。

完整流程描述：

  1. slave节点请求增量同步
  2. master 节点判断replid，发现不一致，拒绝增量同步
  3. master 将完整内存数据生成 RDB，发送 RDB 到slave
  4. slave 清空本地数据，加载 master 的RDB
  5. master 将RDB期间的命令记录在 repl_baklog ，并持续将 log 中的命令发送给slave
  6. slave 执行接收到的命令，保持与master之间的同步

增量同步

为什么会设计增量复制？

​ 全量同步需要先做RDB，然后将RDB文件通过网络传输给 slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与 master 都是做增量同步。

先看两个概念： replication buffer 和 repl_backlog_buffer

repl_backlog_buffer：它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量复制带来的性能开销。如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量复制，所以repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量复制的概率。而在repl_backlog_buffer中找主从差异的数据后，如何发给从库呢？这就用到了replication buffer。

replication buffer：Redis和客户端通信也好，和从库通信也好，Redis都需要给分配一个 内存buffer进行数据交互，客户端是一个client，从库也是一个client，我们每个client连上Redis后，Redis都会分配一个client buffer，所有数据交互都是通过这个buffer进行的：Redis先把数据写到这个buffer中，然后再把buffer中的数据发到client socket中再通过网络发送出去，这样就完成了数据交互。所以主从在增量同步时，从库作为一个client，也会分配一个buffer，只不过这个buffer专门用来传播用户的写命令到从库，保证主从数据一致，我们通常把它叫做replication buffer。

如果在网络断开期间，repl_backlog_size环形缓冲区写满之后，从库是会丢失掉那部分被覆盖掉的数据，还是直接进行全量复制呢？

对于这个问题来说，有两个关键点：

  1. 一个从库如果和主库断连时间过长，造成它在主库repl_backlog_buffer 的 slave_repl_offset 位置上的数据已经被覆盖掉了，此时从库和主库间将进行 全量复制。
  2. 每个从库会记录自己的 slave_repl_offset，每个从库的复制进度也不一定相同。在和主库重连进行恢复时，从库会通过psync命令把自己记录的 slave_repl_offset 发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制。

主从同步优化

可以从以下几个方面来优化Redis主从就集群：

  • 在master中配置 repl-diskless-sync yes 启用无磁盘复制，避免全量同步时的磁盘 IO。(避免磁盘IO)
  • Redis 单节点上的内存占用不要太大，减少 RDB 导致的过多磁盘IO。（减少磁盘IO）
  • 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步。（降低磁盘IO的频率）
  • 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力。（分散磁盘IO的压力）

主从从架构图：

image-20210725154405899

深入理解主从集群

当主服务器不进行持久化时复制的安全性

在进行主从复制设置时，强烈建议在主服务器上开启持久化，当不能这么做时，比如考虑到延迟的问题，应该将实例配置为避免自动重启。

为什么不持久化的主服务器自动重启非常危险呢？为了更好的理解这个问题，看下面这个失败的例子，其中主服务器和从服务器中数据库都被删除了。

  • 我们设置节点A为主服务器，关闭持久化，节点B和C从节点A复制数据。
  • 这时出现了一个崩溃，但Redis具有自动重启系统，重启了进程，因为关闭了持久化，节点重启后只有一个空的数据集。
  • 节点B和C从节点A进行复制，现在节点A是空的，所以节点B和C上的复制数据也会被删除。
  • 当在高可用系统中使用Redis Sentinel，关闭了主服务器的持久化，并且允许自动重启，这种情况是很危险的。比如主服务器可能在很短的时间就完成了重启，以至于Sentinel都无法检测到这次失败，那么上面说的这种失败的情况就发生了。

如果数据比较重要，并且在使用主从复制时关闭了主服务器持久化功能的场景中，都应该禁止实例自动重启。

为什么主从全量复制使用RDB而不使用AOF？

1、RDB文件内容是经过压缩的二进制数据（不同数据类型数据做了针对性优化），文件很小。而AOF文件记录的是每一次写操作的命令，写操作越多文件会变得很大，其中还包括很多对同一个 key 的多次冗余操作。在主从全量数据同步时，传输RDB文件可以尽量降低对主库机器网络带宽的消耗，从库在加载RDB文件时，一是文件小，读取整个文件的速度会很快，二是因为RDB文件存储的都是二进制数据，从库直接按照RDB协议解析还原数据即可，速度会非常快，而AOF需要依次重放每个写命令，这个过程会经历冗长的处理逻辑，恢复速度相比RDB会慢得多，所以使用RDB进行主从全量复制的成本最低。

2、假设要使用AOF做全量复制，意味着必须打开AOF功能，打开AOF就要选择文件刷盘的策略，选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量复制数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景，其实是不需要开启AOF的。

为什么还有无磁盘复制模式？

Redis 默认是磁盘复制，但是 如果使用比较低速的磁盘，这种操作会给主服务器带来较大的压力 。Redis从2.8.18版本开始尝试支持无磁盘的复制。使用这种设置时，子进程直接将RDB通过网络发送给从服务器，不使用磁盘作为中间存储。

无磁盘复制模式：master创建一个新进程直接 dump RDB 到 slave 的 socket ，不经过主进程，不经过硬盘。适用于 disk 较慢，并且网络较快的时候。

使用 repl-diskless-sync 配置参数来启动无磁盘复制。

使用repl-diskless-sync-delay 参数来配置传输开始的延迟时间；master等待一个repl-diskless-sync-delay的秒数，如果没slave 来的话，就直接传，后来的得排队等了; 否则就可以一起传

为什么还会有从库的从库的设计？

通过分析主从库间第一次数据同步的过程，你可以看到，一次全量复制中，对于主库来说，需要完成两个耗时的操作：生成 RDB 文件和传输 RDB 文件。

如果从库数量很多，而且都要和主库进行全量复制的话，就会导致主库忙于 fork 子进程生成 RDB 文件，进行数据全量复制。fork 这个操作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢。此外，传输 RDB 文件也会占用主库的网络带宽，同样会给主库的资源使用带来压力。那么，有没有好的解决方法可以分担主库压力呢？

其实是有的，这就是“主 - 从 - 从”模式。

在刚才介绍的主从库模式中，所有的从库都是和主库连接，所有的全量复制也都是和主库进行的。现在，我们可以通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力，以级联的方式分散到从库上。

简单来说，我们在部署主从集群的时候，可以手动选择一个从库（比如选择内存资源配置较高的从库），用于级联其他的从库。然后，我们可以再选择一些从库（例如三分之一的从库），在这些从库上执行如下命令，让它们和刚才所选的从库，建立起主从关系。

总结

在使用读写分离之前，可以考虑其他方法增加Redis的读负载能力：如尽量优化主节点（减少慢查询、减少持久化等其他情况带来的阻塞等）提高负载能力；使用Redis集群同时提高读负载能力和写负载能力等。如果使用读写分离，可以使用哨兵，使主从节点的故障切换尽可能自动化，并减少对应用程序的侵入。