bgsave或bgrewriteaof使用temp-*.rdb和appendonly.aof.tmp临时文件，是为了通过原子rename保证数据一致性；但异常中断（如磁盘满、kill -9、OOM）会导致临时文件残留，而Redis主进程不负责跨重启清理，需运维脚本定期清理。
为什么bgsave或bgrewriteaof会留下temp-*.rdb和appendonly.aof.tmp
Redis在执行 bgsave 或 bgrewriteaof 时，不会直接覆盖原文件，而是先写入临时文件（如 temp-12345.rdb 或 appendonly.aof.tmp），等写入完成、校验通过后，再原子性地 rename 替换。这个设计保证了数据一致性，但也埋下了清理隐患：只要过程没走完，临时文件就卡在那里。
常见中断场景包括：
– 磁盘空间不足导致写入失败
– kill -9 强杀进程，子进程来不及清理
– 内核OOM Killer干掉子进程
– 高负载下 fork 超时或失败，但临时文件已创建
此时 Redis 主进程不负责兜底清理——它只管“当前活跃文件”，不管“半途而废的临时文件”。
如何快速识别残留的临时文件
别等磁盘报警才查。用这两条命令直接定位：
-
ls -lh /var/lib/redis/*.rdb /var/lib/redis/appendonly.aof*—— 看有没有temp-*.rdb或*.tmp文件 -
find /var/lib/redis -name "temp-*.rdb" -mmin +60—— 找出存在超 1 小时的临时 RDB（正常应在秒级内消失）
注意：appendonly.aof.tmp 一旦存在，说明 AOF 重写中途失败；若同时存在多个 temp-*.rdb，大概率是频繁触发 save 但又反复失败。
为什么Redis自身不自动删这些文件
这不是疏忽，而是设计取舍：
- Redis 启动时不扫描目录、不清理旧临时文件——避免启动慢、避免误删（比如你手动 cp 了一个 temp-xxx.rdb 做调试）
- 它依赖操作系统语义：临时文件本应由创建者销毁；异常退出后，交由运维或外部脚本兜底
- 如果让 Redis 主进程在每次启动时遍历并删所有
temp-*.rdb，可能误伤正在被其他实例使用的文件（多实例共用目录时）
换句话说：Redis 把“谁创建、谁清理”的契约，严格限定在单次 fork 子进程生命周期内。跨进程、跨重启的清理，它不认。
生产环境必须加的归档与清理脚本
靠人工巡检不现实。建议用 cron 每 5 分钟跑一次清理脚本，原则就一条：只留最近 1 个有效临时文件，其余全删。
示例脚本片段（/usr/local/bin/redis-cleanup.sh）：
#!/bin/bash
REDIS_DATA_DIR="/var/lib/redis"
# 删除超过 1 小时的 temp RDB
find "$REDIS_DATA_DIR" -name "temp-*.rdb" -mmin +60 -delete
# 删除孤立的 .tmp AOF（且非当前正在写的）
find "$REDIS_DATA_DIR" -name "appendonly.aof.tmp" -mmin +30 -delete
# 可选：压缩 7 天前的旧 RDB 归档（保留恢复窗口）
find "$REDIS_DATA_DIR" -name "*.rdb" -mtime +7 -exec gzip {} \;关键点：
– 不用 rm -f 直接删所有 temp-*.rdb，加 -mmin +60 避免误删刚生成的合法临时文件
– AOF 的 .tmp 文件超过 30 分钟还没完成，基本可判定失败
– 归档比直接删更稳妥，万一删错还能解压救回来
最容易被忽略的是：临时文件残留本身不是故障，而是故障的副产品。真正要盯住的，是日志里反复出现的 Failed to rewrite the AOF 或 Can't open the temp AOF file —— 那才是根因。
