异步复制是redis主从数据不一致的根本原因，主节点执行命令后立即返回客户端，不等待从节点接收、解析或执行，导致master_repl_offset与slave_repl_offset天然解耦；网络、配置、参数等问题只是加剧因素，而非根源。
异步复制是根本原因，不是配置或网络问题
Redis主从同步数据不一致的根源，不是某次网络抖动、某个参数没调好，而是设计上就选择了异步复制——master_repl_offset推进和slave_repl_offset推进完全解耦。主节点执行完SET key val就返回客户端，不管从节点有没有收到、有没有解析、有没有执行。这个“确认即成功”的语义，决定了它天然无法提供强一致性。
常见误判：看到connected_slaves=1就以为一切正常；看到master_link_status:up就认为数据已同步。其实这些只说明TCP连上了，不代表命令流已消费。
- 主节点写入后，命令先进入复制缓冲区（repl-backlog），再发给从节点
- 从节点收到命令后，先存入本地缓冲区，再逐条解析执行——这中间存在至少两层延迟
- 一旦从节点CPU打满、磁盘IO卡住、或遇到
SMEMBERS这类O(N)命令，slave_repl_offset就会停滞，差值持续扩大
INFO replication 的 offset 差值不能直接当“落后量”用
master_repl_offset - slave_repl_offset这个差值，表面看是“漏了多少命令”，但实际含义更复杂。它可能反映的是网络延迟，也可能是从节点正在全量加载RDB，还可能是命令积压在解析队列里没开始执行。
必须结合其他字段交叉判断：
- 如果
master_sync_in_progress:1，说明正在全量同步，此时slave_repl_offset不会更新，差值无意义 - 如果
repl_backlog_active:0，说明复制积压缓冲区已停用，断连后只能全量重拉，差值再小也救不回中断期间的数据 - 如果
master_last_io_seconds_ago > repl-timeout（默认60），连接其实已经假死，但connected_slaves仍显示为1 - 差值稳定不增长 +
used_memory_peak_human从库远高于主库，大概率是bigkey解析阻塞了复制线程
repl-backlog-size 和 repl-backlog-ttl 是隐形开关
很多团队把repl-backlog-size设成256mb就以为高枕无忧，却忽略了repl-backlog-ttl默认3600秒——只要从节点断连超过1小时，哪怕只差几个字节，也会因缓冲区被清空而触发全量同步。而全量同步本身又会加剧主库压力，形成恶性循环。
生产环境真实影响：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
repl-backlog-size太小 → 差值一超就全量，主库BGSAVE+网络传输双重压力 -
repl-backlog-ttl太短 → 短时网络抖动（如交换机重启）直接导致全量重同步 - 两者都调大 → 主节点内存占用上升，RDB生成期间新写入无法进缓冲区，这部分靠增量补，但前提是缓冲区还活着
建议值：repl-backlog-size 536870912（512MB）、repl-backlog-ttl 7200，但需配合监控repl_backlog_histlen是否长期接近repl_backlog_size——如果是，说明还得再调。
slave-read-only 关闭会导致静默不一致
slave-read-only no不是“功能开关”，而是数据一致性地雷。旧版本Redis（
排查时容易忽略的线索：
-
slave_read_only:0且role:slave同时存在 - 主从
used_memory_human差异异常，但slave_repl_offset差值不大 - 某些key在从库存在、主库不存在，或值明显不符（比如时间戳比主库还新）
修复方式不是“重启从库”，而是人工校验该从库所有写操作，再决定是重置同步还是导出差异后人工合并——没有自动兜底机制。
真正难处理的不是offset差值大，而是差值看起来很小却读到过期数据、或从库明明slave_read_only:yes却被业务代码绕过直连写入。这些场景下，监控指标全绿，问题却已在静默中扩散。
