Redis持久化需权衡配置而非简单开关：RDB应禁用默认自动触发（如save 60 10000），改用低峰期定时bgsave；AOF推荐everysec策略；持久化文件须置于独立SSD分区，禁用swap以防fork失败。
单机 Redis 的持久化和性能不是非此即彼的选择，而是靠配置权衡出来的结果——关键不在“开不开”，而在“怎么开、开多细”。
RDB快照触发时机怎么设才不卡顿
RDB靠 bgsave 异步生成快照，但 fork 子进程本身会拷贝主进程页表，内存越大、fork 越慢，可能引发毫秒级延迟。尤其在大内存（>16GB）或高写入场景下，频繁触发会导致响应抖动。
- 避免用
save 60 10000这类“每60秒+1万次写就保存”的默认策略，它在流量高峰时极易误触发 - 生产环境建议关闭自动 RDB（注释掉所有
save行），改用定时任务 +redis-cli -a <password> bgsave</password>控制执行时间（比如凌晨低峰期） - 如果必须保留自动触发，至少改成
save 300 1（5分钟内有1次写就保存），只对极低频写入场景有效
AOF的appendfsync策略选哪个
appendfsync 是 AOF 性能与安全的开关，三个选项差异极大：
-
always：每次写都 fsync 到磁盘 → 数据最安全，但 QPS 直接跌 30%~50%，基本不用 -
everysec（默认）：每秒一次 fsync → 平衡点，最多丢 1 秒数据，实测对吞吐影响 -
no：由操作系统决定何时刷盘 → 性能最好，但宕机可能丢几十秒数据，仅限开发或日志类缓存
别盲目调成 always，除非你业务允许写入延迟飙升且能接受运维成本上升；everysec 是绝大多数单机场景的真实底线。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
混合持久化（RDB+AOF）要不要开
Redis 4.0+ 支持 aof-use-rdb-preamble yes，即 AOF 文件前半段是 RDB 二进制快照，后半段是增量命令。它不是“两者叠加”，而是用 RDB 加速加载、用 AOF 保最后几秒数据。
- 开启后，Redis 启动时先加载 RDB 部分（快），再重放 AOF 尾部（准），比纯 AOF 恢复快 3~5 倍
- 但会略微增大 AOF 文件体积（RDB 部分占空间），且
bgrewriteaof期间内存占用更高 - 单机部署建议开启，尤其当数据量 >1GB 或启动恢复时间敏感时
持久化文件放在哪块磁盘上
很多人忽略这点：RDB 和 AOF 写入路径直接影响性能。即使开了 everysec，如果磁盘是机械盘或与数据库共用同一块 SSD，IO 竞争会让延迟翻倍。
-
dir参数必须指向独立 SSD 分区（比如/data/redis），不能是系统盘或日志盘 - 禁用
vm.swappiness = 0，防止 Linux 把 Redis 内存页 swap 出去，导致 fork 失败或卡死 - 如果用云服务器，确认该磁盘是“高 IO 专用型”而非“通用型”，后者在突发写入时 IOPS 会限速
真正容易被忽略的是磁盘隔离——哪怕配置全对，只要 RDB 文件和 MySQL 的 ibdata1 在同一块盘上，高峰期的 IO 争抢就会让 Redis 持久化变慢、主线程阻塞，这种问题查监控都难定位。
