作者回复: 我看到还有几个同学在问类似的这个问题，大家都思考的很仔细，非常好! 对于这个问题来说，有两个关键点： 1. 一个从库如果和主库断连时间过长，造成它在主库repl_backlog_buffer的slave_repl_offset位置上的数据已经被覆盖掉了，此时从库和主库间将进行全量复制。 2. 每个从库会记录自己的slave_repl_offset，每个从库的复制进度也不一定相同。在和主库重连进行恢复时，从库会通过psync命令把自己记录的slave_repl_offset发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制。

作者回复: Redis在全量复制时，既支持先生成RDB文件，再把RDB文件传给从库，也支持在主库上直接通过socket把数据传给从库，这称为无盘复制。 如果运行主库的机器磁盘性能不太好，但是网络性能不错的话，可以考虑无盘复制。

作者回复: 没错，环形缓冲区再大，在某些时候，就如你所说的从库长期断网时，也会出问题。 其实从库正常情况下会每秒给主库发送一个replconf ack命令，主库会根据这个命令的达到时间判断和从库的连网情况。如果距离最后一次ack命令收到的时间已经超过了repl_timeout时间，就会和从库断开连接了。 从库再和主库连接时，会发送自己的复制进度，如果要复制内容在缓冲区中已经被覆盖了，那么就不再做增量复制了，而是进行全量复制。

作者回复: Redis主从库的复制是异步的，主库收到命令操作后，在本地执行完成后，就会返回给客户端，并不会等到和从库同步完成后才返回给客户端。 如果从库同步较慢的话，例如从库正在执行bigkey操作，那么复制进度就会落后，此时，从库数据不是强一致性保证。

作者回复: 咱们评论区有不少同学的回复都很棒，思考问题非常仔细、周全和深入。 读评论区是一次非常好的再学习过程 :)

作者回复: 善于思考，非常棒！ repl_backlog_buffer是所有从库共享的，不过正如文章中说的，slave_repl_offset是由从库自己记录的，这也是因为每个从库的复制进度不一定相同。 从库断连后再恢复时，会给主库发送psync命令，并把自己当前的slave_repl_offset发给主库。所以，在你所说的情况下，正常恢复的从库推进的slave_repl_offset是它自己记录的，不会影响到第二个从库。 第二个从库断连后再恢复，只要slave_repl_offset指向的数据没有被覆盖，就能继续恢复。 希望解答了你的问题 :)

作者回复: 不错的总结！

作者回复: 咱们有同学问到了类似slave_repl_offset被覆盖的这个问题，你的回复就是答案。 :) 我在文章小结中有提到了一句“通过调大这个参数（repl_backlog_size），可以减少从库在网络断连时全量复制的风险”，这种情况就是因为repl_backlog被覆盖写了，导致从库开始全量复制。不过这句的确不明显，不容易让大家注意，都是我的错。。。

作者回复: 这个需要客户端实现（例如Redisson客户端），或者在客户端和集群间增加一个proxy才行，由客户端或proxy先行判断是读操作还是写操作，再把读、写操作发给从库或主库