Redis 本身不写满磁盘，但 RDB/AOF 持久化、日志堆积及系统配置不当（如 overcommit_memory=0、swappiness 过高）会引发 fork 失败、双写放大和磁盘耗尽，导致 OOM 或服务拒绝。
Redis 本身不会导致磁盘写满——但它的持久化行为（RDB/AOF）、日志、以及系统级副作用，确实可能悄悄填满磁盘，最终让 Redis 进程被 OOM Killer 杀掉，或因 fork 失败直接拒绝服务。
为什么 Redis 会“连累”磁盘写满？
很多人以为 Redis 是纯内存数据库，磁盘就没事。错在三个关键点：
- RDB 快照生成时，
fork子进程会复制父进程页表，若内存大（比如 16GB），即使没写新数据，临时占用的虚拟内存也可能触发/proc/sys/vm/overcommit_memory=0策略下的 fork 失败，报错Can't save in background: fork: Cannot allocate memory； - AOF 重写（
bgrewriteaof）同样依赖fork，且重写期间新命令持续追加到老 AOF 文件，造成“双写放大”； - Redis 自身不管理磁盘，但
/var/log（systemd 日志）、/var/lib/redis（dump.rdb、appendonly.aof、AOF 重写中的 temp-rewriteaof-* 文件）都在同一块磁盘上，日志打爆 + RDB 挤占 + 系统缓存回收滞后，三者叠加极易触顶。
配置操作系统级磁盘配额（ext4/xfs 场景）
别只盯着 Redis 配置，得先给磁盘“上锁”。以 Redis 数据目录 /var/lib/redis 所在分区为例：
- 确认文件系统支持配额：
tune2fs -l /dev/sda1 | grep "Filesystem features"（需含quota）； - 启用用户配额：
tune2fs -uq /dev/sda1，然后在/etc/fstab对应行末尾加usrquota，再mount -o remount /var/lib/redis； - 初始化配额数据库：
quotacheck -cug /var/lib/redis； - 给 redis 用户设硬限制（比如 5GB）：
setquota -u redis 0 5242880 0 0 /var/lib/redis（单位是 KB）； - 启用：
quotaon /var/lib/redis； - 验证：
quota -u redis，看Block limits是否生效。
⚠️ 注意：如果 Redis 用 systemd 启动且启用了 DynamicUser=yes，它运行在随机 UID 下，此时必须改用 groupquota 或禁用 DynamicUser，否则配额不生效。
监控告警必须覆盖的 3 个真实指标
光配额不够，得提前预警。以下指标不能只看“使用率”，要盯住变化速率和绝对值：
-
df -B1 /var/lib/redis | awk 'NR==2 {print $5}' | sed 's/%//'—— 但仅此不够，得配合inotifywait -m -e create,delete_self /var/lib/redis监控临时文件突增； - AOF 当前大小：
stat -c "%s" /var/lib/redis/appendonly.aof 2>/dev/null || echo 0，重点看 24 小时内是否增长 >30%（说明写入激增或重写卡住）； - RDB 最后修改时间与大小：
find /var/lib/redis -name "dump.rdb" -printf "%T@ %s\n" | sort -n | tail -1，若大小暴涨 + 时间接近现在，大概率是save阻塞了主线程。
告警阈值建议：根分区使用率 >85% 触发 P2，>92% 触发 P1；AOF 文件单日增长 >2GB 且无重写完成日志，立即检查 redis-cli info persistence | grep aof_rewrite。
Redis 层面最该关掉的两个“磁盘黑洞”
很多崩溃其实源于 Redis 自己的配置惯性，而不是磁盘本身小：
- 关掉自动 AOF 重写：
CONFIG SET auto-aof-rewrite-percentage 0，改用手动触发（redis-cli bgrewriteaof），并确保操作前df -h /var/lib/redis有 ≥2 倍当前 AOF 的空闲空间； - 禁用 RDB 快照（除非你真需要）：
CONFIG SET save ""，把save 900 1这类配置从redis.conf彻底删掉——RDB 文件无法增量，每次都是全量复制，对磁盘 I/O 和 fork 压力最大； - 如果必须持久化，优先选 AOF +
appendfsync everysec，并定期用redis-cli BGREWRITEAOF清理，比 RDB 更可控。
真正容易被忽略的是：vm.swappiness=1 要配，否则 Linux 在内存压力下疯狂 swap，反而加剧磁盘 IO，掩盖真实瓶颈；还有 /proc/sys/vm/overcommit_memory 推荐设为 1（允许 overcommit），不然 fork 就是定时炸弹。
