背景

某次抢购时，一个redis集群的某个分片，从实例响应时间陡增到几十秒，报警后运维将其中一个本应该下线的slave下掉，问题减轻但没有解决，又把另一个正常的slave下线掉，问题消失。

master日志

09:59:11.842 # Client id=19768058 addr=xx.xxx.xx.xx:46599 fd=7 name= age=235951 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=10581 omem=268636408 events=rw cmd=replconf scheduled to be closed ASAP for overcoming of output buffer limits.

09:59:11.851 # Client id=19770026 addr=xx.xxx.xx.x:64139 fd=6 name= age=208571 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=10581 omem=268636408 events=rw cmd=replconf scheduled to be closed ASAP for overcoming of output buffer limits.

09:59:11.863 # Connection with slave xx.xxx.xx.x:xxxx lost.

09:59:11.878 # Connection with slave xx.xxx.xx.x:xxxx lost.

slave日志

09:59:11.866 # Connection with master lost.

09:59:43.057 # I/O error trying to sync with MASTER: connection lost

10:00:17.720 # I/O error trying to sync with MASTER: connection lost

10:00:48.585 # I/O error trying to sync with MASTER: connection lost

10:01:20.326 # I/O error trying to sync with MASTER: connection lost

过程描述

两个slave的日志是一样的，所以只摘取了其中一个。

通过master日志可以看出是master因为slave client buffer达到上限，主动关闭了连接，master当时的cpu达到100%，且不断进行bgsave操作，慢日志里有很多psync命令。

从slave日志来看，master连接被断开，然后slave不断进行连接建立和数据拷贝。

过程分析

通过grafana监控发现该业务的写流量第一次达到123MB，但是client-output-buffer-limit slave 256mb 64mb 60，所以主在流量超过60mb之后会将主动将slave连接关闭，这时候从通过psync命令请求数据同步，但是repl-backlog-size 64mb，此时按照现有的流量，增量同步需要的数据已经不在复制缓冲区里面了，master会进行全量复制，全量复制成功后，slave阻塞式加载rdb数据。

以上过程是一个循环，不断重复，导致从实例基本不能响应读请求(时间基本在30s)，主实例受影响并不大，这也是为什么摘除从实例可以减轻甚至恢复问题的原因。

建议

对于写流量比较大的业务，主从复制有关的buffer包括repl-backlog-size、client-output-buffer-limit slave可以调成峰值流量的两倍甚至同普通客户端buffer一样不做限制。