repl_backlog_buffer和replication buffer理解比较混淆，我大概解释一下：

repl_backlog_buffer：就是上面我解释到的，它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量同步带来的性能开销。
- 如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量同步，
- 所以repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量同步的概率。
- 而在repl_backlog_buffer中找主从差异的数据后，如何发给从库呢？这就用到了replication buffer。
replication buffer：Redis和客户端通信也好，和从库通信也好，
- Redis都需要给分配一个内存buffer进行数据交互，客户端是一个client，从库也是一个client，
- 我们每个client连上Redis后，Redis都会分配一个client buffer，所有数据交互都是通过这个buffer进行的：
  - Redis先把数据写到这个buffer中，
  - 然后再把buffer中的数据发到client socket中再通过网络发送出去，这样就完成了数据交互。
- 所以主从在增量同步时，从库作为一个client，也会分配一个buffer，
  - 只不过这个buffer专门用来传播用户的写命令到从库，保证主从数据一致，我们通常把它叫做replication buffer。
再延伸一下，既然有这个内存buffer存在，那么这个buffer有没有限制呢？
- 如果主从在传播命令时，因为某些原因从库处理得非常慢，那么主库上的这个buffer就会持续增长，消耗大量的内存资源，甚至OOM。
- 所以Redis提供了client-output-buffer-limit参数限制这个buffer的大小，
  - 如果超过限制，主库会强制断开这个client的连接，也就是说从库处理慢导致主库内存buffer的积压达到限制后，
    - 主库会强制断开从库的连接，此时主从复制会中断，
  - 中断后如果从库再次发起复制请求，
    - 那么此时可能会导致恶性循环，引发复制风暴，这种情况需要格外注意。

来源：oschina

链接：https://my.oschina.net/u/3847203/blog/4562239

标签

Redis