最轻量且优先执行的判断是用INFO replication检查偏移量是否对齐；需先确认master_sync_in_progress:0，再结合master_last_io_seconds_ago、repl_backlog_histlen等指标交叉验证同步状态。
用 INFO replication 看偏移量是否对齐
这是最轻量、最优先执行的判断动作。主从数据是否在同步轨道上，INFO replication 里的 master_repl_offset 和 slave_repl_offset 是第一手证据。
常见错误现象：从节点 slave_repl_offset 比主节点小几百甚至几千，但 master_link_status:up、role:slave，看起来一切正常——其实只是“连接着”，不代表“同步着”。
- 先确认
master_sync_in_progress:0，否则正在全量同步，slave_repl_offset不更新是正常的 - 再看
master_last_io_seconds_ago：若 >60（默认repl-timeout），说明心跳已超时，连接可能假死 - 若该值
-
slave_read_only:0时要特别小心——业务误写从库会阻塞复制流解析，旧版本可能静默失败
用 DBSIZE 快速筛查键数量是否严重偏离
DBSIZE 返回当前 db 的 key 总数，虽然不验证内容，但能暴露结构性异常：比如从节点 key 数为 0，或比主节点少 30% 以上，基本可判定同步中断、配置错误，或该节点已被踢出集群。
注意点：
- 必须确保所有节点查的是同一个 database index（默认
db0），跨 db 比较无意义 - 避免在高峰期执行，虽然
DBSIZE是 O(1)，但会触发内部统计刷新，高并发下可能短暂阻塞 - 发现差异后，不要直接归因为“从节点丢数据”——先回溯
INFO replication，再查CLUSTER NODES看该节点是否被标记为fail?或handshake
用 redis-full-check 做字段级一致性验证
当偏移量对齐、键数量一致，但业务仍报“读到旧值”，问题往往藏在结构型数据里：比如 HASH 某个 field 值没同步、ZSET 的 score 错位、LIST 少了一段元素。这时候肉眼比对或抽样 GET/HGETALL 完全不可行。
redis-full-check 是目前唯一能覆盖 String/Hash/List/Set/ZSet/Stream 全类型、支持多轮收敛校验的开源方案。
- 它不依赖复制偏移量，而是逐 key 扫描并比对完整序列化结果，适合最终一致性兜底
- 首次运行建议在低峰期 + 从节点上执行，避免影响主节点性能
- 输出中重点关注
diff_count和具体 key 列表，不要只看 summary 行 - 若校验过程中出现
ERR max number of clients reached，需调大目标实例的maxclients
为什么不能跳过偏移量检查直接跑 redis-full-check
因为 redis-full-check 是重量级操作：它需要建立两个连接（主+从）、全量扫描 key、序列化比对，单次耗时可能达分钟级。如果主从还在明显同步滞后状态（比如 master_repl_offset - slave_repl_offset > repl_backlog_size），此时跑校验不仅浪费资源，还会得出大量“伪差异”——这些差异根本不是数据损坏，只是还没来得及同步。
真正容易被忽略的是时间维度交叉验证：offset 差值本身没有绝对意义，必须结合 master_last_io_seconds_ago、repl_backlog_histlen、used_memory_peak_human 一起看。比如从节点内存峰值远高于主节点，大概率是某个 bigkey 解析卡住，拖慢了整个 offset 推进节奏。
