不能仅设appendonly yes就防丢数据；必须同时配置appendfilename、dir可写权限，并建议设appendfsync everysec，动态开启后须执行CONFIG REWRITE落地配置，再通过INFO persistence验证生效。
直接开 appendonly yes 就能防丢数据？不行。光改这一行，Redis 会启动失败，或者重启后 AOF 文件不生成、不生效——这是最常踩的坑。
修改 redis.conf 必须配齐这三件事
AOF 不是单靠一个开关就能跑起来的机制，它依赖三个基础配置协同工作：
-
appendonly yes：必须设为yes，否则整个 AOF 流程不会启动 -
appendfilename "appendonly.aof"：文件名不能带路径，只写文件名；如果改了名字（比如加端口后缀），后续重写、加载都可能出错 -
dir路径必须可写：这个目录要和dbfilename（RDB 的dump.rdb）共用同一位置，且 Redis 进程用户（如redis或www）有写权限；常见错误是路径写成/var/lib/redis但实际没创建或权限不对
appendfsync everysec 是默认值，但不是万能解
这个参数决定命令写入磁盘的节奏，直接影响“最多丢多少数据”：
-
appendfsync always：每次写都落盘，安全但性能暴跌，QPS 高时容易卡住主线程 -
appendfsync everysec（默认）：命令先写入内核缓冲区，每秒刷一次盘；崩溃最多丢 1 秒数据，是绝大多数业务的合理选择 -
appendfsync no：完全交由操作系统调度，性能最好，但断电可能丢几分钟数据，不建议生产环境用
注意：everysec 模式下，如果上一秒的刷盘被阻塞（比如磁盘忙），Redis 会退化为 always 行为——所以别以为设了 everysec 就万事大吉，得看磁盘 I/O 是否稳定。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
动态开启后必须 CONFIG REWRITE，否则配置不落地
用 CONFIG SET appendonly yes 开启后，Redis 确实会立刻启用 AOF，并自动触发一次 BGREWRITEAOF 生成初始文件。但这个设置只在内存中生效，进程重启就丢了。
- 必须紧接着执行
CONFIG REWRITE，把当前运行时配置回写进redis.conf - 否则下次重启，
appendonly又变回no，AOF 彻底失效 - 宝塔面板用户尤其要注意：点【保存】配置文件 ≠ 执行了
CONFIG REWRITE，得进终端手动补上这一步
AOF 重写阈值不调，文件会越滚越大
AOF 文件是追加写的，删 key、改 value 都会留下旧指令，不做清理体积会指数级膨胀。靠这两个参数控制重写时机：
-
auto-aof-rewrite-percentage 100：当前 AOF 大小比上次重写后增长 ≥100%（即翻倍）就触发重写 -
auto-aof-rewrite-min-size 64mb：AOF 文件至少大于 64MB 才考虑重写（防止小文件频繁重写）
如果你的业务写入量不大，但 key 生命周期短（比如大量 session 过期），AOF 实际有效内容可能只有几 MB，但文件却涨到几百 MB——这时得调低 min-size，否则重写永远不触发。
真正难的不是“怎么开”，而是“开了之后怎么确认它真在干活”。别只看配置文件有没有 yes，得查 INFO persistence 里的 aof_enabled、aof_current_size、aof_rewrite_in_progress 这几个字段，再配合 ls -lh 看文件是否在增长——否则你只是以为自己防住了丢数据。
