📚 课程目录第3章数据完整性校验

3. 数据完整性校验：多维度一致性验证

Redis 迁移完成后，数据完整性校验是验证迁移成功与否的核心环节。仅依赖业务功能测试无法覆盖所有数据细节，必须通过工具扫描、计数对比和二进制解析三个维度进行系统性验证。本章介绍三种互补的校验方法：redis-cli --bigkeys 快速扫描、Key 数量对比以及RDB 文件级一致性校验。

校验原则：先粗后细、先快后慢。先做 Key 总数和类型分布对比（分钟级），再用 --bigkeys 扫描大 Key 分布（视数据量 5~30 分钟），最后用 RDB 工具做全量一致性校验（小时级）。任何一步发现差异，立即中断后续步骤，排查迁移链路。

3.1 方法一：Key 数量与类型分布对比

最基础的校验手段，通过 INFO keyspace 和 DBSIZE 命令快速获取源库与目标库的 Key 总数，并按数据类型统计分布。此方法适合迁移后的第一轮冒烟检查，能在 1 分钟内发现明显的数量级差异。

检查项	源库命令	目标库命令	预期结果
Key 总数	`DBSIZE`	`DBSIZE`	完全一致
各库 Key 数	`INFO keyspace`	`INFO keyspace`	每个 db 的 keys 值一致
类型分布	`MEMORY USAGE` + 抽样	`MEMORY USAGE` + 抽样	分布趋势一致

# 源库 Key 总数
redis-cli -h source-host -p 6379 DBSIZE

# 目标库 Key 总数
redis-cli -h target-host -p 6379 DBSIZE

# 源库 keyspace 详情
redis-cli -h source-host -p 6379 INFO keyspace

# 目标库 keyspace 详情
redis-cli -h target-host -p 6379 INFO keyspace

注意：如果源库与目标库的 Key 总数差异超过 0.1%，不要盲目认为迁移失败。先检查迁移过程中是否有写入流量（增量数据），确认迁移窗口是否完全关闭。若迁移窗口已关闭且差异 > 0.1%，则必须进入下一轮校验。

3.2 方法二：redis-cli --bigkeys 扫描与对比

redis-cli --bigkeys 是 Redis 官方提供的扫描工具，它会遍历整个实例，按数据类型统计每个类型中最大的 Key 以及该类型的总体分布。迁移后使用该工具分别扫描源和目标，对比大 Key 的分布是否一致，能快速发现因序列化/反序列化导致的数据截断或类型转换错误。

# 扫描源库大 Key
redis-cli -h source-host -p 6379 --bigkeys > source_bigkeys.txt

# 扫描目标库大 Key
redis-cli -h target-host -p 6379 --bigkeys > target_bigkeys.txt

# 对比两个输出文件
diff source_bigkeys.txt target_bigkeys.txt

对比时重点关注以下指标：

每个类型最大的 Key 名称与大小：名称应一致，大小差异应在 5% 以内（考虑内存碎片和序列化开销）。
每个类型的 Key 总数：如源库有 1000 个 string 类型 Key，目标库也应为 1000 个。
每个类型的总大小：string 总大小、hash 总大小等应基本一致。

  实战经验：某次迁移后，--bigkeys 发现源库 hash 类型最大 Key 大小为 12MB，目标库仅为 8MB。进一步排查发现迁移工具对 hash 中某个 field 的 TTL 处理有误，导致部分 field 过期被删除。通过 --bigkeys 的对比，在 10 分钟内定位了问题。

3.3 方法三：RDB 文件级一致性校验（redis-rdb-tools）

最严格的一致性校验方式。通过将源库和目标库分别导出为 RDB 文件，使用 redis-rdb-tools（rdb）工具解析并对比每个 Key 的完整内容，包括 value、TTL、编码类型等。此方法能发现任何级别的数据差异，但耗时较长，适合在迁移窗口关闭后的离线校验阶段执行。

3.3.1 导出 RDB 文件

# 源库导出 RDB（需在迁移窗口关闭后执行）
redis-cli -h source-host -p 6379 --rdb source.rdb

# 目标库导出 RDB
redis-cli -h target-host -p 6379 --rdb target.rdb

3.3.2 使用 redis-rdb-tools 解析与对比

# 安装 redis-rdb-tools
pip install rdbtools python-lzf

# 将 RDB 解析为 JSON 格式（包含所有 Key 和 TTL）
rdb --command json source.rdb > source.json
rdb --command json target.rdb > target.json

# 使用 diff 或自定义脚本对比 JSON 文件
diff source.json target.json

# 或者使用内存对比模式（更快）
rdb --command diff source.rdb target.rdb

3.3.3 对比维度清单

对比维度	检查内容	允许误差	发现的问题类型
Key 名称	所有 Key 的完整名称	0	Key 丢失、Key 名称被篡改
Value 内容	string/hash/list/set/zset 的完整值	0	数据截断、序列化错误、字符编码问题
TTL/过期时间	每个 Key 的剩余存活时间	±5 秒（考虑导出时间差）	TTL 丢失、TTL 被重置
编码类型	如 string 的 raw/embstr/int 编码	0	编码转换导致的内存膨胀
内存大小	每个 Key 的近似内存占用	±10%	内存碎片差异、编码差异

重要提示：RDB 对比必须在迁移窗口完全关闭后进行，否则源库和目标库的增量数据会导致大量假阳性差异。建议在迁移完成后，先暂停所有写入流量，等待 30 秒（确保缓冲区清空），再执行 RDB 导出。如果业务不允许停写，则需记录导出时间戳，在对比时过滤掉时间戳之后的增量 Key。

3.4 三种校验方法对比总结

校验方法	耗时（1000 万 Key）	发现能力	适用阶段	工具依赖
Key 数量对比	1~2 分钟	仅发现 Key 总数差异	冒烟检查	redis-cli
--bigkeys 扫描	10~30 分钟	发现大 Key 分布差异、类型分布异常	快速验证	redis-cli
RDB 文件对比	1~4 小时	发现所有数据级差异（含 TTL、编码）	离线全量校验	redis-rdb-tools

  最佳实践：在迁移后的生产环境中，建议按以下节奏执行校验：

迁移完成后立即执行 Key 数量对比（1 分钟）。

确认数量一致后，执行 --bigkeys 扫描（15 分钟）。

扫描通过后，在业务低峰期执行 RDB 文件对比（2 小时）。

将校验结果记录到迁移报告中，作为验收依据。