redis主从健康需同时监控master_link_status和偏移量差值：status为down或up但master_last_io_seconds_ago＞60表明连接异常；master_repl_offset与slave_repl_offset差值持续＞1mb说明同步滞后，lag字段易误导不可单独依赖。

直接看 INFO replication 输出，这是最准、最快、最不需要额外依赖的判断方式。

主从连接状态必须盯紧 master_link_status

这个字段是健康与否的第一道门槛。它只可能为 up 或 down，没有中间态：

• master_link_status:up 表示 TCP 连接正常，但不等于数据已同步 —— 还要看 master_sync_in_progress 和偏移量差值
• master_link_status:down 说明网络断开、防火墙拦截、主节点宕机或从节点配置错误（比如 replicaof 指向了不可达地址）
• 注意：即使 master_link_status 是 up，如果 master_last_io_seconds_ago 持续大于 60，大概率主从心跳已失效，只是 TCP 连接没被内核回收

用偏移量差值判断实际延迟大小

主从复制不是“时间同步”，而是“命令流同步”。真正反映滞后程度的是两个偏移量之差：master_repl_offset 减去 slave_repl_offset：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 差值为 0：理想状态，从节点完全追平
• 差值在几百字节内：基本可忽略，常见于小流量写入场景
• 差值持续 > 1MB：说明从节点写入速度跟不上主节点，可能因磁盘 I/O 瓶颈、CPU 过载或网络丢包导致
• 差值突增后长期不回落：大概率从节点卡在某条命令执行上（比如大 key 的 HGETALL），需查 SLOWLOG

别只看 lag 字段，它有严重误导性

lag 是从节点上报给主节点的“自报延迟”，单位秒，但它只反映最后一次心跳间隔，不是真实复制延迟：

• 默认每秒上报一次，所以 lag:1 只表示“上次心跳是 1 秒前发的”，不代表落后 1 秒数据
• 如果从节点 CPU 被打满，lag 可能卡在 1 不动，但实际偏移量差已达数 MB
• 跨机房部署时，lag 常因网络抖动虚高，此时更应依赖 master_repl_offset - slave_repl_offset 的绝对值
• 某些 Redis 版本（如 6.2+）在从节点阻塞时会停止上报 lag，表现为字段消失而非数值增大

监控脚本里要避开这些坑

自动化采集时容易踩的几个硬伤：

• 不要只连从节点执行 INFO replication —— 它看不到主节点的 master_repl_offset，必须分别连主、从两端取值再比对
• 避免用 redis-cli --scan 类工具轮询，高频 INFO 本身会增加主节点负载，建议采样间隔 ≥ 5 秒
• 解析 INFO 输出时，别用简单字符串分割（如 split(':')），某些字段值含冒号（如 master_host:10.0.1.100:6379），要用冒号前最后一个键名定位
• 哨兵模式下，INFO replication 在从节点返回的是当前主节点信息，但若哨兵刚完成 failover，新主节点的 run_id 已变，旧从节点可能还在连老主 —— 此时 master_link_status 是 down，但你得先确认是否已切换成功

偏移量差值和连接状态这两项，必须同时纳入告警阈值，单看一个都会漏判。尤其当网络抖动导致短暂断连又恢复时，master_link_status 会闪回 up，但积压缓冲区（repl_backlog_hislen）可能已被冲掉，引发全量同步 —— 这种隐性损伤，只有对比偏移量才能发现。