redis为了实现高可靠性，通过RDB和AOF尽量减少了数据的丢失，通过主从模式尽量减少了服务的中断，增加了实例的副本的主从模式和读写分离保证了数据的一致性。
如果没有读写分离，每个实例都能提供读写功能，那么势必得通过锁住操作资源及多个实例间的通信协商操作的完成性判断，必然带来巨大的性能开销，所以通过读写分离，只有主库可以执行写操作，避免了实例间的协调，进而通过主从的数据同步来保证数据的一致性。
实例通过replicaof命令完成主从关系确认，从库发送“psync 主库id 复制进度 offset”同步请求，最开始是全量同步，主库发送RDB文件给从库，在这期间，主库接到的命令，记录到replication buffer中，待从库执行完RDB之后，再把replication buffer中的命令同步给从库，对于第一次同步而言，主库的压力在于生成最新的RDB文件，如果从库数量很多，而且都要和主库进行全量复制的话，就会导致主库忙于fork 子进程生成 RDB 文件，进行数据全量同步。fork 这个操作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢。此外，传输 RDB 文件也会占用主库的网络带宽，同样会给主库的资源使用带来压力，因此可以通过采用 主-从-从的级联模式缓解主库的压力。
级联模式
就是在从库中选择一个实例当成”主库A“，选择一些从库replicaof到A上面，这样我们真正的主库只需要同步到部分从库及"主库A"，进而通过主库A对其从库进行同步，一旦主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为基于长连接的命令传播，可以避免频繁建立连接的开销。假如说主从之间的网络发生了中断，如果我们从新进行一次全量的主从同步，必然耗费太高，所以通过增量复制同步给从库。
增量复制
当主从库断连后，主库会把断连期间收到的写操作命令，写入replication buffer，同时也会把这些操作命令也写入 repl_backlog_buffer 缓冲区。repl_backlog_buffer 是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置,对于主库而言，接收到的写操作之后会从起始位置开始偏移，对应的偏移量叫做 master_repl_offset，对于从库而言，复制完主库的写命令，也会从起始位置开始偏移，叫做 slave_repl_offset，正常情况下这两个偏移量基本相等，主从库的连接恢复之后，从库首先会给主库发送 psync 命令，并把自己当前的slave_repl_offset 发给主库，主库会判断自己的 master_repl_offset 和 slave_repl_offset之间的差值，就是在网络断连阶段，主库收到新的写命令，所以，一般来说，master_repl_offset会大于 slave_repl_offset，主库只用把 master_repl_offset 和 slave_repl_offset之间的命令操作同步给从库就行，因为 repl_backlog_buffer 是一个环形缓冲区，所以在缓冲区写满后，主库会继续写入，就会覆盖掉之前写入的操作。如果从库的读取速度比较慢，就有可能导致从库还未读取的操作被主库新写的操作覆盖，这会导致主从库间的数据不一致。我们可以通过repl_backlog_size设置缓冲区的大小，我们通过主库写入命令速度、主从网络命令传输的速度和从库操作命令的速度，再加上应对突发流量的增长以预估缓冲区大小，降低增量复制时主从数据不一致的风险。
