好的，各位观众老爷们，欢迎来到今天的技术分享会！今天我们要聊的，是 Redis 主从复制中的两位重量级选手：无盘复制（Diskless Replication）和 RDB 文件传输。
别看它们名字有点学术范儿，其实都是 Redis 为了提高复制效率，让主从数据同步更快更稳的“秘密武器”。想象一下，主从服务器就像一对形影不离的好基友，老大（主服务器）负责赚钱养家，小弟（从服务器）负责备份数据，以防老大哪天嗝屁了，还能顶上。
那问题来了，老大辛辛苦苦赚来的家产，怎么才能快速又安全地同步给小弟呢？这就是我们今天要探讨的核心。
第一幕：RDB 文件传输——老派的土豪式同步
首先，让我们来认识一下 RDB 文件传输这位老大哥。它可是 Redis 主从复制的元老级人物，资格老，经验丰富。
RDB (Redis DataBase) 文件，你可以把它想象成老大精心打包的家产清单，里面记录了所有值钱的东西。老大定期（或者在特定情况下）会把这份清单做一份拷贝，然后一股脑地丢给小弟。小弟拿到清单后，吭哧吭哧地照着清单把自己的家底重新整理一遍，力求和小弟保持一致。
RDB 文件传输的流程，大致可以分为以下几步：
- 老大一声令下： 当从服务器第一次连接主服务器，或者复制中断后重新连接时，从服务器会向主服务器发送一个 SYNC 命令（在 Redis 5.0 之后，已经被 PSYNC 命令取代，PSYNC 更加智能，可以实现增量复制，我们稍后会提到）。
- 老大开始打包： 主服务器收到 SYNC 命令后，会执行 BGSAVE 命令，开始在后台生成 RDB 文件。这个过程不会阻塞主线程，老大可以继续赚钱，不用停下来专门打包。
- 老大传送清单： RDB 文件生成完毕后，主服务器会将 RDB 文件发送给从服务器。这个过程就像快递员把一个巨大的包裹送到你家门口。
- 小弟埋头苦干： 从服务器收到 RDB 文件后，会先清空自己的数据（如果配置了
slave-read-only yes，则会阻止写入操作），然后加载 RDB 文件，恢复数据。这个过程就像你收到包裹后，把里面的东西一件一件地摆放整齐。
RDB 文件传输的优点：
- 简单粗暴： 流程简单，实现容易，就像用一个大锤解决所有问题。
- 恢复速度快： 从服务器加载 RDB 文件恢复数据的速度很快，因为 RDB 文件是经过压缩的二进制文件。
RDB 文件传输的缺点：
- 耗费磁盘 I/O： 主服务器需要将 RDB 文件写入磁盘，从服务器需要从网络接收 RDB 文件，然后写入磁盘。这涉及到大量的磁盘 I/O 操作，容易成为性能瓶颈。
- 全量复制： 每次都需要全量复制，即使只有少量数据发生变化，也需要重新生成和传输整个 RDB 文件。这就像你只是想买一瓶酱油，却被快递员送来了一整个超市。
- 可能导致服务中断： 虽然主服务器在后台生成 RDB 文件，但仍然会对性能产生一定影响。从服务器在加载 RDB 文件期间，通常无法提供服务，导致服务中断。
表格总结：RDB 文件传输的优缺点
| 特性 | 优点 | 缺点 |
|---|---|---|
| 流程 | 简单粗暴 | 耗费磁盘 I/O，全量复制，可能导致服务中断 |
| 性能 | 恢复速度快 | 对主服务器性能有一定影响，从服务器加载期间可能无法提供服务 |
| 适用场景 | 初始同步，数据量较小，对实时性要求不高 | 数据量大，频繁更新，对实时性要求高的场景不适用 |
第二幕：无盘复制——轻装上阵的闪电侠同步
为了解决 RDB 文件传输的缺点，Redis 2.8.18 版本引入了无盘复制（Diskless Replication）技术。这位新秀一出场，就惊艳四座，因为它彻底颠覆了传统的复制方式。
无盘复制，顾名思义，就是主服务器在生成 RDB 文件时，不再写入磁盘，而是直接通过网络发送给从服务器。这就像老大不再需要打包家产清单，而是直接用语音告诉小弟，省去了打包和快递的环节，大大提高了效率。
无盘复制的流程，大致可以分为以下几步：
- 老大一声令下： 同样，从服务器向主服务器发送 PSYNC 命令。
- 老大开始准备： 主服务器收到 PSYNC 命令后，会启动一个子进程（与 BGSAVE 类似）生成 RDB 文件，但不再写入磁盘。
- 老大实时播报： 主服务器将生成的 RDB 文件通过网络直接发送给从服务器。这个过程就像老大在直播，小弟实时收听。
- 小弟同步进行： 从服务器收到 RDB 文件后，一边接收数据，一边加载数据，无需等待整个 RDB 文件传输完成。
无盘复制的优点：
- 减少磁盘 I/O： 主服务器不再需要将 RDB 文件写入磁盘，大大降低了磁盘 I/O 压力。
- 提高复制效率： 由于省去了磁盘 I/O 环节，复制速度更快。
- 减少服务中断时间： 从服务器可以一边接收数据，一边加载数据，减少了服务中断时间。
无盘复制的缺点：
- 依赖网络带宽： 无盘复制对网络带宽要求较高，如果网络带宽不足，可能会导致复制失败。
- 容错性较差： 如果在 RDB 文件传输过程中出现网络中断，需要重新进行全量复制。
- 只能进行一次全量复制： 在无盘复制期间，如果有新的从服务器连接，只能等待当前复制完成后才能进行复制。
表格总结：无盘复制的优缺点
| 特性 | 优点 | 缺点 |
|---|---|---|
| 流程 | 减少磁盘 I/O，提高复制效率，减少服务中断时间 | 依赖网络带宽，容错性较差，只能进行一次全量复制 |
| 性能 | 复制速度更快 | 对网络带宽要求较高，网络中断会导致复制失败 |
| 适用场景 | 网络带宽充足，数据量较大，对实时性要求较高 | 网络带宽不足，需要频繁进行全量复制的场景不适用 |
第三幕：PSYNC——智能的增量复制
无论是 RDB 文件传输还是无盘复制，都存在一个共同的问题：每次都需要进行全量复制，即使只有少量数据发生变化。为了解决这个问题，Redis 2.8 版本引入了 PSYNC 命令，实现了增量复制。
PSYNC 命令就像一位聪明的侦探，它能够判断主从服务器之间的数据差异，只同步发生变化的部分，大大提高了复制效率。
PSYNC 命令的工作原理：
PSYNC 命令依赖于两个重要的概念：
- Replication Offset： 主从服务器都会维护一个 Replication Offset，用于记录已经复制的数据量。主服务器每发送一部分数据，就会增加自己的 Replication Offset；从服务器每接收一部分数据，也会增加自己的 Replication Offset。
- Replication Backlog： 主服务器会维护一个 Replication Backlog，用于存储最近一段时间内发送的数据。Replication Backlog 是一个环形缓冲区，当缓冲区满了之后，新的数据会覆盖旧的数据。
PSYNC 命令的两种模式：
- Full Resynchronization (全量同步)： 当从服务器第一次连接主服务器，或者无法进行增量复制时，会触发全量同步。全量同步的过程与 RDB 文件传输或无盘复制类似。
- Partial Resynchronization (增量同步)： 当主从服务器之间的连接中断后重新连接时，会尝试进行增量同步。增量同步的过程如下：
- 从服务器向主服务器发送 PSYNC 命令，并携带自己的 Replication Offset。
- 主服务器检查从服务器的 Replication Offset 是否在 Replication Backlog 中。
- 如果在，则主服务器将 Replication Backlog 中从服务器缺失的数据发送给从服务器。
- 如果不在，则触发全量同步。
PSYNC 命令的优点：
- 提高复制效率： 只同步发生变化的数据，大大提高了复制效率。
- 减少网络带宽消耗： 只传输少量数据，减少了网络带宽消耗。
- 减少服务中断时间： 增量同步速度更快，减少了服务中断时间。
PSYNC 命令的缺点：
- 依赖 Replication Backlog： 如果从服务器断开连接的时间过长，导致 Replication Backlog 中的数据被覆盖，则无法进行增量同步，需要进行全量同步。
- 需要额外的内存空间： Replication Backlog 需要占用一定的内存空间。
第四幕：如何选择？——根据场景选择合适的同步方式
既然我们了解了 RDB 文件传输、无盘复制和 PSYNC 命令的优缺点，那么在实际应用中，应该如何选择合适的同步方式呢？
- 初始同步： 当从服务器第一次连接主服务器时，通常需要进行全量同步。如果网络带宽充足，可以选择无盘复制；如果网络带宽不足，可以选择 RDB 文件传输。
- 数据量较小： 如果数据量较小，可以选择 RDB 文件传输，因为其流程简单，实现容易。
- 数据量较大： 如果数据量较大，且网络带宽充足，可以选择无盘复制，以提高复制效率。
- 频繁更新： 如果数据频繁更新，应该使用 PSYNC 命令进行增量同步，以减少网络带宽消耗和服务中断时间。
- 网络环境不稳定： 如果网络环境不稳定，应该选择 RDB 文件传输，因为其容错性较好。
总结：
RDB 文件传输、无盘复制和 PSYNC 命令都是 Redis 主从复制中重要的技术手段。RDB 文件传输是老派的土豪式同步，无盘复制是轻装上阵的闪电侠同步，PSYNC 命令是智能的增量复制。我们需要根据实际场景，选择合适的同步方式，才能充分发挥 Redis 主从复制的优势，提高系统的可用性和性能。
希望今天的分享能够帮助大家更好地理解 Redis 主从复制的原理和实践。感谢大家的观看！ 👏