直接改appendfsync为everysec、切高iops云盘、禁用无谓落盘动作，可缓解90%磁盘iops打满问题；因always模式每命令强制fsync导致高频小io，云盘实际吞吐不足标称值60%，而everysec将io压力降一个数量级且最多丢1秒数据。
直接改 appendfsync 和 save 配置、切到高IOPS云盘、禁用无谓的落盘动作，这三步做完，90% 的磁盘 IOPS 打满问题当场缓解。
为什么 appendfsync always 是 IOPS 杀手
它让 Redis 每写一条命令就调一次 fsync()，相当于把 10 万次小 IO 拆成 10 万次强制刷盘。云盘实际扛不住这种高频小写——哪怕标称 3000 IOPS，真实随机写吞吐也常打 6 折。日志里反复出现 Asynchronous AOF fsync is taking too long 就是典型信号。
改用 appendfsync everysec：主线程只追加到内存缓冲区，后台线程每秒统一刷一次盘。IO 压力骤降一个数量级，且数据最多丢失 1 秒，多数业务可接受。
- 别用
no：AOF 文件会越积越大，重写时反而引发更大 IO 波动 - 确认已开 AOF：
CONFIG GET appendonly必须返回"yes" - 混合持久化可叠加启用：
aof-use-rdb-preamble yes（Redis 4.0+），进一步压缩 AOF 体积
如何让 RDB 不再抢 IOPS
RDB 全量快照是连续大块写，一次 bgsave 可能吃掉几百 MB 磁盘带宽。若 save 触发太勤（比如默认 save 900 1），高写入场景下几乎每 15 分钟就来一次，IOPS 直接被钉死。
调大触发阈值是最安全的解法：save 300 50000 表示“5 分钟内至少 5 万个 key 变更才快照”，大幅削平 IO 峰值。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先查现状：
INFO stats | grep changes_since_last_save看当前变更数，再结合uptime_in_seconds推算平均速率 - 改完必须 reload：
CONFIG REWRITE或重启，CONFIG GET save要能看见新值 - 禁止写
save ""—— 旧版本可能误判为关闭持久化，导致数据裸奔
云盘 IOPS 不足时必须做的三件事
很多故障不是配置错，而是云盘本身扛不住。比如阿里云 ESSD PL0 默认仅 300 IOPS，而一次 RDB 写入就可能持续占用 80% 以上队列。
先用 iostat -x 1 看 %util 和 await：若 %util > 90% 且 await > 50ms，基本确定是云盘瓶颈。
- 把
dir明确指向高性能云盘分区（如/data/redis），绝不能和系统盘混用 - 升级云盘类型：ESSD PL1 起、AWS gp3 开启 Provisioned IOPS，别信“突发性能”
- 临时保命：
no-appendfsync-on-rewrite yes，避免 AOF 重写时和主线程 fsync 抢资源
容易被忽略的隐性磁盘消耗点
真正压垮磁盘的，往往不是主流程，而是残留文件、多份备份、日志堆积这些“看不见的债”。
temp-*.rdb、appendonly.aof.tmp、旧版 dump.rdb 文件，只要没被 Redis 主动 unlink，就会一直占空间。一旦发生 kill -9 或 OOM，这些文件极易卡住不删。
- 定期清理脚本必须外挂，别信 Redis 自身清理逻辑
- 检查残留：
ls -lh /var/lib/redis/*.rdb /var/lib/redis/appendonly.aof* - AOF 重写失败日志关键词：
Failed to rewrite the AOF或Can't open the temp AOF file
