Redis RDB 不支持并行拉取切片，因其为单文件顺序写入二进制快照，无分片格式与元数据索引；并行只能在实例粒度实现，即多 master 同时 BGSAVE。

Redis RDB 全量备份为什么不能直接并行拉取切片

Redis 的 RDB 文件本身是单文件、顺序写入的二进制快照，不支持“天然分片”。所谓“并行拉取 RDB 切片”，本质是伪需求——RDB 没有切片格式，也没有元数据索引告诉你哪段字节对应哪些 key。强行按字节切分再拼接，会导致校验失败、解析崩溃或数据丢失。

真正可行的路径只有一条：让多个 Redis 实例（或分片集群）各自生成独立 RDB，再并行传输。也就是说，“并行”必须发生在实例粒度，而非文件粒度。

• SAVE 或 BGSAVE 总是生成完整快照，无法指定 key 范围或 hash slot 范围
• 单实例开启 RDB 时，磁盘 I/O 和 fork() 开销会随数据量陡增，10GB+ 数据可能卡住主进程数秒
• 即使你用 redis-cli --rdb 流式拉取，它拿到的仍是完整流，无法中途截断或跳过某段

分片集群下如何安全触发多实例并行 BGSAVE

如果你用的是 Redis Cluster 或 Codis/Proxy 类架构，每个 master 节点负责一部分 slot，这时可以对所有 master 同时发 BGSAVE，实现逻辑上的“并行备份”。但要注意节点间状态不同步、磁盘空间竞争和时间窗口漂移问题。

• 先用 redis-cli -c -h {host} -p {port} cluster nodes 获取全部 master 地址，过滤出 master 角色且无 fail 标记的节点
• 避免用 SAVE：它会阻塞整个实例，哪怕只差一个节点卡住，就破坏“并行”意义
• 检查各节点 dir 配置是否指向本地高速盘（如 NVMe），而非共享网络存储，否则并发写入会打满 IO
• 加 timeout 控制单个 BGSAVE 最大耗时，例如 redis-cli -h x -p y config set timeout 60，防止异常 hang 住

RDB 文件传输阶段的性能瓶颈与绕过方式

备份完成后，并行 scp/rsync 大 RDB 文件看似合理，但实际常被低估的是 TCP 连接建立开销、SSH 加密负载、以及接收端磁盘顺序写能力。100 个 2GB 文件并发拉取，可能比串行还慢。

• 用 rsync --partial --inplace 替代 scp，支持断点续传且减少内存拷贝
• 禁用 SSH 压缩（-o Compression=no），CPU 往往比带宽更先成为瓶颈
• 接收端用 ionice -c 3 降低写入优先级，避免影响其他服务
• 如果备份目标是对象存储（如 S3），直接用 aws s3 cp --sse AES256 绕过本地中转，省掉落地磁盘这一步

验证 RDB 完整性不能只靠 redis-check-rdb

redis-check-rdb 只校验文件结构合法性，不验证 key 数量、过期时间、value 内容是否与源一致。一次看似成功的备份，可能漏掉最后几秒的写入，或因 fork 失败导致 RDB 实际为空。

• 备份前记录源实例的 info stats 中 total_commands_processed 和 instantaneous_ops_per_second
• 备份后立刻在目标端用 redis-server --test-memory 100 快速加载测试（不启动服务），确认能解析
• 抽样比对：从源随机选 100 个 key（用 scan + randomkey），检查其 ttl、type、strlen 是否与 RDB 加载后的实例一致
• 注意 RDB 不保存 client 输出缓冲区、复制偏移量等运行时状态，这些不属于“数据一致性”范畴，别拿它们当校验依据

最麻烦的地方在于：RDB 生成时刻是模糊的——BGSAVE fork 的瞬间，子进程看到的内存快照和父进程下一毫秒的写入之间存在不可控 gap。想逼近强一致，只能上 AOF + RDB 混合策略，或者接受几秒内的最终一致性。