Redis启动时通过CRC64校验判断RDB损坏：读取末尾8字节校验值并与数据体重新计算值比对，不一致则报“Wrong RDB checksum. Aborting now.”并退出。
Redis启动时如何判断RDB文件损坏
Redis在加载dump.rdb时，如果启用了rdbchecksum yes（默认开启），会先读取文件末尾8字节的CRC64校验值，再对前面全部数据体重新计算一次CRC64，两者不一致就直接报错退出。错误信息是：Wrong RDB checksum. Aborting now.
这个校验只在Redis服务启动加载RDB时触发，运行中写入RDB（如SAVE或BGSAVE）也会写入校验值，但不会主动验证自身——它只信自己刚算出来的那个值。
- 没启用
rdbchecksum时，即使RDB被截断或填了乱码，Redis也可能静默加载部分数据，导致键丢失或类型错乱，排查极难 - 校验失败后Redis不会尝试降级加载，也不会输出损坏位置，只打印错误并退出
- 注意：AOF文件不走这套CRC64机制，它的完整性靠
aof-rewrite过程中的校验和重写保证
rdbchecksum配置开关的实际影响
rdbchecksum默认为yes，设为no可跳过CRC64计算。关闭后，SAVE/BGSAVE生成的RDB末尾不再写校验值，加载时也不校验——性能提升微乎其微（现代CPU上CRC64计算开销几乎可忽略），但彻底放弃最后一道完整性防线。
- 仅在极老内核或嵌入式环境且确认磁盘/内存绝对可靠时才考虑关掉
- 生产环境严禁关闭，尤其使用机械盘、网络存储或容器挂载卷时，位翻转或IO中断风险真实存在
- 配置位置在
redis.conf中，改完需重启Redis才生效；在线用CONFIG SET rdbchecksum no无效，该配置项不支持运行时修改
手动验证RDB文件是否完整（离线场景）
当Redis因校验失败无法启动，又需要确认是不是RDB真坏了，可以用redis-check-rdb工具离线检查。它不依赖Redis进程，直接解析文件结构并验证CRC64。
命令示例：redis-check-rdb /var/lib/redis/dump.rdb
- 输出
Checksum OK表示末尾CRC64匹配，但不保证RDB逻辑正确（比如压缩头损坏、嵌套结构错位仍可能加载失败） - 输出
Checksum error说明CRC64不一致，文件大概率被篡改或传输损坏 - 若提示
Invalid RDB magic string，通常是文件开头3字节不是REDIS，可能是空文件、被覆盖或根本不是RDB格式 - 该工具随Redis源码编译产出，Docker镜像里一般自带，系统包安装的Redis通常也包含
RDB校验失效的典型坑
CRC64校验本身很可靠，但容易被绕过或误判。最常见的是文件未写完就被强制读取——比如BGSAVE还在执行，另一个进程就去拷贝dump.rdb，此时文件末尾CRC64字段为空或随机值，校验必然失败。
- 不要在
BGSAVE进行中复制RDB文件；应监听save事件或检查INFO persistence里的rdb_bgsave_in_progress:0 - 用
cp --reflink=always或rsync --inplace等可能破坏文件原子性的命令复制RDB，会导致中间状态暴露 - 某些云存储挂载方式（如NFSv3）不保证write ordering，可能使CRC64先落盘而数据体滞后，造成校验失败
- 用
dd截断RDB文件后手动补8字节垃圾值，能让CRC64“通过”，但Redis加载时仍会因结构解析失败崩溃——校验只是第一关，不是万能锁
真正关键的不是“有没有校验”，而是整个RDB生命周期里，写入、传输、备份、恢复每个环节是否保持原子性。CRC64只负责把关最后一环，前面任何一步出问题，它都救不了。
