redis主库切换后存在“幽灵数据”是正常窗口期现象，需用redis-full-check工具键值级比对而非仅依赖offset差值；它绕过复制协议，支持多数据结构逐字段校验，推荐配合--qps=500和--batchcount=256参数使用。
主库切换后，从库很可能存在主库已丢失、但自己还没来得及同步的“幽灵数据”——这不是 bug，而是哨兵故障转移过程中的正常窗口期行为。必须人工或工具介入检查，不能依赖 INFO replication 的偏移量差值就认为一致。
用 redis-full-check 快速比对主从键值级差异
仅靠 master_repl_offset 和 slave_repl_offset 差值为 0，并不等于数据真正一致：AOF重写、命令传播中断、部分写命令未落盘都可能导致 offset 对齐但内容错位。
-
redis-full-check是目前最轻量且生产验证过的开源工具，它绕过复制协议，直接遍历键并逐字段比对（支持 Hash/List/Set/ZSet） - 启动前确保目标主从实例均开启
keys *权限（或配置scan模式），否则无法获取全量 key 列表 - 推荐命令行参数组合：
./redis-full-check -s 192.168.8.112:6379 -t 192.168.8.111:6379 --qps=500 --batchcount=256（源为新主，目标为待检从） - 若对比中报
ERR wrong number of arguments，说明某从节点启用了 ACL 但未授权SCAN或GET命令，需补全权限
手动验证关键业务 key 是否同步完成
全量比对耗时长，上线前或紧急排查时，应优先抓取核心业务 key 的实时状态。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在旧主（刚恢复的节点）上执行：
redis-cli -h 192.168.8.111 -a '1+1=2?Yes' --scan --pattern "order:*" | head -n 100 | xargs -I{} redis-cli -h 192.168.8.111 -a '1+1=2?Yes' GET {} > /tmp/oldmaster.txt - 在新主上执行相同命令，输出到
/tmp/newmaster.txt，再用diff /tmp/oldmaster.txt /tmp/newmaster.txt查差异 - 注意：如果 key 是 Hash 类型，
GET会失败，改用HGETALL；List 类型用LRANGE key 0 -1；务必匹配实际数据结构 - 不要只查 key 存在性——
EXISTS返回 1 只代表 key 在，不代表 value 与主库一致
为什么 slaveof no one 后从库仍可能有残留数据
哨兵执行 slaveof no one 仅解除复制关系，并不清理从库本地已有的、但主库已删除或覆盖的数据。
- 例如：主库在切换前执行了
DEL user:1001，但该命令尚未传到某从库，该从库仍保留user:1001键 - 又如：主库因 AOF rewrite 截断了部分历史命令，而从库还缓存着旧命令的执行结果，导致状态分叉
- 这种数据残留不会被
INFO replication报出，因为复制链已断，offset 不再更新 - 唯一可靠方式是切换后立即触发一次全量校验，或在应用层加写后双删逻辑（如先删缓存再删 DB，再补删一次缓存）
真正的难点不在工具使用，而在判断“哪些 key 值得校验”。业务侧必须提供关键 key 模式（如 stock:*、session:* ），否则全自动扫描容易漏掉冷数据或误报临时 key。校验不是一次性的动作，而是切换后 5 分钟内必须完成的闭环操作。
