redis主从同步卡住主因是磁盘io瓶颈而非cpu不足，表现为bgsave_in_progress长期为1、latest_fork_usec超500ms，iostat显示%util>90%或await>50ms；需停rdb改aof、迁ssd、调大repl-backlog-size（≥64mb）、优化client-output-buffer-limit及排查慢查询。
主库bgsave卡住：其实是磁盘IO拖垮了复制
主从同步卡在 bgsave_in_progress:1 长时间不结束，不是CPU不够，而是磁盘写入跟不上。机械盘、云盘IOPS限速、RDB文件过大（>2GB）都会让fork+写盘双阻塞，导致复制缓冲区持续积压，最终触发重试。
- 用
redis-cli --stat观察：bgsave_in_progress:1持续超30秒，且latest_fork_usec > 500000（即>500ms），基本可断定是IO瓶颈 - 查真实磁盘压力：
iostat -x 1 3看%util是否长期 >90%，await是否 >50ms；云环境重点看EBS/云盘IOPS是否打满 - 临时缓解：执行
CONFIG SET save ""停RDB，改用AOF +appendfsync everysec - 长期方案：迁SSD、调高云盘配额，或拆分大实例（避免单实例RDB超4GB）
从库RDB加载慢：先确认数据有没有真正流进来
从节点 master_sync_in_progress:1 时间很长，但 master_sync_left_bytes 下降极慢（比如每秒只减几MB），说明问题不在从库解析，而在主库发不出、或链路被掐。
- 在主节点用
ss -i或tcpdump -i any port 6379抓包，看是否有持续的大块TCP数据包（>1MB）发出；没有，就是主库卡在发送环节 - 检查
client-output-buffer-limit slave设置：若设为256mb 64mb 60，而RDB是4GB，传输需200秒，60秒内累计超64MB就会被主节点强制断连 - 生产建议直接设为
1024mb 512mb 60，并确保从库网卡、交换机端口不限速（尤其跨机房场景，注意TCP窗口缩放、MTU匹配）
复制积压缓冲区太小：表面同步慢，实际被迫反复全量
从节点断线重连后不走增量（PSYNC），直接fallback到全量（SYNC），不是因为网络断太久，而是主节点的 repl-backlog-size 太小，旧offset对应的数据早被覆盖了。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 默认值通常为1MB，对中等流量集群远远不够；建议设为 ≥64MB，高吞吐场景建议 ≥512MB
- 修改后需重启或用
CONFIG SET repl-backlog-size 67108864生效（注意：该配置不支持热重载所有版本，Redis 8.2.3已支持） - 配合
INFO replication中的repl_backlog_active和repl_backlog_histlen实时观察积压是否稳定、有无频繁回卷
慢查询和输出缓冲区溢出：别只盯网络，先看slowlog和CLIENT LIST
主从复制卡住时，INFO replication 显示 master_link_status:down 或偏移量长期不增长，第一线索不是网络，而是slowlog堆积和输出缓冲区异常。
- 执行
SLOWLOG GET 10，重点关注耗时超client-output-buffer-limit slave阈值（默认60秒）的命令，如KEYS、未加COUNT的SCAN、大集合SUNION/ZINTERSTORE；以及 >100ms 的EXEC/EVAL - 用
CLIENT LIST筛选从库连接：qbuf > 1048576（1MB）说明从库处理慢或网络延迟高；obl > 67108864（64MB）已触发硬限制，主库会主动断连 -
age很大但idle也很大，可能是从库假死，主库尚未检测到心跳超时，需人工介入检查
IO堵塞问题最易被误判为网络或CPU问题，实际根源常藏在磁盘吞吐、缓冲区配置、慢命令堆积这三个层面。排查时务必按“主库IO → 数据传输链路 → 积压缓冲区 → 客户端连接状态”顺序推进，跳过任一环都可能白忙半天。
