这是我参与2022首次更文挑战的第27天，活动详情查看：2022首次更文挑战」
前言
针对RDB不适合实时持久化的问题，redis 提供了AOF持久化方式来解决，参考文章，开始吧！
AOF持久化
大多数的数据库采用写前日志（WAL），例如MySQL，Redis是“写后”日志，即Redis先执行命令把数据写入内存，然后才记录日志。这是因为Redis要求高性能，采用写后日志的好处是：
- 避免额外的检查开销
- 不会阻塞当前的写操作 潜在风险是：
- 如果命令执行完成，写日之前宕机了，会丢失数据。
- 主线程写磁盘压力大，导致写盘慢，阻塞后续操作。
实现方式
AOF日志记录Redis的每个写命令，步骤是：
- 命令追加（append） 当AOF持久化功能打开了，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。
- 文件写入和同步（write、sync）
关于何时将 aof_buf 缓冲区的内容写入AOF文件中，Redis提供了三种写回策略：
Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
这三种写回策略的一个重要原则是：trade-off，取舍，也就是会在性能和可靠性保证之间做取舍。
从持久化中恢复数据
数据的备份、持久化做完了，我们如何从这些持久化文件中恢复数据呢？如果一台服务器上有既有RDB文件，又有AOF文件，该加载谁呢？
- redis重启时判断是否开启aof，如果开启了aof，那么就优先加载aof文件；
- 如果aof存在，那么就去加载aof文件，加载成功的话redis重启成功，如果aof文件加载失败，那么会打印日志表示启动失败，此时可以去修复aof文件后重新启动；
- 若aof文件不存在，那么redis就会转而去加载rdb文件，如果rdb文件不存在，redis直接启动成功；
- 如果rdb文件存在就会去加载rdb文件恢复数据，如加载失败则打印日志提示启动失败，如加载成功，那么redis重启成功，且使用rdb文件恢复数据；
