主从同步卡顿、断连主因是client-output-buffer-limit replica设置过小，导致从节点处理慢时主节点缓冲区溢出而强制断连；同时net.core.somaxconn与tcp-backlog不一致、TIME_WAIT端口耗尽、vm.overcommit_memory=0等内核参数配置不当也会引发连接异常。
为什么主从同步卡顿、断连？先看 client-output-buffer-limit replica 是否设小了
主从同步时，主节点要把 RDB 文件或增量命令流持续发给从节点。如果从节点处理慢（比如磁盘 IO 高、网络差、CPU 忙），数据就会在主节点的输出缓冲区堆积。一旦超过硬限制，Redis 会强制断开该从节点连接，日志里出现 Client output buffer limit reached。
默认值 client-output-buffer-limit replica 256mb 64mb 60 在千兆内网尚可，但万级写入 + 大 key 场景下极易触发断连：
- 硬限制（第一个值）建议设为
1073741824（1GB），避免 RDB 同步中途被杀 - 软限制（第二个值）设为
536870912（512MB），宽限时间保持 60 秒足够 - 务必配合
repl-backlog-size调大（如1073741824），防止从节点重连后无法部分同步
net.core.somaxconn 和 tcp-backlog 不一致，主从连接会随机丢包
主节点 accept() 新从节点连接时，依赖 Linux 全连接队列；而 Redis 的 tcp-backlog 是告诉内核“我最多能处理多少已完成三次握手的连接”。两者不匹配，高并发批量建立从节点时，accept() 来不及取走连接，队列溢出，新连接直接被内核丢弃——现象是部分从节点始终连不上，redis-cli -p 6379 info replication 里看不到自己。
必须同步调大：
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 修改
/etc/sysctl.conf：设置net.core.somaxconn = 65535 - 修改
redis.conf：设置tcp-backlog 65535 - 执行
sysctl -p生效，重启 Redis（仅改tcp-backlog需重启）
TIME_WAIT 连接占满端口，导致从节点反复重连失败
主从之间是长连接，但若频繁断连重连（比如因超时、配置错误、网络抖动），主节点上会积累大量 TIME_WAIT 状态连接。Linux 默认 net.ipv4.ip_local_port_range 是 32768–60999（约 28K 端口），很快耗尽，新连接报错 Cannot assign requested address。
关键参数不是“回收”，而是“复用”：
- 启用
net.ipv4.tcp_tw_reuse = 1（允许 TIME_WAIT socket 用于新连接） - 禁用
net.ipv4.tcp_tw_recycle = 0（内核 4.12+ 已废弃，开启反而导致 NAT 下从节点连接失败） - 扩大本地端口范围：
net.ipv4.ip_local_port_range = 10000 65000 - 注意：
tcp_tw_reuse只对客户端有效；主节点作为服务端不直接受益，但从节点作为客户端发起重连时依赖它
vm.overcommit_memory=1 不配，主节点 fork 子进程失败就成单点故障
主节点做 bgsave 或 AOF rewrite 时，需 fork 出子进程。若系统 vm.overcommit_memory=0，fork 会检查是否有足够物理内存+swap 承载当前进程镜像。而 Redis 内存占用大，fork 时即使只复制页表，内核也可能拒绝——日志出现 Can't save in background: fork: Cannot allocate memory，RDB 持久化中断，后续主从全量同步失败风险陡增。
生产环境必须设为 1：
- 执行
echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf && sysctl -p - 这不是“允许内存爆炸”，而是让 fork 基于写时复制（Copy-on-Write）安全执行
- 搭配
maxmemory合理设置（留 20%~30% 内存给系统和 fork），才能真正稳住主从链路
tcp-backlog 和 net.core.somaxconn 必须等值，tcp-tw-reuse 对从节点重连生效但对主节点无效，这些细节一旦错位，问题就表现为“间歇性断连”“重连超时”“同步卡死”，排查时容易误判为网络或 Redis bug。 
