池田依来沙（٩(๑❛ᴗ❛๑)۶）
白天学习《梁家河》，晚上学学Redis，党的政治素养和个人技术提高两手抓，光喊口号是不够的，要做行动上的巨人。。。好像有点跑题了orz
上节讲解了复制原理中的复制过程和数据同步，这节主要讲全量复制、部分复制和心跳。（参考付磊、张益军两位大神的《Redis开发与运维》）
全量复制
全量复制是Redis最早支持的复制方式，也是主从第一次建立复制时必须经历的阶段。触发全量复制的命令是sync（2.8版本以下）和psync（2.8版本以上，包括2.8）。
全量复制流程
流程说明：
-
发送psync命令进行数据同步，由于是第一次复制，从节点没有复制偏移量和主节点的运行ID，所以发送psync ? -1。
-
主节点根据psync ? -1解析出当前为全量复制，回复+FULLRESYNC响应。
-
从节点接受主节点的响应数据保存运行ID和偏移量offset。
-
主节点执行bgsave保存RDB文件到本地。
-
主节点发送RDB文件给从节点，从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件，接收完RDB后从节点打印相关日志。
5.1 传输文件这一步骤非常耗时，速度取决于主从节点之间网络带宽。我们可以通过分析Full resync和MASTER<->SLAVE这两行日志的时间差，可以算出RDB文件从创建到传输完毕消耗的总时间。如果总时间超过repl-timeout所配置的值（默认60秒），从节点将放弃接受RDB文件并清理已经下载的临时文件，导致全量复制失败。所以针对数据量较大的节点，建议调大repl-timeout参数防止出现全量同步数据超时。 -
对于从节点开始接收RDB快照到接收完成期间，主节点仍然响应读写命令，所以主节点会把这期间写命令数据保存在复制客户端缓冲区内，当从节点加载完RDB文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。
6.1 如果主节点创建和传输RDB的时间过长，对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出。默认配置client-output-buffer-limit slave 256MB 64MB 60，如果60秒内缓冲区消耗持续大于64MB或直接超过256MB，主节点将直接关闭复制客户端连接，造成全量失败。 -
从节点接收完主节点传送来的全部数据后会清空自身旧数据。
-
从节点清空数据后开始加载RDB文件，对于较大的RDB文件，这一操作依然比较耗时，可以通过计算日志之间的时间差来判断加载RDB的总耗时。
8.1 对于线上做读写分离的场景，从节点也负责响应读命令。如果此时从节点正处于全量复制阶段或者复制中断，那么从节点在响应读命令可能拿到过期或错误的数据。这种场景，Redis复制提供了slave-serve-stale-data参数（默认开始状态）。如果开启，则从节点依然响应所有命令。对于无法容忍不一致的应用场景可以设置no来关闭命令执行，此时从节点除了info和slaveof命令之外只返回“SYNC with master in progress”信息。
9、从节点成功加载完RDB后，如果当前节点开启了AOF持久化功能，会立刻执行bgrewriteaof操作，为了保证全量复制后AOF持久化文件立刻可用。
纵观整个全量复制的流程，会发现全量复制是一个非常耗时耗力的操作。光是时间开销就有：
- 主节点bgsave时间
- RDB文件网络传输时间
- 从节点清空数据时间
- 从节点加载RDB的时间
- 可能的AOF重写时间
所有除了第一次复制时采用全量复制在所难免之外，对于其他场景应该规避全量复制的发生。不过正因为全量复制的成本问题，Redis部分复制应运而生。
部分复制
部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施，使用psync {runId} {offset}命令实现。当从节点（slave）正在复制主节点（master）时，如果出现网络中断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，如果主节点的复制积压缓冲区内存在这部分数据则重新发送给从节点，这样就可以保持主从节点复制的一致性。（补发的部分数据一般远远小于全量复制，所以开销很小。）
部分复制过程
流程说明：
1、当主从节点之间网络出现中断时，如果超过repl-timeout时间，主节点会认为从节点故障并中断复制连接。
2、主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内部存在的复制积压缓冲区，依然可以保存最近一段时间的写命令数据（默认最大缓存为1MB）。
3、当主从节点网络恢复后，从节点会再次连上主节点。
4、当主从连接恢复后，由于主节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把他们当做psync参数发送给主节点，要求进行部分复制操作。
5、主节点接到psync命令后首先核对参数runId是否与自身一致，如果一致，说明之前复制的是当前主节点；接着根据参数offset在自身复制积压缓冲区查找，如果偏移量之后的数据存在缓冲区中，则对从节点发送+CONTINUE响应，表示可以进行部分复制。
6、主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进去正常状态。(发送的数据量可以在主节点的日志获取。)
心跳
主从节点在建立复制后，他们之间维护着长连接并彼此发送心跳命令。
主从心跳检测
主从心跳判断机制：
-
主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信，通过client list命令查看复制相关客户端信息，主节点的连接状态为flags=M，从节点的连接状态为flags=S。
-
主节点默认每隔10秒对从节点发送ping命令，判断从节点的存活性和连接状态。可通过参数repl-ping-slave-period控制发送频率。
-
从节点在主线程中每隔1秒发送replconf ack {offset}命令，给主节点上报自身当前的复制偏移量。replconf命令主要作用如下：
- 实时监测主从节点网络状态
- 上报自身复制偏移量，检查复制数据是否丢失，如果从节点数据丢失，再从主节点的复制缓冲区中拉取丢失数据
- 实现保证从节点的数量和延迟性功能， 通过min-slaves-to-write、min-slaves-max-lag参数配置定义
主节点根据replconf命令判断从节点超时时间，体现在info replication中的lag信息中，lag表示与从节点最后一次通信延迟的秒数，正常延迟应该在0和1之间。如果超过repl-timeout配置的值(默认60秒)，则判定从节点下线并断开复制客户端连接，即使主节点判定从节点下线后，如果从节点重新恢复，心跳检测会继续进行。
（PS.为了降低主从延迟，一般把Redis主从节点部署在相同的机房/同城机房，避免网络延迟和网络分区造成的心跳中断等情况）
异步复制
主节点不但负责数据读写，还负责把写命令同步给从节点。写命令的发送过程是异步完成，即主节点本身处理完写命令后直接返回给客户端，并不等待从节点复制完成。
主节点复制过程
主节点复制流程：
- 主节点接收处理命令
- 命令处理完之后返回响应结果
- 对于修改命令异步发送给从节点，从节点在主线程中执行复制的命令
小结
“复制原理”的章节告一段落，比较偏理论，需要静下心来好好学习，如果觉得写得还不错，请关注点赞赞赏，谢谢！
网友评论