Redis 有两种持久化方式：AOF 和 RDB。本节就先来聊聊 AOF。AOF（Append Only File） 日志是写后日志，Redis 会先执行命令，把数据写入内存，然后才记录日志。1 开启 AOF 日志
在 Redis 的配置文件中，设置以下两个参数即可开启 AOF：appendonly yes
appendfilename "appendonly.aof"
appendfilename：定义 AOF 文件名
2 AOF 的内容
AOF 里记录的是 Redis 收到的每一条写命令，这些命令是以文本形式保存的。我们就来通过一个实验看下 AOF 中的内容。首先连上本地 Redis（本节的版本为：5.0.7）：tail data/redis6301/data/appendonly.aof
如上图，其中 *3 表示当前命令有三个部分，每个部分从 $“数字”开始，数字表示这部分中命令、键或者值一同有多少字节。
3 为什么是 AOF 而不是 WAL
很多数据库都是采用的 Write Ahead Log（WAL）方式，其特点就是先把修改的数据记录到日志中，再进行写数据的提交，可以方便通过日志进行数据恢复。但是 Redis 采用的却是 AOF，特点就是先执行写命令，把数据写入内存中，再记录日志。那么 Redis 为什么考虑使用 AOF 而不是 WAL 呢？这是因为先让系统执行命令，只有命令能执行成功，才会被记录到日志中。因此，Redis 使用写后日志这种形式，可以避免出现记录错误命令的情况。另外还有一个原因就是：AOF 是在命令执行后才记录日志，所以不会阻塞当前的写操作。4 AOF 文件同步策略
AOF 虽然避免了对当前命令的阻塞，但是可能阻塞下一个操作，这是因为 ，AOF 日志是在主线程中执行的，如果写日志时磁盘 IO 压力较大，就会导致后续的写操作很慢，从而导致命令阻塞。那么 Redis 有没有类似 MySQL 中控制 redo log 落盘时机的参数呢？有意思的是的确有类似参数 appendfsync，控制 AOF 缓冲区文件同步策略。该参数的可配置值如下：| 可配置值 | 详解 |
| 同步写回：每个写命令执行完，立马同步地将日志写回磁盘 |
| 每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘 |
| 操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘 |
- 如果对性能要求很高，而对数据可靠性要求不高，就选择 No 策略；
- 如果想要得到高可靠性保证，就选择 Always 策略；
- 如果允许数据有一点丢失，又希望性能别受太大影响的话，那么就选择 Everysec 策略。
5 AOF 重写机制
如果实例运行比较久，并且修改比较频繁，那么 Redis 的 AOF 文件很可能比较大，那怎么解决呢？AOF 重写机制是把 Redis 进程内的数据转化为写命令同步到新的 AOF 文件中。并且重写的 AOF 文件可以变小，原因如下面几点：- 旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。
- 已经过期的 key 不再写入新的 AOF 文件中。
首先可以直接执行 bgrewriteaof 命令触发重写机制。- aof_current_size：表示当前 AOF 文件空间
- aof_base_size：表示上一次重写后 AOF 文件空间
- auto-aof-rewrite-min-size: 表示运行 AOF 重写时文件的最小体积，默认为64MB
- auto-aof-rewrite-percentage: 表示当前 AOF 重写时文件空间（aof_current_size）超过上一次重写后 AOF 文件空间（aof_base_size）的比值多少后会重写。
- aof_current_size 大于 auto-aof-rewrite-min-size
- 当前 AOF 相比上一次 AOF 的增长率:(aof_current_size - aof_base_size) aof_base_size 大于或等于 auto-aof-rewrite-percentage
如果二维码过期，在公众号回复“进 Redis 群”即可。
另外，悦专栏欢迎各位大牛投稿，内容可以是数据库、开发、运维、产品、运营等。只要在公众号回复“投稿”即可。
