Redis主从库网络断连问题——repl_backlog_buffer

主从库间网络断了怎么办？

• 在 Redis 2.8 之前，如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。

• 从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。

  增量复制只会把主从库网络断连期间主库收到的命令，同步给从库。

增量复制通过 repl_backlog_buffer 这个缓冲区实现。

• repl_backlog_buffer 是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。
  -

主库的所有写命令除了通过replication buffer传播给从库之外，都会在这个repl_backlog_buffer（只要有从库，这个缓冲区就一定会存在）中记录一份，缓存起来。通过repl_backlog_buffer预先缓存数据，在从库恢复时就能够通过这个缓存区进行数据恢复（具体原理下文会说）。

replication buffer 和 repl_backlog_buffer 的区别（后面会详细介绍）：

• replication buffer 对于一主多从来说是相互独立，即redis会为每一个redis client创建一个独立的replication buffer，通过该buffer传输数据，
• repl_backlog_buffer则是多个从库共用一个，每一个redis client都会有一个offset，该offset除了在断开重连后会通过psync将自己的offset传递给master，主从还维护了一个心跳机制，从节点会向主节点发送REPLCONF ACK命令，频率是每秒1次，命令格式为：REPLCONF ACK {offset}，其中offset指从节点保存的复制偏移量告知master，repl_backlog_buffer通过该offset进行移动

repl_backlog_buffer 工作原理：

• 刚开始的时候，主库和从库的写读位置在一起，这算是它们的起始位置。随着主库不断接收新的写操作，它在缓冲区中的写位置会逐步偏离起始位置，我们通常用偏移量来衡量这个偏移距离的大小，对主库来说，对应的偏移量就是 master_repl_offset。主库接收的新写操作越多，这个值就会越大。

• 同样，从库在复制完写操作命令后，它在缓冲区中的读位置也开始逐步偏移刚才的起始位置，此时，从库已复制的偏移量 slave_repl_offset 也在不断增加。正常情况下，这两个偏移量基本相等。（感觉和 mysql 的 redo log 的机制有点像）

主从库的连接恢复之后的数据同步：

主从库的连接恢复之后，从库首先会给主库发送 psync 命令，并把自己当前的 slave_repl_offset 发给主库，主库会判断自己的 master_repl_offset 和 slave_repl_offset 之间的差距。主库只用把 master_repl_offset 和 slave_repl_offset 之间的命令操作同步给从库就行。(通过replication buffer)

增量复制的流程：

此时，数据恢复的大致流程就完成啦！！！

下面是一些注意点和重点事项：

注意点：因为 repl_backlog_buffer 是环形缓冲区，如果主库写的速度大于从库的读取速度，那么会发生数据覆盖的情况。（如果发生覆盖后，就不得不进行全量复制）

一般而言，我们可以调整 repl_backlog_size 这个参数。

缓冲空间的计算公式是：缓冲空间大小 = 主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小

repl_backlog_size = 缓冲空间大小 * 2（一般会考虑并发情况）

重点：

1. 一个从库如果和主库断连时间过长，造成它在主库repl_backlog_buffer的slave_repl_offset位置上的数据已经被覆盖掉了，此时从库和主库间将进行全量复制。
2. 每个从库会记录自己的slave_repl_offset，每个从库的复制进度也不一定相同。在和主库重连进行恢复时，从库会通过psync命令把自己记录的slave_repl_offset发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制。

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。
3. 再延伸一下，既然有这个内存buffer存在，那么这个buffer有没有限制呢？如果主从在传播命令时，因为某些原因从库处理得非常慢，那么主库上的这个buffer就会持续增长，消耗大量的内存资源，甚至OOM。所以Redis提供了client-output-buffer-limit参数限制这个buffer的大小，如果超过限制，主库会强制断开这个client的连接，也就是说从库处理慢导致主库内存buffer的积压达到限制后，主库会强制断开从库的连接，此时主从复制会中断，中断后如果从库再次发起复制请求，那么此时可能会导致恶性循环，引发复制风暴，这种情况需要格外注意。

参考资料：极客时间