Redis 不支持“分支结构控制下的多路快照遍历”，全量导出唯一合法方式是 SCAN 命令分批遍历内存键，配合 TYPE 判断类型后分别用 DUMP、LRANGE、ZRANGE、XRANGE 等命令导出对应数据。
直接说结论：redis 本身不提供“分支结构控制下的多路快照遍历”这种机制，也不存在官方支持的“多路快照”概念。所谓“多路快照”不是 redis 的功能特性，而是对 rdb 快照、aof 日志、主从同步等不同持久化/复制路径的误读或术语混淆。导出大容量 redis 字典（即所有键值对）的全量数据，核心在于安全、可控、不阻塞、不丢数据地读取内存状态，而非依赖虚构的“多路快照遍历”。
真正可行的全量导出路径只有两条
Redis 的全量数据始终只存在于内存中（RDB/AOF 是磁盘副本，非实时镜像）。要导出“本地内存字典”的全量键值对，必须主动扫描内存——而 Redis 提供的唯一合法方式是 SCAN 命令族，它替代了已废弃且危险的 KEYS 命令。
- SCAN 是唯一推荐的遍历方式：基于游标（cursor）分批迭代，不阻塞主线程，适合生产环境；每次返回一批 key（如 100–1000 个），通过游标推进直到返回 cursor=0 表示完成
- 不能用 KEYS *：在百万级 key 场景下会严重阻塞 Redis，导致超时、连接中断甚至服务不可用
- RDB 文件不是“快照遍历”，而是离线二进制镜像：dump.rdb 是 fork 子进程生成的内存快照，但它是静态文件，无法“遍历”，只能整体备份或用 redis-check-rdb 工具解析（不推荐用于常规导出）
导出流程：SCAN + TYPE + DUMP 组合（仅限支持类型）
由于 DUMP 命令不支持 List、Stream 等类型（仅支持 string/hash/set/zset/stream/module），所以不能对所有 key 统一 DUMP。必须先判断类型，再分策略导出：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- STEP 1：SCAN 获取全部 keyredis-cli --scan --pattern "*" | while read key; do ... done
- STEP 2：对每个 key 执行 TYPE 判断类型 若为 string/hash/set/zset/stream → 可安全 DUMP；若为 list → 改用 LRANGE 分页拉取
- STEP 3：按类型选择序列化方式 string → DUMP hash → HGETALL + JSON 序列化 list → LRANGE key start end（batch_size ≤ 5000） zset → ZRANGE key 0 -1 WITHSCORES stream → XRANGE key - + COUNT 1000（需循环游标）
为什么不能靠“多路快照”实现无损？
所谓“多路”常被误解为主从多个副本同步读取，但这无法解决根本问题：
- 主从复制是异步的，从节点数据必然滞后，读取从库无法保证“无损”（尤其秒杀场景最后几毫秒写入可能未同步）
- RDB 快照是某个时间点的静态切片，两次快照之间产生的写入不会被捕捉，不满足“全量实时”要求
- 没有机制能同时冻结主库所有 key 的状态并分多线程快照——Redis 单线程模型决定了它不支持并发内存快照遍历
生产级全量导出建议方案
兼顾速度、内存安全与数据一致性：
- 使用 redis-cli --scan 配合管道处理，避免一次性加载全部 key 到客户端内存
- 导出目标格式优先选 JSON Lines（每行一个 key 的完整结构），便于后续校验和恢复
- 开启 AOF + 混合持久化（aof-use-rdb-preamble yes），确保导出期间新写入仍可落盘
- 如需严格一致性，可在低峰期执行 BGSAVE + 立即停写（业务层配合）+ 读取 dump.rdb，但这是有损可用性的方案，慎用
