复制偏移量（offset）是主从同步进度的字节计数器，主从offset相等是逻辑一致的必要条件；但offset对齐不保证强一致，需结合lag、连接状态及外部校验。
复制偏移量（offset）本身不直接“校验数据一致性”，而是反映主从之间命令流的同步进度。它是一个轻量、高效的状态指标，用于判断是否已接收并执行完全部写命令——只有当主从 offset 完全相等，且无其他异常（如连接中断、状态非 connected），才能认为当前处于逻辑一致状态。
Offset 是什么：同步进度的字节计数器
主节点每向从节点发送 1 字节的复制数据（包括命令、RDB 头部、AOF 格式指令等），master_repl_offset 就加 1；从节点每成功解析并执行 1 字节，slave_repl_offset 也加 1。两者数值相同，意味着从节点已完整复现主节点到该时刻的所有写操作序列。
- offset 不是键值对数量，也不是哈希校验值，而是基于 TCP 流的线性偏移量
- 它不关心数据内容是否“语义一致”，只保证“命令执行顺序与主库完全一致”
- 因此，offset 对齐是最终一致性的必要条件，但不是充分条件（例如，若从节点执行了错误命令但 offset 已更新，仍会表现为 offset 一致）
如何用 offset 判断同步状态是否健康
在主节点执行 INFO replication，查看 master_repl_offset；在每个从节点执行同样命令，找到对应 slave0 或 slave1 区块中的 slave_repl_offset。
- 若从节点
slave_repl_offset == master_repl_offset，且master_link_status:up、slave_state:online，说明增量同步已追平 - 若差值持续为 0，但业务读到旧值，需排查客户端是否绕过从节点直连主库，或是否开启了
slave-read-only no导致脏写 - 若差值突然增大（如 >512KB），即使状态显示 connected，也可能因网络抖动、从节点阻塞（如 bgsave、慢 Lua 脚本）导致积压
offset 对齐 ≠ 数据完全一致：关键边界情况
offset 只能确认命令流已送达并执行，但无法覆盖所有不一致场景：
- 主节点写入后宕机，未及时落盘：若使用 RDB 或 AOF no-appendfsync-on-rewrite 模式，这部分命令可能丢失，而从节点 offset 已更新，形成“伪一致”
- 从节点执行失败但未报错：比如 EXPIRE 命令在从节点遇到不存在的 key，Redis 默认静默忽略，不中断同步也不回滚 offset
- 时钟漂移影响过期逻辑：key 在主节点过期，但从节点系统时间滞后，可能导致该 key 在从节点多存活一段时间——offset 一致，但实际状态不一致
- repl-backlog 被覆盖后触发全量同步：此时 offset 会被重置，新同步开始前存在明显窗口期，期间写入不可见
配合 offset 的实用校验建议
仅靠 offset 不足以保障强一致，需组合以下手段提升可信度：
- 定期比对
INFO stats中的instantaneous_ops_per_sec和rejected_connections，识别从节点是否因负载高丢指令 - 启用
repl-diskless-sync yes+repl-diskless-sync-delay 5，减少全量同步时磁盘 I/O 对 offset 追赶的干扰 - 监控
repl_backlog_active和repl_backlog_size，确保 backlog 大小能覆盖典型断连窗口（建议 ≥ 预估峰值写入量 × 60 秒） - 对关键业务 key，可辅以客户端层双读比对（如主+某从同时 GET，校验返回值），但不宜高频使用
