Redis AOF 写回策略：Always、Everysec、No 怎么取舍

前面讲 Redis 持久化时，我们已经把 RDB、AOF 和混合持久化放在一起看过。这里单独拎出 AOF 写回策略，是因为它很适合作为面试和线上配置的分界题：你到底更怕丢数据，还是更怕写入变慢？

相关基础内容 对 Redis 持久化的概括很清楚：AOF 日志是每执行一条写操作命令，就把该命令以追加方式写入一个文件；RDB 快照是把某一时刻的内存数据，以二进制方式写入磁盘；混合持久化是 Redis 4.0 新增的方式，集成了 AOF 和 RDB 的优点。接着 资料 讲到 AOF 的三种写回策略：Always、Everysec 和 No。这三种策略在可靠性上从高到低，在性能上从低到高。

这篇不把持久化讲散，只抓一个问题：Redis 执行写命令后，AOF 记录已经生成，但它什么时候真正写回硬盘？Always、Everysec、No 的区别，就在这个时间点上。

RDB 保存的是某一时刻的内存快照。它像给 Redis 当前数据拍一张照片，恢复时直接加载这张照片。RDB 的恢复速度通常比较好，但两次快照之间发生的写操作，如果还没进入下一次快照，宕机时就可能丢失。

AOF 保存的是写命令日志。每执行一条写命令，Redis 就把这条命令追加到 AOF 文件里。恢复时，Redis 可以重新播放这些写命令，把数据恢复出来。AOF 的思路更接近“记录变更过程”，而不是只记录某个时间点的结果。

混合持久化把两者结合起来：用 RDB 作为基础数据，再接 AOF 增量命令。这样既能兼顾恢复速度，也能保留较新的写入记录。理解这三者后，再看 AOF 写回策略就很自然：AOF 既然是日志，那日志到底什么时候刷到硬盘，就会影响可靠性和性能。

很多人看到“写入 AOF 文件”，会以为数据已经安全地躺在硬盘上。实际中间还有一层操作系统的缓冲。资料 在解释 Everysec 和 No 时都提到：写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，然后再由策略决定什么时候把缓冲区内容写回硬盘。

这个差别很重要。写到内核缓冲区，速度快，但如果机器突然断电，缓冲区里还没刷到硬盘的内容可能丢失。写回硬盘更可靠，但磁盘 I/O 会拖慢写入路径。AOF 写回策略本质上就是在这两个目标之间选择。

所以不要只问“开了 AOF 会不会丢数据”。更准确的问题是：AOF 用的是什么写回策略？如果是 Always，丢失窗口最小；如果是 Everysec，最多可能丢约一秒内的数据；如果是 No，丢失窗口取决于操作系统何时刷盘。

资料 对 Always 的解释是：每次写操作命令执行完后，同步将 AOF 日志数据写回硬盘。这是三种策略里最可靠的一种。每条写命令都尽量在返回前落盘，异常发生时，已经确认的写入更不容易丢。

代价也直接：性能最低。每次写命令都要等磁盘 I/O，Redis 的低延迟优势会被明显影响。尤其在写入频繁、磁盘性能一般、AOF 文件较忙的场景里，Always 会把写路径拖得很重。

Always 适合特别看重写入可靠性的场景，但这类场景也要想清楚 Redis 的角色。如果 Redis 只是缓存，没必要为了缓存数据付出这么高的刷盘成本。如果 Redis 承载了不容易重建的状态，那除了 Always，还要配合主从、备份、业务补偿一起看。

资料 对 Everysec 的解释是：每次写操作命令执行完后，先把命令写入 AOF 文件的内核缓冲区，然后每隔一秒把缓冲区内容写回硬盘。它的可靠性和性能都处在中间。

Everysec 的好处是写命令不用每次都等硬盘同步完成，性能比 Always 更好；同时 Redis 会主动每秒刷盘一次，可靠性又比完全交给操作系统的 No 更可控。宕机时，理论上可能丢失最近一秒左右的写命令。

这也是很多业务愿意接受的取舍。Redis 常被用于缓存、会话、计数、排行榜、队列辅助状态等场景。对这些数据来说，丢一秒数据不一定完全不可接受，但写入延迟和吞吐对线上体验很敏感。Everysec 就是把损失窗口压在一个相对可控的范围内。

资料 对 No 的解释是：不控制写回硬盘的时机。每次写操作命令执行完后，先把命令写入 AOF 文件的内核缓冲区，再由操作系统决定什么时候把缓冲区内容写回硬盘。

No 的性能最好，因为 Redis 自己不主动等待刷盘。写命令进入内核缓冲区后，Redis 就可以继续处理后面的请求。对追求吞吐、且数据可以丢失或重建的场景来说，它的成本最低。

风险也最大。操作系统什么时候刷盘，并不由 Redis 明确控制。机器故障时，缓冲区里尚未写到硬盘的 AOF 记录可能丢失，丢失范围也更不稳定。它适合把 Redis 当纯缓存、且后端数据源能够承受回源重建的场景，不适合承载难以补偿的数据。

文中那句“可靠性从高到低，性能从低到高”非常适合记。Always 最可靠，因为每次写完都同步刷盘；但性能最低，因为每次都要等磁盘。No 性能最高，因为不主动刷盘；但可靠性最低，因为刷盘时机交给操作系统。Everysec 在两者中间。

这不是 Redis 独有的问题。所有写日志系统都会面对类似取舍：立刻同步到稳定存储，还是先放在缓冲区里批量写？前者更安全，后者更快。AOF 只是把这个选择显式暴露给使用者。

所以配置 AOF 时不要只背默认值。要看数据性质、恢复要求、写入压力和故障容忍度。缓存数据和交易事实不是一类数据；热点榜单和支付流水也不是一类数据。不同数据对“丢一秒”这件事的接受程度完全不同。

如果 Redis 只是 MySQL 前面的缓存层，AOF 策略可以更偏性能。缓存丢了，最多是命中率下降，系统回源数据库重新构建。此时强行使用 Always，可能让缓存层本身变慢，反而削弱 Redis 的价值。

如果 Redis 保存的是会话、计数、排行榜、限流状态，就要看这些数据能不能补。用户会话丢失可能导致重新登录，计数丢失可能造成统计偏差，排行榜丢失可能需要从数据库重算。能补和不能补，决定了你能接受多大的丢失窗口。

如果 Redis 承载的是业务关键状态，就不能只靠 AOF 策略拍板。要考虑主从复制、备份、消息日志、数据库落库、幂等补偿。AOF 能提高恢复能力，但它不是业务正确性的全部答案。

选好写回策略只是开始。线上还要看 AOF 文件增长、刷盘耗时、磁盘 I/O、重写情况、实例延迟。AOF 写得越多，文件越大，恢复和重写都会带来额外成本。只开 AOF 不监控，容易把问题留到故障时才暴露。

Always 要重点看写延迟和磁盘压力；Everysec 要看周期刷盘是否稳定，是否出现刷盘阻塞；No 要接受更大的丢失窗口，同时关注操作系统和磁盘状态。不同策略的监控重点不同。

还有一个现实问题：Redis 经常部署在虚拟机、容器或云盘上，底层磁盘性能不是固定不变的。AOF 策略配置看起来只是 Redis 参数，实际会被宿主机、云盘、文件系统和负载一起影响。

如果被问 Redis 持久化机制，可以先说三类：AOF 日志、RDB 快照、混合持久化。AOF 是每执行一条写命令，就把命令追加写入文件；RDB 是把某一时刻内存数据以二进制方式写入磁盘；混合持久化结合了 RDB 和 AOF 的优点。

如果追问 AOF 三种写回策略，就按 相关的口径回答：Always、Everysec、No。Always 是每次写命令执行完后同步把 AOF 日志写回硬盘，可靠性最高、性能最低；Everysec 是先写入 AOF 文件的内核缓冲区，每隔一秒写回硬盘，是折中方案；No 是 Redis 不控制写回时机，由操作系统决定，性能最高、可靠性最低。

最后补一句选型：AOF 策略没有绝对最好，要看 Redis 保存的数据是否能重建、能接受多大丢失窗口、写入延迟要求多高。只做缓存可以偏性能，保存难以恢复的状态就要提高可靠性，并结合复制、备份和业务补偿。