纯AOF模式重启卡住几十秒是因为需逐条重放命令而非加载快照；混合持久化需同时满足AOF开启、保留save规则、手动触发bgrewriteaof生成含REDIS0011魔数的新AOF文件。
纯AOF模式重启卡住几十秒，本质是命令重放不是加载
Redis启动时显示LOADING Redis is loading the dataset in memory，且INFO persistence里loading:1长时间不变成0，说明它正在逐条执行appendonly.aof里的命令——不是“读快照”，而是走完整命令路径：解析、键查找、过期判断、写入、模拟响应。哪怕内存只有12MB，只要AOF里有50万条历史命令，就得一条条跑完才能对外服务。
常见误判是以为磁盘慢或内存小，其实问题根子在AOF文件结构本身。纯文本AOF（开头是*2\r\n$6\r\nSELECT\r\n这类）无法跳过冗余操作，必须全量重放。
混合持久化不是改个配置就生效
只执行config set aof-use-rdb-preamble yes或只在redis.conf里设aof-use-rdb-preamble yes，完全没用。旧AOF文件仍是纯文本格式，下次重启照样全量重放。
真正启用混合模式必须同时满足：
-
appendonly yes（AOF开启） - 至少保留一个
save规则（如save 300 1或save ""），不能清空所有save行 - 手动触发一次
bgrewriteaof，生成含RDB preamble的新AOF文件
验证是否成功：用head -c 100 /var/lib/redis/appendonly.aof | hexdump -C看开头，应出现REDIS0011（RDB魔数），而不是*2\r\n\r\nSELECT\r\n。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
自动重写阈值默认值在生产环境基本失效
auto-aof-rewrite-min-size 64mb和auto-aof-rewrite-percentage 100这两个默认值，在真实业务中几乎总是错配：
- 64MB对小实例可能够用，但中大型实例几分钟就突破，导致频繁重写、IO打满
- 100%翻倍才重写，容易在高峰期连续触发，尤其刚重写完又快速膨胀
- 单位必须带
mb或gb，写成1024会被当成字节，实际只到1KB就触发
推荐按日均写入量调整：例如日均2GB，可设auto-aof-rewrite-min-size 1gb + auto-aof-rewrite-percentage 80。重写后立刻查INFO persistence中的aof_current_size与aof_base_size，差值应明显收窄。
执行bgrewriteaof前必须确认三件事
bgrewriteaof是后台操作，但子进程仍需内存拷贝+磁盘写入，疏忽易OOM或IO阻塞：
- 剩余磁盘空间 ≥ 当前AOF文件大小的1.5倍（重写期间新旧文件并存）
-
INFO persistence中aof_rewrite_in_progress:0，避免并发重写 - 避开流量高峰——重写时新写命令会暂存在
aof_rewrite_buffer，QPS突增易溢出，导致客户端超时
执行后观察：redis-cli INFO | grep -E "aof_rewrite|used_memory"，确认aof_rewrite_in_progress从1变0，且used_memory无异常飙升。重写完成不代表立即生效，必须等Redis用新AOF文件替换旧文件，且下次启动时能识别RDB preamble才算真正切换成功。
