md5sum抽样校验更实用，因全量行对比会锁表、耗时长，而md5sum序列化摘要可并行且快；但仅能发现差异，不能定位错误条目，需覆盖热点与冷key并统一序列化方式。
迁移过程中出现数据不一致，不是“会不会发生”，而是“在哪一步出的”。关键要盯住 checksum 校验结果和增量同步断点是否连续。
为什么 md5sum 抽样校验比全量行对对比更实用
大数据量下全量行比对会锁表、拖慢验证周期，而 md5sum 对 key 的序列化值做摘要，耗时低、可并行。但要注意：它只告诉你“有没有差异”，不告诉你“哪几条错了”。
- 抽样必须覆盖热点 key 和冷 key，比如用
SCAN随机游标取 0.1% 的 key，再按TYPE分类抽样（string、hash、zset各抽若干） - 序列化方式必须统一：源库和目标库都用
GET/HGETALL/ZRANGE ... WITHSCORES等命令输出标准格式，避免因 Lua 脚本或客户端序列化差异导致 md5 不等 - 若发现某类结构（如
hash）md5 失败率高，优先检查目标端是否启用了noeviction——否则HMSET可能因内存满被静默丢弃，不报错但数据缺失
增量同步中断后，如何确认是否还能走 psync 增量而非强制全量
核心看两个值是否在 INFO replication 输出中对得上：master_repl_offset（主节点当前偏移）和从节点的 slave_repl_offset，以及主节点 repl_backlog_active 是否为 1。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 执行
redis-cli -h $MASTER_HOST INFO replication | grep -E "(master_repl_offset|repl_backlog_active)"和同理查从节点 - 如果从节点
slave_repl_offset落后 ≤repl-backlog-size（默认 1MB，建议设为 16mb），且run_id未变，则psync可继续，不会触发全量 - 一旦看到
master_repl_offset - slave_repl_offset > repl-backlog-size，说明 backlog 缓冲区已被覆盖，此时 DTS 或自建同步程序会退回到SYNC全量流程——这就是数据延迟突增、CPU 打满的根源
DBSIZE 数量对不上时，先别急着判定不一致
源库和目标库的 DBSIZE 差异，90% 以上是过期 key 清理节奏不同导致的。Redis 不会在 key 过期瞬间删除，而是惰性删除 + 定期抽样清理。
- 用
INFO keyspace查看各 db 的 key 数量分布，比DBSIZE更细粒度；再用DEBUG OBJECT <key>抽查几个已过期但还存在的 key，确认 TTL 是否为负值 - 真正需要关注的是
expired_keys和evicted_keys指标：前者表示正常过期数量，后者表示因maxmemory-policy被逐出的数量——如果目标库evicted_keys持续增长，说明内存不足，必须调大maxmemory或切到noeviction - 对于带
EXPIRE的 key，迁移工具（如 DTS）通常不复制过期时间本身，而是靠目标端重设，因此需确认目标端是否开启了lazyfree-lazy-expire yes，否则大量过期 key 会阻塞主线程
最易被忽略的一点：Lua 脚本执行结果无法被同步工具捕获。哪怕 EVALSHA 返回成功，目标端也可能因 script cache miss 或参数类型错误静默失败。线上迁移前，务必把所有用到的 EVAL/EVALSHA 脚本单独拎出来，在目标库手工执行一遍，并核对返回值和 key 状态变化。
