配置appendfsync需权衡数据安全与性能：always零丢失但性能差；everysec默认推荐，最多丢1秒数据；no仅适用于可容忍大量丢失的缓存场景，并需配合no-appendfsync-on-rewrite等关键配置及RDB混合持久化。
配置 appendfsync 的核心，是根据业务对“最多能丢多久数据”和“写入吞吐能否承受”的实际判断来选值，而不是追求理论上的绝对安全或极致性能。
理解三个选项的真实影响
• always：每次写命令后立刻 fsync 到磁盘。数据零丢失（严格说最多丢最后一个命令），但磁盘 I/O 成为瓶颈，QPS 可能下降 50% 以上，不适用于高并发写场景。
• everysec（默认）：命令先写入内核缓冲区，每秒统一刷盘一次。崩溃时最多丢失 1 秒内的写操作，绝大多数业务可接受；性能损耗小，是生产环境最常用、最推荐的折中选择。
• no：完全交由操作系统决定刷盘时机（Linux 默认约 30 秒）。写入延迟最低，但宕机可能丢失几十秒数据，仅适合纯缓存、可容忍大量丢失的场景，如临时会话 ID 缓存。
关键配套配置不能忽略
• no-appendfsync-on-rewrite yes：AOF 重写（bgrewriteaof）期间，暂停 fsync，避免因磁盘压力导致主线程阻塞。此时新写入暂存在内存缓冲区，重写完成后一并刷盘——既保性能，又不额外增加丢失窗口。
• auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size：合理设置 AOF 文件膨胀阈值（如 100% + 64MB），避免频繁重写拖慢系统，也防止文件过大影响恢复速度。
• appendonly yes 必须开启，否则所有 appendfsync 配置都不生效。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
结合业务场景做取舍
• 订单、支付类系统：选 always，哪怕吞吐降一半，也要确保每笔交易日志落盘；需搭配高性能 SSD 和充足 I/O 带宽。
• 实时推荐、用户行为埋点：用 everysec 即可，1 秒误差不影响分析结果，且保障吞吐稳定。
• 热点缓存预热、临时 Token 存储：可考虑 no，配合后端数据库兜底，专注响应速度。
验证与兜底建议
• 开启 AOF 后务必检查 appendonly.aof 文件是否持续增长，确认日志真实写入。
• 不要只依赖 AOF：建议同时启用 RDB（如 save 300 10），作为基础快照锚点，降低 AOF 文件体积和恢复耗时。
• 生产环境强烈建议开启混合持久化：aof-use-rdb-preamble yes，重启时先加载 RDB 头部再重放增量命令，兼顾恢复速度与完整性。
