【Redis / 缓存内核】AOF：命令日志 · rewrite · appendfsync
内容提要
本文讨论了Redis 7.4.x中的AOF（追加只文件）机制，强调其通过命令日志记录数据变化。AOF使用多段清单管理数据，支持增量写入和重放恢复。分析了不同fsync策略对数据持久性的影响，指出“always”模式下fsync失败会导致进程退出，而“everysec”模式允许最多1秒的数据丢失。此外，AOF重写过程通过子进程压缩日志，确保数据一致性。
关键要点
-
AOF（追加只文件）通过记录数据变化的命令来实现数据持久化，采用多段清单管理数据。
-
AOF的fsync策略有三种：always、everysec和no，影响数据的持久性和丢失窗口。
-
在always模式下，fsync失败会导致进程退出，而everysec模式允许最多1秒的数据丢失。
-
AOF重写过程通过子进程压缩日志，确保数据一致性，避免在fork窗口内丢失命令。
-
AOF的加载过程按manifest顺序进行，支持截断损坏尾部后启动，允许一定程度的数据丢失。
延伸解读
AOF与RDB的比较
AOF（追加只文件）与RDB（快照）在数据持久化方面有显著差异。AOF通过记录每个写操作的命令来实现，而RDB则是定期保存数据的快照。AOF的文件体积会随着时间的推移而膨胀，可能导致恢复速度变慢，而RDB则相对紧凑，恢复速度较快。选择使用哪种方式应根据具体的应用场景和对数据一致性的需求来决定。
fsync策略的影响
AOF的fsync策略对数据的持久性和丢失窗口有直接影响。使用'appendfsync always'模式时，fsync失败会导致进程退出，数据安全性高，但性能可能受到影响。而'everysec'模式则允许最多1秒的数据丢失，适合对性能要求较高的场景。用户在选择fsync策略时需权衡数据安全与性能之间的关系。
AOF重写过程的关键
AOF重写过程通过子进程压缩日志，确保数据一致性，避免在fork窗口内丢失命令。重写的触发条件包括手动命令和自动阈值，合理配置重写频率可以有效降低文件膨胀带来的性能问题。开发者应关注重写过程中的资源占用，确保系统在高负载下仍能稳定运行。
延伸问答
AOF机制是如何实现数据持久化的？
AOF通过记录数据变化的命令来实现数据持久化，采用多段清单管理数据。
AOF的fsync策略有哪些？
AOF的fsync策略有三种：always、everysec和no，分别影响数据的持久性和丢失窗口。
在AOF的always模式下，fsync失败会发生什么？
在always模式下，fsync失败会导致进程退出，因为无法回滚内存状态。
AOF重写过程是如何进行的？
AOF重写过程通过子进程压缩日志，生成最小命令集，确保数据一致性。
AOF的加载过程是怎样的？
AOF的加载过程按manifest顺序进行，先加载基础文件再加载增量文件，支持截断损坏尾部后启动。
AOF与RDB的主要区别是什么？
AOF通过记录操作命令实现持久化，而RDB则是序列化对象，AOF在恢复时可能较慢。
