RDB快照应按业务写入节奏配置：高QPS场景推荐save 30 5000，波峰场景叠加save 5 1000；需禁用THP防fork延迟；混合持久化仅在AOF超500MB且启动慢时启用。

Redis RDB快照触发条件怎么配才不丢数据又不卡写入

RDB快照不是越频繁越好，也不是越少越安全——关键看业务写入节奏和容忍丢失的窗口。默认的 save 900 1（15分钟至少1个key变更）在高写入场景下基本失效，而改成 save 60 10000 又可能在流量高峰时阻塞主线程。

• 用 CONFIG GET save 查当前规则，别只看配置文件，运行时可能被动态改过
• 多个 save 规则是“或”关系，满足任一即触发，不是叠加生效
• 写入突增时，RDB fork子进程会复制整个内存页表，若实例 > 4GB 且启用了透明大页（THP），fork() 延迟可能飙到秒级，直接拖慢写入 —— 必须关掉 /sys/kernel/mm/transparent_hugepage/enabled
• 建议按业务峰值QPS预估：每秒写入 ≥ 5k key，至少配一条 save 30 5000；若写入有明显波峰（如整点报表生成），再加一条 save 5 1000 应对短时爆发

混合持久化（aof-use-rdb-preamble）开不开？什么场景真有用

开启 aof-use-rdb-preamble yes 后，AOF重写时会先写一个RDB格式的头部，再接增量命令。它不降低AOF体积，但能显著缩短 Redis 启动时的AOF加载时间 —— 尤其当AOF文件超1GB、命令历史复杂（大量 lpush/hset 混合）时。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 仅在同时开启AOF（appendonly yes）且AOF文件常超500MB时启用，小实例纯RDB更轻量
• 重写期间内存占用会临时增加约1.2倍（RDB头 + AOF增量缓冲），若内存余量
• Redis 7.0+ 默认开启，但老版本需手动配；注意升级后检查 CONFIG GET aof-use-rdb-preamble 是否被覆盖

save命令阻塞主线程？用bgsave还是schedule更可控

save 是同步操作，绝对不能在生产环境调；bgsave 虽异步，但每次仍要 fork，高频调用照样引发延迟抖动。真正可控的方式是交由外部调度器驱动。

• 禁用所有自动 save 规则（设为 save ""），完全靠外部定时任务触发 bgsave
• 用 redis-cli -a <password> BGSAVE</password> 配合 cron，但要注意：若上一次 bgsave 还没结束，新请求会被拒绝，返回 ERR Background save already in progress
• 更稳妥的做法是加锁检测：先 INFO Persistence 查 rdb_bgsave_in_progress:0，为0再执行；避免脚本并发冲突
• 别用 SCHEDULE 类关键词幻想Redis内置调度——它没有，得自己管

从RDB恢复时，如何确认快照没被写入洪峰截断

RDB文件末尾必须是 REDIS 魔数 + 有效校验和，但写入未完成时可能只落盘了前半部分，导致 redis-server 启动报 Wrong RDB checksum 或静默失败。

• 每次 bgsave 完成后，用 redis-cli INFO Persistence 核对 rdb_last_bgsave_status:ok 和 rdb_last_bgsave_time 时间戳
• 用 sha256sum 对比前后两次快照，若大小接近但哈希不同，大概率是截断（正常增量写入不会让RDB体积突变）
• 把RDB文件放在独立磁盘分区，避免和其他日志争IO；SSD上也要留意 vm.dirty_ratio，过高会导致内核延迟刷盘，加剧截断风险

实际部署时，最常被跳过的其实是磁盘空间水位监控——rdb_last_bgsave_size 突增2倍以上，往往意味着业务数据结构失控，而不是持久化参数没调好。