必须先启用AOF（appendonly yes），再设置aof-use-rdb-preamble yes（Redis 4.0+），重启或CONFIG REWRITE生效；混合模式仅在bgrewriteaof触发时将RDB二进制头与AOF命令尾合并，提升加载速度并保障数据完整性。
怎么开启混合持久化：必须先开AOF，再改开关
混合持久化不是独立功能，而是AOF重写时的“增强模式”。aof-use-rdb-preamble 默认是 no，直接打开它不会生效——前提是 appendonly yes 已启用，否则Redis压根不写AOF文件，更谈不上在重写时嵌入RDB格式。
- 先确认AOF已开启：
appendonly yes，并指定appendfilename "appendonly.aof" - 再设置：
aof-use-rdb-preamble yes（Redis 4.0+ 才识别） - 重启或执行
CONFIG REWRITE让配置落地；用CONFIG GET aof-use-rdb-preamble验证返回"yes" - 注意：如果之前已有AOF文件，混合模式只会在下一次
bgrewriteaof触发时生效，旧AOF仍为纯文本命令
为什么重写后AOF文件开头像RDB：二进制头 + 命令尾的结构
开启混合后，bgrewriteaof 不再把整个数据库状态翻译成一堆SET/LPUSH命令，而是先用RDB格式序列化全量数据（紧凑、快速加载），再把重写期间新产生的增量命令以AOF协议追加在后面。所以你会看到appendonly.aof文件开头是乱码（实际是RDB二进制头，如REDIS0011），后面才是可读的文本命令。
- 这种结构让恢复速度接近RDB：跳过逐条解析命令，直接
rdbLoad加载快照部分 - 但又保留AOF语义：增量部分确保重写窗口内的写操作不丢失
- 别用
cat硬看混合AOF文件——会显示乱码+部分明文，这是正常现象，不是损坏
哪些配置会影响混合持久化效果
混合持久化不是“设了就完事”，它严重依赖AOF重写的触发时机和策略。如果AOF从不重写，那永远用不上RDB preamble。
-
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size必须合理设置，否则可能长期不触发重写。例如设成100和64mb，但业务写入极低，AOF始终20mb，那就永远不会混合 -
no-appendfsync-on-rewrite yes建议开启：避免AOF重写时appendfsync everysec被阻塞，导致主线程延迟飙升 -
stop-writes-on-bgsave-error对混合无直接影响，但若RDB部分写失败（如磁盘满），整个bgrewriteaof会中止，AOF保持纯文本状态
容易踩的坑：RDB配置没关干净，反而多存一份
很多人开了混合持久化，却忘了注释掉save规则，结果系统既生成dump.rdb，又在appendonly.aof里存了一份RDB二进制——白白占用双倍磁盘，还增加fork负担。
- 混合持久化启用后，
save配置建议全部注释掉（如# save 900 1），因为AOF本身已覆盖数据安全需求 - 检查
dir和dbfilename，确保dump.rdb不会意外落盘；可用CONFIG GET dir和CONFIG GET dbfilename确认 - 线上切混合前，务必在测试环境用
redis-cli --rdb /tmp/test.rdb验证AOF文件能否被正确解析——混合AOF不能直接当RDB用，但redis-check-aof --fix仍支持
混合持久化的关键不在“开关”，而在AOF重写是否真正发生、是否稳定落地。盯着INFO persistence里的aof_rewrite_in_progress和aof_last_bgrewrite_status，比反复查配置更有用。
