Redis 主从复制延迟过高通常由网络带宽饱和、主节点阻塞或从节点处理性能不足引起，优先检查网络连通性和主节点慢查询日志。调整 tcp-keepalive 和 repl-backlog-size 配置有助于维持连接稳定，但无法解决物理带宽瓶颈，生产环境修改配置前需评估重启风险。
先说结论：复制延迟高通常是网络带宽饱和或主节点阻塞导致，需结合监控指标定位瓶颈。
- 先定位：对比 master_repl_offset 和 slave_repl_offset 差值，确认延迟来源是网络还是负载。
- 先做：优化网卡中断绑定、调整 TCP 内核参数，避免在主节点执行大键删除或复杂命令。
- 再验证：观察 INFO replication 中的 replication_lag 指标是否回落至秒级以内。
命令速用版
# 查看复制状态
INFO replication
# 查看慢查询
SLOWLOG GET 10
# 查看网络丢包
ping -c 100 <slave_ip>
# 查看 TCP 参数
sysctl net.ipv4.tcp_keepalive_time为什么会这样
主从复制延迟本质是主节点写入偏移量与从节点同步偏移量之间的差值过大。网络带宽不足会导致复制数据排队，主节点执行阻塞命令会导致偏移量停止更新，从节点磁盘 I/O 过高会导致回放速度跟不上。
分步处理
第一步：确认延迟指标
登录主节点和从节点，分别执行 INFO replication，记录 master_repl_offset 和 slave_repl_offset。如果差值持续增大，说明存在复制积压。
第二步：检查网络链路
使用 ping 或 mtr 检查主从节点间的网络延迟和丢包率。如果跨机房部署，物理延迟无法消除，需评估是否接受最终一致性延迟。
第三步：优化内核参数
在主从节点调整 TCP 保持 alive 时间，防止空闲连接被防火墙切断。执行 sysctl -w net.ipv4.tcp_keepalive_time=300，注意该操作需 root 权限。
第四步：排查主节点阻塞
检查主节点 SLOWLOG，识别耗时命令。避免使用 KEYS、FLUSHALL 等阻塞命令，大键删除建议使用 UNLINK 异步删除。
怎么验证是否生效
执行 INFO replication 命令，观察 master_repl_offset 与 slave_repl_offset 的差值是否稳定或缩小。监控系统中 replication_lag 曲线应呈现下降趋势，且无频繁的全量复制日志。
常见坑
1. 盲目调大 repl-backlog-size：该参数仅影响部分重连，无法解决网络带宽不足导致的持续延迟，且占用内存。
2. 忽略从节点负载：从节点若同时承担高读流量，CPU 或网络带宽被业务占用，会直接影响复制线程速度。
3. 频繁全量同步：网络波动导致复制中断，若 backlog 不足会触发全量同步，进一步加剧网络拥塞。
常见问题
复制延迟多少算正常？
局域网环境通常应在秒级以内，跨机房环境取决于物理延迟，需根据业务容忍度设定报警阈值。
调整 tcp-keepalive 需要重启 Redis 吗？
不需要重启 Redis 服务，但修改操作系统 sysctl 参数后立即生效，Redis 配置文件中 tcp-keepalive 修改后需重启生效。
从节点延迟高会影响主节点写入吗？
默认配置下不会阻塞主节点写入，但若配置了 min-slaves-to-write 参数，主节点可能在从节点延迟过高时拒绝写入。