关闭RDB后AOF仍可能丢数据，因AOF的appendfsync策略决定持久化强度：always每写刷盘、everysec默认每秒刷一次（最多丢1秒）、no交由OS处理（可能丢数分钟）；生产中极少用always，故仅开AOF不等于不丢数据。
为什么关闭RDB后AOF仍可能丢数据
关闭RDB不等于强一致性保障。AOF本身有三种appendfsync策略：always（每写必刷盘）、everysec（默认，每秒刷一次）、no（交由OS决定）。若用everysec，崩溃最多丢失1秒内命令；若用no，可能丢数分钟数据。实际生产中，always因磁盘I/O压力大极少启用，所以“仅开AOF”不自动等于“不丢数据”。
常见错误现象：服务重启后发现最后几条写入消失，但redis-cli info persistence显示aof_enabled:1——这说明AOF开了，但没配对策略。
- 确认当前策略：
redis-cli config get appendfsync - 临时生效（重启失效）：
redis-cli config set appendfsync always - 持久生效：在
redis.conf里显式写入appendfsync always，再redis-cli config rewrite
AOF重写期间的内存与性能抖动
AOF文件持续增长会拖慢加载速度和磁盘占用，Redis靠bgrewriteaof异步重写压缩。但重写过程本身吃CPU、内存和磁盘IO，尤其当写入频繁时，容易触发高延迟或连接超时。
典型表现：INFO stats中latest_fork_usec值突然飙升（>500ms），或客户端报READ timeout。
- 避免在业务高峰触发重写：用
redis-cli bgrewriteaof前先看redis-cli info memory | grep used_memory_human是否接近上限 - 控制重写频率：调大
auto-aof-rewrite-min-size（如从64mb→512mb），并设auto-aof-rewrite-percentage 100防止小增量反复重写 - 重写失败后AOF仍可用：只要
appendonly.aof文件末尾完整，Redis启动时能跳过损坏部分继续加载
关闭RDB后如何安全做备份
RDB文件是二进制快照，天然适合冷备和跨版本恢复；AOF是文本协议流，不能直接cp备份——因为重写可能正在写入，文件处于中间状态。
错误做法：cp appendonly.aof appendonly.aof.bak → 备份文件可能被截断或包含未完成命令，恢复时报Unexpected EOF或Invalid argument。
- 正确方式一（推荐）：用
redis-cli --rdb backup.rdb生成RDB快照（即使save配置全关，该命令仍有效） - 正确方式二：触发AOF重写后，等
INFO persistence中aof_rewrite_in_progress:0再拷贝appendonly.aof - 注意路径：备份必须读取
config get dir返回的目录，不是当前工作目录
从RDB切换到纯AOF的线上迁移要点
不能直接停掉RDB再开AOF——旧RDB文件不会自动转成AOF，会导致上次RDB以来所有写入丢失。
必须让Redis先用RDB加载，再把RDB里的数据重放为AOF命令流，这个过程叫“AOF rewrite from RDB”。关键在于顺序和时机。
- 第一步：确保
appendonly yes已写入配置，但先不要CONFIG REWRITE或重启 - 第二步：执行
redis-cli config set appendonly yes，Redis会立即开始记录新命令到AOF，并后台启动一次重写，把当前内存数据转成AOF格式 - 第三步：等
INFO persistence显示aof_rewrite_in_progress:0且aof_current_size > 0，再执行config set save ""彻底禁用RDB触发条件 - 第四步：最后
CONFIG REWRITE落盘，删掉原dump.rdb（别手快删早了）
最容易被忽略的是第二步后的等待——重写没完成就禁RDB，等于主动放弃RDB里的全部历史数据。
