Redis持久化优化：RDB与AOF策略调整指南

Redis持久化性能优化的核心在于避免主节点同时执行RDB快照和AOF重写引发的双重fork导致CPU与内存瞬时飙升、请求延迟倍增；推荐主节点仅启用AOF（appendonly yes）并设为everysec同步策略，关闭RDB，将快照任务交由从节点承担；AOF重写需协同调优auto-aof-rewrite-percentage（如70）、auto-aof-rewrite-min-size（如64mb）及no-appendfsync-on-rewrite yes，以压峰避频、减少IO争抢；RDB save策略须按业务写入特征动态调整，摒弃通用配置，优先利用低峰期手动触发；最后务必先排查used_memory_rss是否远超used_memory——若已触发swap，任何参数调优都将失效。

Redis主节点同时做RDB快照和AOF重写，会触发两次fork，CPU和内存瞬间飙高，请求延迟直接翻倍甚至超时——这不是配置没调好，是默认策略在高压下必然发生的资源争抢。

主节点要不要关持久化？看场景再决定

很多团队一看到save或appendonly yes拖慢服务，就急着全关。但关错地方反而埋雷：

• 如果业务能接受秒级数据丢失（比如纯缓存场景），主节点确实可以关RDB+关AOF：config set save "" + config set appendonly no
• 但如果用了redis-cli --rdb做离线备份，或依赖AOF做故障回放，关掉后就失去最后一道防线
• 更稳妥的做法是：主节点只开AOF（appendonly yes），但把appendfsync设为everysec；RDB完全交给从节点执行

怎么调AOF重写才不卡主线程？盯住两个关键阈值

AOF重写本身不阻塞，但重写过程中的fork和磁盘IO会抢资源。别只改auto-aof-rewrite-percentage，得配合auto-aof-rewrite-min-size一起压峰：

• auto-aof-rewrite-percentage 70：当前AOF文件比上次重写后大70%才触发——太低会频繁重写
• auto-aof-rewrite-min-size 64mb：哪怕涨了100%，只要AOF不到64MB也不重写——避免小文件反复折腾
• 顺手加个no-appendfsync-on-rewrite yes：重写期间暂停fsync，防止磁盘IO雪上加霜（前提是能容忍重写失败时最多丢失2秒数据）

RDB快照频率怎么设？别信“每5分钟一次”这种通用建议

save 900 1这种配置在低流量环境没问题，但一到写入高峰，900秒内只要有一个key变更就触发快照，等于每分钟都在fork：

• 先用info persistence看rdb_last_bgsave_time_sec和rdb_last_bgsave_status，确认是否真在频繁快照
• 生产环境建议改成save 300 10000（5分钟内至少1万个变更才快照），或干脆只保留save 3600 100000（1小时+10万变更）
• 如果业务有定时低峰（比如凌晨2点），可以用redis-cli bgsave手动触发，避开白天流量

真正卡顿往往不是因为“没调参数”，而是忘了检查used_memory_rss是否远大于used_memory——这说明系统已经在swap，此时调任何持久化参数都只是给火上浇油。

终于介绍完啦！小伙伴们，这篇关于《Redis持久化优化：RDB与AOF策略调整指南》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布数据库相关知识，快来关注吧！