1、AOF的基本概念
- AOF持久化方式是通过保存Redis所执行的写命令来记录数据库状态的。
- AOF以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来（读操作不记录）。
- AOF文件是一个只追加的文件，只允许追加文件但不可以改写文件。
2、配置
- AOF默认不开启,在conf配置文件中进行配置。
- 修改redis.conf配置文件
appendonly no
//修改
appendonly yes- 默认文件名是appendonly.aof
- 默认是启动后的相对路径，redis在哪里启动，appendonly.aof文件就在哪生成
3、AOF持久化
3.1流程
- 写命令追加：客户端的写命令请求会被追加到AOF缓冲区内。
- 同步到磁盘：AOF缓冲区根据AOF持久化策略（
always、everysec、no）将操作同步到磁盘的AOF文件中。 - AOF文件重写：当AOF文件大小超过重写策略或手动触发时，会对AOF文件进行重写，以压缩AOF文件容量。重写过程会创建一个新的AOF文件，只包含恢复当前数据状态所必需的命令。
- 数据恢复：当Redis服务重启时，会重新加载AOF文件中的写操作，以达到数据恢复的目的。
3.2三种写回策略
- always（每次）
- 含义：每次写入操作都立即同步到AOF文件。
- 特性：
- 数据零误差：由于每次写操作都立即同步，因此数据安全性最高，几乎不会丢失数据。
- 性能较低：频繁的磁盘IO操作会对Redis的性能产生较大影响。
- 适用场景：对数据安全性要求极高，可以容忍较低性能的场景。
- everysec（每秒）
- 含义：每秒将缓冲区中的写命令同步到AOF文件。
- 特性：
- 数据准确性较高：在大多数情况下，数据只会丢失一秒内的写操作。
- 性能较高：每秒同步一次，避免了频繁的磁盘IO操作，对Redis性能影响较小。
- 适用场景：对数据安全性有一定要求，同时希望保持较高性能的场景。这是Redis AOF的默认配置。
- no（系统控制）
- 含义：由操作系统控制写命令同步到AOF文件的频率。
- 特性：
- 整体过程不可控：同步频率完全取决于操作系统的调度和硬件性能。
- 性能最好：Redis几乎不参与同步操作，性能开销最小。
- 数据安全性最低：在系统突然宕机的情况下，可能会丢失较多的数据。
- 适用场景：对数据安全性要求不高，追求极致性能的场景。
4、AOF的特点
优势：
- 更好的数据安全性：由于AOF记录了每个写操作，因此即使出现意外宕机，也可以通过AOF文件恢复数据。
- 可读的日志文本：AOF文件以文本格式存储，可以通过查看AOF文件来处理误操作或进行数据审计。
劣势：
- 占用更多的磁盘空间：与RDB相比，AOF文件通常更大，因为它记录了所有的写操作。
- 恢复备份速度较慢：由于AOF需要执行文件中的每个写操作来恢复数据，因此恢复速度通常比RDB慢。
- 性能压力：如果每次写操作都立即同步到AOF文件（
always策略），会对Redis的性能产生一定的影响。
5、应用场景
- 数据安全性要求高：
- 金融交易系统：在金融领域，数据的完整性和安全性至关重要。AOF机制通过记录所有的写操作，可以在系统崩溃后几乎无数据丢失地恢复数据。
- 关键业务系统：对于不能容忍任何数据丢失的系统，如电商平台的核心交易系统，AOF提供了更高的数据安全性保障。
- 实时性要求高：
- 实时数据分析：在一些实时数据分析场景中，数据的实时性和一致性非常重要。AOF可以在不阻塞主线程的情况下，异步地将写操作追加到AOF文件中，从而确保数据的实时性和一致性。
- 实时日志记录：AOF以文本形式存储写操作，这使得它非常适合用于实时日志记录场景。系统管理员可以通过查看AOF文件来跟踪Redis的写操作，并进行审计或故障排查。
- 写操作频繁：
- 高并发写入场景：在写操作频繁的系统中，如缓存系统、消息队列等，AOF机制能够确保所有的写操作都被持久化保存，防止因系统崩溃而导致的数据丢失。
- 数据更新频繁的应用：对于需要频繁更新数据的应用，如在线游戏、实时排名等，AOF能够确保每次数据更新都被记录下来，并在需要时恢复。
- 容灾备份：
- 异地容灾：通过将AOF文件备份到远程服务器，可以实现Redis的异地容灾。即使本地服务器发生故障，也可以从远程服务器上的AOF文件恢复数据。
- 数据迁移：AOF文件也可以用于Redis的数据迁移。通过复制AOF文件到新的服务器，并在新服务器上重新加载AOF文件，可以实现Redis数据的快速迁移。
