彻底禁用 Redis 自动 RDB 快照需注释或清空 redis.conf 中所有 save 行，设置 appendonly no、rdb-aof-use-rdb-preamble no，并删除 dump.rdb 和 appendonly.aof 文件，否则仍可能触发默认策略或 AOF 写入导致磁盘 IO 上升。
RDB触发频率过高导致磁盘IO打满
频繁的 bgsave 会引发大量磁盘写入，尤其在机械盘或共享存储上，可能拖慢整个实例响应。这不是配置“错”，而是业务写入节奏和默认 save 策略不匹配。
常见现象：redis-cli info persistence 显示 rdb_last_bgsave_status:err，日志里反复出现 Failed to open .rdb file for writing 或 write(2) failed: No space left on device（即使磁盘没满，也可能是inode耗尽或内核写缓冲区阻塞）。
- 先检查实际写入压力：用
iotop -p $(pgrep redis)观察 Redis 进程的实时 IO 吞吐 - 临时禁用自动触发：注释掉 redis.conf 中所有
save行，改用人工调度bgsave（比如低峰期 cron 调用） - 若必须保留自动触发，把最激进的一条（如
save 60 10000）删掉，只留save 900 1和save 300 10—— 多数中小规模业务够用 - 确认
dir指向的是 SSD 路径，且该路径无其他高 IO 进程争抢
AOF everysec 模式下仍丢数据
启用 appendfsync everysec 后，理论上最多丢 1 秒数据，但实际遇到断电或 kernel panic 时，可能丢失远不止 1 秒——因为 Linux 的 page cache 刷盘不是严格按秒执行，everysec 只保证每秒调用一次 fsync()，而 write() 调用本身只是进内核 buffer。
关键点：Redis 进程崩溃（非系统宕机）时，everysec 是安全的；但主机硬关机、突然断电时，buffer 里未刷盘的 AOF 数据就丢了。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 不要误信 “everysec = 不丢数据”，它本质是性能与安全的折中
- 若业务真不能容忍任何丢失，必须切到
appendfsync always，但要接受写吞吐下降 3–5 倍（尤其小 key 高频写场景） - 更现实的做法：搭配
no-appendfsync-on-rewrite yes，避免 AOF 重写期间fsync被阻塞，否则重写时写延迟会陡增 - 注意：AOF 重写本身也会触发
bgsave类似的 fork 开销，如果内存 >20GB，建议关闭auto-aof-rewrite-percentage，改用人工bgrewriteaof控制时机
RDB压缩开启反而拖慢恢复速度
rdbcompression yes 默认启用 LZ4 压缩，能减小 RDB 文件体积，但解压恢复时需额外 CPU 时间。当 Redis 实例内存很大（比如 >32GB）、CPU 核心数少（
典型症状：Redis 启动后 INFO server 显示 loading:1，但 INFO stats 的 total_commands_processed 长时间不增加。
- 验证是否为压缩瓶颈：对比同一份 RDB 文件，分别用
rdbcompression yes和no启动，测加载耗时（redis-server --rdbfilename test.rdb --rdbcompression no） - 生产环境建议：SSD 存储 + 内存 ≤16GB → 开压缩；HDD 存储或内存 >32GB → 关闭压缩（
rdbcompression no） - 别忽略
rdbchecksum yes：校验开启会延长加载时间约 10%–15%，但能防止损坏 RDB 导致静默数据错误，除非你有 100% 信任备份链路，否则不建议关
混合持久化开启后 AOF 重写变慢
Redis 4.0+ 支持 aof-use-rdb-preamble yes，即 AOF 文件前半部分是 RDB 格式快照，后半部分是增量命令。这本意是加速加载，但重写时需先生成 RDB 片段再拼接命令，CPU 和内存开销比纯 AOF 重写更高。
现象：AOF 重写耗时从平时的 2 分钟飙升到 8 分钟以上，期间 used_memory_peak_human 突增 1.5 倍，甚至触发 OOM killer。
- 根本原因：重写过程要 fork 出子进程做 RDB 快照，同时主线程还在写入，内存 copy-on-write 放大了实际占用
- 紧急缓解：设
auto-aof-rewrite-min-size 512mb（而非默认 64mb），减少重写频次；并确保maxmemory预留至少 30% 内存余量 - 长期方案：如果业务写入模式稳定（如日增 2GB AOF），干脆关闭混合模式，用纯 AOF + 定期
bgrewriteaof手动控制 - 注意：混合模式下，
rdbchecksum对 AOF 文件无效，校验只作用于 RDB 片段部分
