rdb+aof混合策略不可行，必须禁用aof、只用rdb+外部增量备份协同：因千万级key下aof重写会导致长时间阻塞和磁盘爆满，而bgsave在大内存场景fork延迟高、备份不同步、恢复不一致，故需rdb全量+redis-cli--scan增量导出，并严格管控备份命名、元数据与恢复流程。
RDB + AOF 混合策略不可行，必须禁用 AOF、只用 RDB + 外部增量备份协同。千万级 Key 场景下，AOF 重写会触发长时间阻塞和磁盘爆满，RDB 文件虽大但可控，关键是备份过程不能干扰集群可用性。
为什么不能直接用 bgsave 做集群全量备份
单节点 bgsave 看似无阻塞，但在千万级 Key 下：子进程 fork 耗时可能达秒级（尤其内存 >32GB），期间主进程暂停处理请求；生成的 dump.rdb 文件常超 10GB，拷贝到远程存储需分钟级，期间若节点故障，备份就中断且不可续传；集群多分片时，各节点 bgsave 时间不同步，无法保证全局一致性快照。
- 实际观测中，Key 数量超 800 万、平均 value 长度 512B 时，
bgsavefork 阶段延迟常突破 1.2s（Redis 日志里会出现fork time: 1247ms） - 集群恢复时若依赖多个不同时间点的 RDB，数据会严重不一致——比如订单已扣减但库存未更新
- 不要在运行中的生产集群上循环执行
redis-cli -h $node bgsave，这是典型“看似自动、实则灾难”的做法
推荐方案：RDB 全量 + redis-cli --scan 增量导出
核心是把“备份”拆成两个阶段：固定周期的 RDB 全量（如每日凌晨），叠加高频轻量的 key 级增量（如每 5 分钟）。后者不依赖持久化机制，而是靠 Redis 原生命令实时捞取变更。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 全量层：每天一次
bgsave，但必须配合CONFIG SET save ""临时关闭自动 RDB，避免与手动备份冲突；备份后立即将dump.rdb用rsync --partial --progress推送到对象存储，启用断点续传 - 增量层：用
redis-cli -h $node --scan --pattern "myapp:*" | xargs -L 1000 redis-cli -h $node migrate --replace导出最近变更的 key（注意：migrate 需目标实例在线，更适合迁移而非备份；更稳妥的是redis-cli --scan+get/hgetall批量读取后序列化为 JSON 行格式存 S3） - 关键参数：扫描时加
--cluster-yes（若用 redis-cli 6.2+ 连集群）、--scan默认游标步长是 10，千万级建议设为--scan 10000减少往返次数
恢复时必须跳过 AOF 自动加载
千万级数据恢复最常踩的坑：重启前忘了关 AOF，导致 Redis 启动卡死在 Reading appendonly.aof 阶段，甚至因 OOM 被系统 kill。AOF 文件在高频写入下极易膨胀到远超 RDB 的体积。
- 恢复流程严格按顺序：停服务 → 删除
appendonly.aof→ 替换dump.rdb→ 修改配置文件确保appendonly no且save ""→ 启动 - 如果必须保留 AOF，只能先用
redis-check-aof --fix appendonly.aof修复再加载，但千万级下该命令本身可能跑数小时，不可控 - 集群恢复要逐个节点操作，切勿并行重启；优先恢复 master，等其状态为
ok后再启动 slave，否则 slave 会尝试同步一个不存在的 offset
备份文件命名与元数据必须带分片标识
集群环境下，dump.rdb 文件本身不包含 slot 信息，同一份备份无法区分是哪个分片的数据。恢复错 slot 就等于写坏整个集群。
- 备份脚本中强制重命名：例如节点运行在 192.168.10.5:7001（负责 slot 0-5460），备份后文件名应为
redis_7001_slot_0-5460_202609030200.rdb - 配套生成
.meta.json记录：{"host":"192.168.10.5","port":7001,"slots":"0-5460","redis_version":"7.2.5","rdb_checksum":"sha256:abc123..."} - 别依赖
CONFIG GET dir的输出路径——Docker 或 systemd 环境下它可能返回/data，但实际挂载点是/mnt/redis-data，务必用readlink -f $(redis-cli config get dir | awk '{print $2}')获取真实路径
真正难的不是备份动作本身，而是验证备份可恢复。千万级场景下，每次全量备份后必须用空实例做一次完整 restore 流程，并用 redis-cli --scan 对比 key count 和随机采样 value，这步不能省，也不能只测单节点。
