真实延迟需观察master_last_io_seconds_ago是否持续>3秒、slave_repl_offset与master_repl_offset差值是否持续扩大且从库offset停滞；若前者>60秒或后者长期不涨，表明网络中断或从节点卡死。
怎么确认主从同步延迟真实存在
别一上来就调参数，先看 INFO REPLICATION 输出里有没有异常信号。重点关注两个字段：master_last_io_seconds_ago（主从最后一次通信间隔，超过 3 秒就该警惕）、slave_repl_offset 和 master_repl_offset 的差值（即积压字节数）。如果差值持续增长，说明从节点拉不动数据；如果 master_last_io_seconds_ago 长期 > 60，大概率是网络中断或从节点卡住。
常见错误现象：
-
master_last_io_seconds_ago突然跳到几百甚至上千秒 → 从节点进程卡死或网络断开 -
slave_repl_offset停滞不涨 → 从节点内存不足触发 OOM Killer 或 client-output-buffer-limit 被击穿 - 主节点
used_memory_peak_human在全量同步期间翻倍 → fork 子进程失败或阻塞严重
repl-backlog-size 设多少才不频繁全量同步
默认 1MB 的 repl-backlog-size 在中高写入场景下基本等于没设。它不是越大越好，但太小会直接导致断连后强制全量同步——而全量同步会触发 fork，拖慢主节点、打满带宽、还可能让其他从节点也掉线。
计算依据是：最大可容忍断连时间 × 平均写入速率 × 安全系数（建议 1.5～2）。
实操建议：
- 写入峰值约 20 MB/s、允许断连 60 秒 → 至少配
repl-backlog-size 2gb - 用
INFO REPLICATION查repl_backlog_histlen，若长期接近repl-backlog-size，说明缓冲区已满，必须扩容 - 云环境建议起步 512mb，生产高写入实例直接上 2～4gb，别省这点内存
启用 repl-diskless-sync 后反而更慢？
无盘同步（repl-diskless-sync yes）跳过磁盘 IO，对 SSD 寿命和 fork 延迟友好，但它把压力从磁盘搬到了网络和 CPU。一旦网络抖动或丢包，重传成本比磁盘 RDB 更高。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
容易踩的坑：
- 没配
repl-diskless-sync-delay 5→ 多个从节点同时请求，主节点反复 fork，CPU 爆表 - 内网带宽不足（比如千兆网卡跑满 100MB/s 写入），开启无盘后网络打满，主节点响应变慢
- Linux TCP 栈未调优：
net.core.rmem_max过小导致 socket 接收缓冲区溢出，从节点收包丢帧
建议搭配调整：tcp-keepalive 60 + sysctl -w net.ipv4.tcp_slow_start_after_idle=0，避免 Nagle 算法引入额外延迟。
监控延迟不能只看 INFO，得落地告警
INFO REPLICATION 是手动排查工具，不是监控方案。真正要防住延迟恶化，得把关键指标暴露给 Prometheus，并设阈值告警。
核心采集点：
-
redis_replication_master_last_io_seconds_ago> 5 秒 → 触发 P1 告警（可能已失联） -
redis_replication_slave_repl_offset与主节点 offset 差值 > 100MB → 触发 P2 告警（同步明显滞后） - 从节点
used_memory_rss_human持续 > 90% → 提前预警缓冲区溢出风险
注意：Prometheus 抓取 /metrics 接口前，Redis 必须运行 redis_exporter，且主从节点的 exporter 配置要区分 instance 标签，否则所有延迟指标会混在一起无法定位。
最常被忽略的一点：延迟不是独立问题，它永远是网络、内存、配置、写入模式四者共同作用的结果。改一个 repl-backlog-size 不解决根本，得同步查 ifconfig 的丢包率、dmesg 的 OOM 日志、slowlog get 10 里的大 key 删除操作——否则调完参数，过两天又回原样。
