主从之间的复制
在主服务器与从服务器之间进行数据复制，分为两种方式：完整的重同步(full resynchronization)和部分的重同步(partial resynchronization)。
完整的重同步
主服务器创建并发送RDB文件，以及向从服务器发送保存在缓冲区里面的写命令来进行同步。
完整的重同步创建RDB文件、发送RDB文件会消耗主服务器的CPU、内存和磁盘IO等资源，同时也会占用大量的网络带宽和流量。在实际中，有时完整的重同步是没有必要的，例如当从服务器与主服务器网络连接断开时间很短，数据的不一致可能就是为数不多的几条写命令，这时却要进行全量数据的复制，显然是资源的浪费。其实只需要将断开连接期间的数据进行同步就可以完成数据的一致性。
完整的重同步只应该用于首次复制，或者万不得已需要全量复制时才执行。
部分的重同步
针对完整的重同步的缺陷，Redis提供了部分的重同步功能。
部分的重同步功能涉及到三个部分：
- 复制偏移量：主从服务器都会维护自己的复制偏移量，表示当前数据已经发送或者接受到的位置。对比复制偏移量可以知道主从服务器是否处于一致的状态。
-
复制积压缓冲区：主服务器维护的一个固定长度的先进先出的队列。当主服务器进行命令传播时，不仅会将写命令发送给所有从服务器，也会将写命令入队到复制积压缓冲区里面。
摘自《Redis设计与实现》第二版 - 服务器运行ID：主从服务器都有自己的运行ID，标识自身。运行ID在服务器启动时自动生成，40个随机的十六进制字符组成。
部分的重同步过程：
- 从服务器对主服务器进行首次复制时，从服务器会保存主服务器的运行ID。如果是首次复制会执行完整的重同步。
- 当从服务器断线后，重新连接主服务器，比较保存的主服务器运行ID与现在连接的主服务器运行ID，如果不同说明和之前连接的不是同一台服务器，需要执行完整的重同步。
- 如果运行ID一致，尝试执行部分的重同步。从服务器会将自己的复制偏移量发送给主服务器。
- 主服务器收到从服务器发来的复制偏移量，在自己维护的复制积压缓冲区寻找，如果偏移量之后的数据仍旧存在于复制积压缓冲区中，执行部分的重同步。如果偏移量之后的数据不在复制积压缓冲区中，执行完整的重同步。
主从之间的心跳
主服务器通过向从服务器传播命令来更新从服务器的状态，保持主从服务器一致，而从服务器通过向主服务器发送命令来进行心跳检测，以及命令丢失检测。
在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令心跳。用于检测主从之间的网络连接状态，以及检测传播的命令是否丢失等。
