必须用 SCAN + TYPE 过滤出纯 String key 再 GET:SCAN 避免阻塞,TYPE 确认类型为 "string" 后才执行 GET,禁用 KEYS;导出时注意 value 编码、换行符处理及内存控制。
直接导出全部 String 类型数据,不能只靠 GET 或 KEYS 简单拼凑——因为 KEYS 会阻塞 Redis,且返回的 key 混杂所有类型;而 GET 对非 String key 会报错 WRONGTYPE Operation against a key holding the wrong kind of value。必须先过滤、再取值。
这是最安全、生产环境唯一推荐的方式。SCAN 避免阻塞,TYPE 命令逐个确认类型,只对 string 类型执行 GET。
SCAN 游标需循环调用,每次带 count=1000 参数提升效率TYPE key,响应为 "string" 才继续 GET
HSET 再 SET)r.type(key).decode() == "string" 是必要判断,跳过这步会导致脚本中断KEYS * 在数据量 >10 万时极易触发 Redis 主线程卡顿,集群环境下还可能被禁用(redis.conf 中 rename-command KEYS "")。即使你后续加了 TYPE 判断,也已经把风险前置了。
redis-cli KEYS "*" | xargs -I{} redis-cli TYPE {} | grep string -q && redis-cli GET {} —— 多次连接开销大,且 KEYS 本身已违规SCAN 0 MATCH * COUNT 1000 起手,游标推进到 "0" 结束KEYS,但放行 SCAN,这点要提前验证取决于下游用途。纯文本(key:value)适合快速人工核对或导入其他 KV 存储;JSON 更利于程序解析,但要注意 GET 返回的 value 是字节串,需 decode,且空值(None)和二进制内容需额外处理。
f.write(f"{key.decode()}:{value.decode() if value else ''}n") 即可repr(value) 比 decode() 更稳妥,避免文件损坏json.dump() 全量数据——内存占用陡增,100 万 key 可能吃掉 2GB+ RAMtime.sleep(0.001)(每千条一次),防客户端缓冲区溢出真正麻烦的不是“怎么取”,而是“怎么不崩”。SCAN 的游标管理、TYPE 的响应判等、value 的编码容错——漏掉任意一环,脚本在半夜跑一半就挂,而你收到告警时,Redis 已经又写入了新数据。