Redis持久化磁盘IO飙升，RDB/AOF参数调优降低

Redis 持久化磁盘 IO 飙升，通常表现为 redis-cli --latency 延迟突然增大、INFO stats 里 rdb_bgsave_in_progress:1 长期不结束，或者用 iostat 看到 %util 被打满。
这是 RDB 快照或 AOF 重写频繁触发的典型表现。
本文按 定位问题 → 调整参数 → 验证效果 的顺序，带你一步步把持久化 IO 压下来。

先确认 IO 压力来自 Redis 还是系统

调优之前必须确认压力来源，避免白改配置。
登录服务器后依次执行三条命令：

iostat -x 1 3

看输出里 %util 是否持续接近 100%，同时观察哪个磁盘设备（如 vda 或 sda）最忙。
接着用 iotop -o 查看实际占用 IO 的进程，确认是不是 redis-server 在刷盘。
最后进入 Redis 执行：

redis-cli INFO persistence

重点看这三项：

• rdb_bgsave_in_progress：为 1 表示正在生成 RDB 快照
• aof_rewrite_in_progress：为 1 表示正在做 AOF 重写
• aof_last_bgrewrite_status：看上次重写是否成功

如果确认 Redis 刷盘期间系统 %util 明显升高，那就可以继续下面的调优。

调低 RDB 触发的频率和开销

RDB 默认配置是 save 3600 1、save 300 100、save 60 10000，意思是 60 秒内只要有 1 万次写操作就自动执行一次 bgsave。
对写入量大的业务来说，这个频率会让磁盘频繁被打满。

编辑 redis.conf，按实际写入量降低触发阈值：

save 3600 1
save 600 1000
save 300 10000

修改后重启 Redis 或执行 CONFIG REWRITE 让配置持久化。
注意：不要同时把三个 save 全注释掉，否则发生宕机时最多会丢最近的所有数据，除非你能接受。
关掉 RDB 后还想保留持久化能力，就继续调整 AOF。

如果确定保留 RDB，可改用一个独立磁盘或 SSD 存储 dump.rdb，把快照刷盘和业务读写分到不同设备，IO 抢占问题能立刻缓解。

AOF 参数调优：降低刷盘频率和重写干扰

AOF 默认 appendfsync everysec，对大多数场景已经够用。
如果 everysec 依然造成 IO 毛刺，可以改成 no，把刷盘时机交给操作系统，减少 Redis 主动 fsync 的次数：

appendfsync no

如果你的机器是 SSD 且备份压力不大，也可以继续用 everysec，但要看磁盘是否跟得上。
另外要确认 no-appendfsync-on-rewrite 是否已开启：

no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 200
auto-aof-rewrite-min-size 512mb

no-appendfsync-on-rewrite yes 会在 AOF 重写期间暂停 fsync，避免重写和正常写入同时抢磁盘 IO。auto-aof-rewrite-percentage 从默认 100 调到 200，意味着 AOF 文件比基准大 200% 时才触发重写，这样能减少重写次数。
压力大的实例建议把 auto-aof-rewrite-min-size 也调大一些，防止小文件频繁重写。

避坑说明：这两个改动别一起做

第一，appendfsync no 和 save 全部关闭不能同时用于生产环境，否则 Redis 崩溃会丢大量数据。
如果系统允许丢一部分数据，建议至少保留一种持久化。
第二，改完参数后观察一段时间，不要只盯 1 秒的监控。
AOF 重写期间会 fork 子进程并拷贝内存页，瞬时 IO 和 CPU 升高属于正常现象，不代表调优失败。
第三，如果磁盘是机械盘，调参只是治标，最终建议换 SSD 或给 Redis 单独挂一块数据盘。

验证调优效果

重启 Redis 后，用以下方式确认压力是否下降：

iostat -x 1 30

观察 %util 是否从接近 100% 回落到安全范围。
同时在业务写入高峰期执行：

redis-cli INFO stats | grep -E 'instantaneous_ops_per_sec|total_commands_processed'

确认写入吞吐没有明显下降。
最后再跑一遍 redis-cli INFO persistence，确保 rdb_bgsave_in_progress 和 aof_rewrite_in_progress 在空闲时都快速归零，说明持久化流程已经恢复正常。

如果你遇到的 IO 飙升发生在凌晨整点或定时任务时间点，还可以回顾是否和其他备份脚本、日志切割撞在一起，错开计划任务往往比继续压低 Redis 参数更有效。
对于负载很高、无法停机的实例，建议优先调整 AOF 重写触发阈值和刷盘策略，RDB 频率谨慎降低，避免影响恢复点目标。