save配置在高频写入时更危险，因其触发条件（如save 60 10000）易导致fork子进程过于密集，64gb内存机器单次fork可能阻塞主线程100ms+，引发分钟级延迟尖峰；应禁用save或大幅提高阈值，并启用混合持久化、appendfsync everysec及i/o隔离。
高频读写场景下，Redis 的持久化压力主要来自 RDB fork() 阻塞和 AOF fsync() I/O 竞争。直接关掉持久化最省事，但不可接受；真正可行的解法是「用混合持久化 + 调整同步节奏 + 隔离 I/O 资源」，而不是在 RDB 和 AOF 之间二选一。
为什么 save 配置在高频写入时反而更危险？
RDB 的 save 触发条件（如 save 60 10000）在高频写场景下极易被频繁触发，导致 fork() 子进程过于密集。64GB 内存机器上一次 fork() 可能卡主线程 100ms+，而每分钟触发多次，等于每分钟主动制造多次延迟尖峰。
- 高频写入下，
save建议完全禁用：把配置项清空为save "" - 改用
bgrewriteaof或定时redis-cli --rdb手动快照，把控制权收回来 - 如果必须保留自动 RDB，至少把阈值拉高到
save 300 100000以上，避免秒级抖动
appendfsync everysec 是高频场景下的底线选择
appendfsync always 在万级 QPS 下会把磁盘 I/O 打满，延迟飙升；appendfsync no 依赖操作系统刷盘，宕机可能丢数分钟数据。只有 everysec 在「最多丢 1 秒数据」和「I/O 压力可控」之间取得实际可用的平衡。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 确认磁盘不是共享盘（比如和 MySQL 共用一块 SATA 盘），否则
everysec也会被拖慢 - 观察
redis-cli info persistence中的aof_delayed_fsync，持续 > 0 表示 fsync 被排队，说明磁盘已成瓶颈 - 不要调高
aof-rewrite-incremental-fsync，它在高写入下反而增加小 I/O 次数，加重压力
混合持久化（aof-use-rdb-preamble yes）不是可选项，是必选项
Redis 4.0+ 的混合模式让 AOF 文件前半段是 RDB 二进制快照，后半段是增量命令。重启时加载速度接近纯 RDB，数据安全性等同 AOF —— 这对高频读写服务意味着「恢复时间不随写入量线性增长」。
- 必须开启：
aof-use-rdb-preamble yes，且确保appendonly yes - AOF 重写（
bgrewriteaof）仍会发生，但它现在生成的是「RDB 快照 + 新增命令」，比纯 AOF 重写快得多、I/O 少得多 - 注意重写期间的内存占用：子进程会 copy-on-write，若写入突增，可能触发系统 OOM Killer
真正容易被忽略的点是：混合持久化生效的前提是 AOF 文件本身不能损坏。高频写入下，如果磁盘写满或突然断电，AOF 文件末尾可能截断，导致 Redis 启动失败。所以除了配置，还得配好磁盘监控（如 df -h /var/lib/redis 告警）和日志轮转（auto-aof-rewrite-percentage 配合 auto-aof-rewrite-min-size 防止无限膨胀）。
