Redis主从复制

建立主从命令：
slaveOf 主库ip port

复制类型

Redis2.8之前只有全量复制，2.8之后全量+增量

• 全量复制：比如在第一次同步时
• 增量复制：网络通讯中断后，从库重新连接，增量复制

全量复制

1. 主库和从库建立通讯连接，协商复制过程。从库发起数据同步，向主库发送fsycn {runId} {offSet}请求，比如fsync ? -1代表请求从库不知道主库的runId，offSet为1表示是第一次复制。主库收到后，响应fullresync {runId} {offSet}，告诉从库运行时ID，以及当前数据同步的偏移量。
2. 主库向从库发生RDB文件。主库执行bgsave，开始生成RDB文件，并且在生成完毕后向从库发送。从库收到了RDB后，先将本库内容清空，因为在这段时间内，可能已经收到了主库发送过来的部分内容。清空后通过RDB文件进行恢复。在这段时间内，主库会将发生的写操作写到replication buffer内。
3. 主库向从库发送replication buffer。当主库完成文件发送后，会再将replication buffer发送，从库再执行，以此来保证最终一致性。
   
   image.png

增量复制

1. 从库短线重连
2. 从库发送psync {runId} {offSet}命令
3. 主库根据偏移量计算需要同步的数据
4. 通过repl_buffer发送需要同步的数据

• repl_backlog_buffer（复制积压缓冲区）
  环形缓冲区，主库内部会维护自己的repl_backlog_buffer，每次主库向从库同步同步写命令时，会同时维护内部的repl_bak缓冲区。当从库断开连接重连后，向主库请求同步数据，发送psync {runId} {offSet}，主库根据offSet偏移量和repl_bak内的偏移量进行对比，计算出差异的数据，并写入repl_buffer内，发送到从库实现断连期间的数据同步。但当offSet在repl_bak内找不到时，说明新数据已经将覆盖掉环形缓冲区了，此时只能进行全量备份，所以尽量将repl_bak设置的大一些，避免全量同步，默认为1M。

• replication buffer
  redis内无论客户端和redis通信，还是主库和从库通信，均需要创建repl_buffer。客户端是一个client，从库也是一个client，当客户端连接到redis后，redis会创建一个repl_buffer，redis先把数据写到buffer内，再输出buffer通过socket将数据发送出去，所以主从同步时也是同样，先输出到repl_buff，再发送到从库内实现同步。

  
  
  image.png

命令传播阶段

主库在收到写操作后，异步向slave发送修改命令，以尽量快的保证数据一致。

命令传播阶段

在主从正常通讯的阶段，从库每秒向主库发送心跳，发送REPLCONF ACK ，向主库发送偏移量。
主要有3个用处：

1. 检测主从节点的连接
2. 辅助实现min-slave
3. 检查是否存在命令丢失

问题

1. 为什么主从全量复制使用RDB而不是AOF
   1. RDB文件占用空间较小，使用了内存压缩技术，且RDB是二进制数据，恢复数据块，而AOF是执行的命令，恢复数据慢
   2. 如果使用AOF，说明需要开启AOF的持久化，需要持续刷盘，会对磁盘的IO产生压力，而RDB一般在定时备份和全量复制才会触发。
2. 什么是无磁盘复制模式
   Redis默认全量复制是磁盘复制，但是如果磁盘性能较差，会对主服务器产生压力。无磁盘复制就是Master节点fork一个新线程，直接dump RDB到从库的socket，不写入到磁盘。适用于磁盘较慢，网络较快的场景。
3. 为什么还有从库的从库设计模式
   如果是一主多从，多个从节点的数据复制，都需要从主库这边消耗线程资源，如果是一主-多从-多从，同步的压力就会级联分散到从库这边，由从库再向下一级从库发送同步数据。
4. 读写分离器中的问题

   1. 延迟与不一致的问题
      用于主从同步的过程是异步的，所以延迟问题无法避免，Redis本身也只能保证最终一致性。但是可以尽量减少延迟：比如优化主从之间的网络延迟、监控主从节点延迟，如果offSet差异过大，则不再从次从节点读取数据、使用集群拓展读写能力。
      在初始过程或者是网络连接不畅的时候，不一致的差异会增大。例如主从节点无法连接的时候，可以通过slave-serve-stale-data配置来优化，如果对差异性要求不高，设为yes，即允许在主从网络不通的情况下，接收读命令，设为no则是不允许。

   2. 数据过期问题
      在单机版的Redis中，有2种缓存过期策略：
      惰性删除：读取key时，判断如果ttl过期，则删除key
      定期删除：服务器定时删除过期内存，但是频发删除内存会对cpu产生压力，所以删除的频率和时间都受到了限制
      在主从复制的场景下，从库为了保证数据的一致性，不会主动删除过期数据，都是由主节点控制删除过期数据。在Redis3.2后，在从节点读取到过期数据时，会自动不再返回给客户端。

   3. 故障切换问题
      在没有使用哨兵模式的情况下，需要客户端自己去选择连接主库还是从库，增加应用的复杂度，对于容灾也需要自己去实现。

总结

主从模式要和哨兵模式共同使用，以实现容灾、自动切换负载的功能。

参考链接：
https://www.pdai.tech/md/db/nosql-redis/db-redis-x-copy.html