主节点应禁用rdb、仅启用aof（appendonly yes）并设appendfsync为everysec；aof重写需协同配置auto-aof-rewrite-percentage（如70）、auto-aof-rewrite-min-size（如64mb）及no-appendfsync-on-rewrite yes；rdb快照宜按业务峰谷调整save策略，避免高频fork。
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一起压峰：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
-
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，此时调任何持久化参数都只是给火上浇油。
