旧版主从复制
旧版主从复制主要有个操作：
- 同步（sync）
- 命令传播（command propagate）
1. 同步
2. 命令传播
缺陷：
每次进行断线重连时，就要进行全量复制，影响资源
1. BGSAVE 生成RDB快照会影响主服务器的I/O资源，cpu资源
2. 传输大量数据浪费网络资源
3. 从服务器进行同步时，阻塞，没法处理命令请求
新版复制psync
- 完整同步
- 部分同步
部分同步实现
复制积压缓冲区（repl_backlog_buffer）
如果需要同步的数据超过了复制积压缓冲区，就需要全量复制。
PSYNC实现
一些TRICKY POINT
从库过多怎么办：
主从从模式
repl-backlog-buffer和 replication buffer的区别
1、repl_backlog_buffer：就是上面我解释到的，它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量同步带来的性能开销。如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量同步，所以repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量同步的概率。而在repl_backlog_buffer中找主从差异的数据后，如何发给从库呢？这就用到了replication buffer。
2、replication buffer：Redis和客户端通信也好，和从库通信也好，Redis都需要给分配一个 内存buffer进行数据交互，客户端是一个client，从库也是一个client，我们每个client连上Redis后，Redis都会分配一个client buffer，所有数据交互都是通过这个buffer进行的：Redis先把数据写到这个buffer中，然后再把buffer中的数据发到client socket中再通过网络发送出去，这样就完成了数据交互。所以主从在增量同步时，从库作为一个client，也会分配一个buffer，只不过这个buffer专门用来传播用户的写命令到从库，保证主从数据一致，我们通常把它叫做replication buffer。
Ref
- Redis设计与实现
