Redis不直接解决磁盘打满问题，需挂载独立SSD并配置空间保护机制；默认配置下因持久化写盘易触发“No space left on device”，导致AOF重写与RDB保存失败，甚至静默停服。
Redis 本身不直接解决磁盘打满问题——它只会忠实写入，直到 write 系统调用失败；真正起作用的是你提前把 appendonly.aof 和 dump.rdb 所在目录挂载到独立高速 SSD，并配好空间保护机制。
为什么默认配置下 Redis 会“帮倒忙”
Redis 持久化（AOF 重写、RDB 快照）是全量或增量写盘操作，一旦系统盘（通常是根分区 / 或 /var）剩余空间不足 10%，fork() 后的子进程在写临时文件时极易触发 write: No space left on device 错误。此时：
– AOF 重写失败，日志持续增长
– RDB 保存失败，lastsave 时间停滞
– 更糟的是，部分版本 Redis 会静默停止响应，而 INFO persistence 里 aof_rewrite_in_progress 可能仍为 1，掩盖真实状态
必须挂载独立 SSD 的三个硬性前提
- SSD 必须格式化为
ext4或xfs（避免btrfs的 CoW 在 AOF 重写时引发空间突增） - 挂载选项必须含
noatime,nodiratime,commit=60（减少元数据刷盘频率） - Redis 数据目录（
dir配置项）必须指向该挂载点根目录，且不能是子目录软链（否则rename(2)原子替换.aof.temp时跨文件系统会失败）
Redis 配置中真正影响磁盘安全的 4 个参数
仅靠换硬盘不够，这些配置决定你能否抢在打满前刹车：
-
auto-aof-rewrite-percentage 100：设太低（如 50）会导致小增量频繁重写，放大写放大；建议结合auto-aof-rewrite-min-size 64mb使用，避免空库反复重写 -
stop-writes-on-bgsave-error yes：必须开启——RDB 失败时立刻拒绝写入，比等 AOF 也崩掉更可控 -
maxmemory-policy noeviction：如果启用了内存淘汰策略（如allkeys-lru），持久化失败后仍接受写入，会加速填满磁盘；生产环境建议设为noeviction并靠监控+告警兜底 -
notify-keyspace-events "Ex"：若监听过期事件，注意EXPIRE触发的键删除不会立即释放磁盘空间（AOF 还得记录DEL），大 Key 过期潮可能引发 AOF 突增
光挂 SSD 不够，还得加一层空间熔断
Linux 内核无法让 Redis “感知”剩余空间，所以必须在外围拦截：
- 用
df -B1 /data/redis定期检查（建议 30s 一次），剩余或时触发：
– 自动redis-cli config set stop-writes-on-bgsave-error yes
– 发送钉钉/企业微信告警，附带redis-cli info memory | grep used_memory和ls -lh /data/redis/*.aof结果 - 禁止任何 cron job 向该挂载点写日志（比如把
/var/log/redis软链过去是高危操作） - SSD 挂载点根目录下保留至少 10% 空间给 ext4 的 reserved blocks（用
tune2fs -m 10 /dev/nvme0n1p1设置），避免 root 用户也无法写入
最常被忽略的一点：Redis 启动时不会校验 dir 目录剩余空间，它只检查可写权限。等第一次 BGSAVE 或 AOF 重写开始，才暴露问题——所以空间监控必须独立于 Redis 进程运行，且阈值要比实际报错点留足缓冲。
