appendfsync配置决定AOF落盘时机与数据丢失量：always最安全但性能差；everysec为默认，最多丢1秒数据；no性能最好但可能丢30秒数据；写后日志机制本身存在固有窗口期，需RDB+AOF或主从架构兜底。
appendfsync 配置直接决定 AOF 日志落盘时机，进而决定 Redis 宕机时最多丢失多少数据——不是“会不会丢”，而是“丢多少”。
appendfsync always 为什么最安全但慎用
每次写命令执行完，立刻调用 fsync() 强制刷盘。即使断电，只要命令返回成功，就已落盘。
- 适合金融类交易等零容忍丢数据的场景，但吞吐量会暴跌（尤其机械盘）
- 高并发下容易阻塞主线程：
fsync()是同步磁盘操作，慢就卡住后续所有请求 - SSD 也扛不住高频
fsync()，实测 QPS 可能跌 40% 以上
appendfsync everysec 是生产环境默认选择
Redis 启动一个后台线程，每秒把 AOF 缓冲区（aof_buf）内容 fdatasync() 到磁盘。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 宕机最多丢失 1 秒内写入，对绝大多数业务可接受
- 性能折损小：磁盘压力分散，不阻塞主线程
- 注意：
everysec不是“严格每秒”，若上一秒没刷完，下一秒会合并刷；极端情况下可能积压 2 秒数据
appendfsync no 的风险在哪
完全交由操作系统决定何时刷盘，Redis 只负责把日志写进内核缓冲区。
- 性能最好，但风险最高：机器掉电或内核崩溃时，缓冲区里未刷的数据全丢
- Linux 默认脏页回写周期是 30 秒，意味着可能丢最多半分钟数据
- 仅建议用于纯缓存、可重建的场景（比如 Session 存储），绝不能用于状态型数据
AOF 写后日志机制本身带来的固有缺陷
AOF 是先改内存、再记日志，这个顺序决定了它天生有“窗口期”。
- 命令执行成功 → 还没来得及写入 AOF 缓冲区 → 宕机 → 数据丢失
- 即使
appendfsync always，也无法覆盖这个间隙（因为日志记录本身也是个操作） - 真正兜底要靠 RDB + AOF 混合使用，或部署主从+哨兵自动故障转移，而不是只调一个配置
配置再细，也绕不开写后日志的本质限制：它保的是“命令重放能力”，不是“原子性持久化”。真正关键的数据，别只靠 AOF 一条链路扛着。
