前言
说到关系型数据库，最常想到的就是MySQL、oracle了；说到非关系型数据库，最常想到的就是redis、MongoDB了。而Redis因其速度快的优势，广泛应用在各种缓存场景中。
但redis数据是存储在内存中，所以数据的持久化就显得尤为重要，我们都知道，Redis有两大持久化机制，分别是 AOF日志 和 RDB快照，今天就先来说说AOF日志的重要知识吧。
AOF写入规则
简单来说，AOF写入规则就是：
- redis执行命令
- 执行成功后，将命令记录到日志中（注意，是将命令记录起来）
注意，命令成功后才会记录命令，这样就可以避免记录大量错误命令到日志中了。
AOF存在2个潜在风险：
- 丢失数据，比如刚执行完一个命令，AOF日志还没记录就宕机了，此时会丢失这个命令日志。
- 会阻塞Redis主线程：AOF不会阻塞当前的操作，但是可能会给下一操作带来阻塞的风险，因为AOF日志也是在Redis的主线程中完成的。
AOF的3种写回策略
为了解决丢失数据的风险，AOF有提供了3种写回策略，分别是：
- Always 同步写回：每个写命令执行完成，立刻同步地将日志写回磁盘；
- Everysec 每秒写回：每个写命令执行后，日志先写到内存缓冲区，每1秒将缓冲区的内容写入磁盘；
- No 操作系统控制的写回：每个写命令执行后，把日志写到AOF文件的内存缓冲区，写入时机由操作系统决定。
每种策略都有各自的优缺点，总结就是：
| 策略 | 优点 | 缺点 |
| Always | 数据基本不丢失 | 每个命令执行后都得同步，性能影响大 |
| Everysec | 性能适中 | 宕机会丢失1秒内的数据 |
| No | 性能最好 | 宕机会丢失较多数据 |
根据每种策略的优缺点，我们结合项目的要求来选择策略。比如说我们的数据可靠性的要求特别高，就选择Always策略；如果想高性能，可靠性要求不是很高，就选择No策略；如果允许数据有少部分丢失，性能要求不能受太大影响，我们可选择Everysec策略。
当AOF记录的日志越来越多，日志文件也会随着增大，我们需要注意随之产生的性能问题。总结有3点：
- 系统会限制保存过大的文件；
- 文件太大，追加日志的话，效率会变低；
- 文件太大，如果发生宕机，恢复时间就会很慢。
Redis的设计者也考虑到了这个问题，因此就有了下面要讲的AOF重写机制。
AOF重写机制
重写机制说简单点，就是会对记录的多条命令加以判断，如果可合并，就对多条命令合并，这样就减少了文件大小。 举个例子来说：
重写前的命令： $ hset nba curry 30 $ hset nba james 23 $ hdel nba james 23 $ hset nba kobe 24 复制代码
此时nba这个哈希列表中有的数据是：curry 30, kobe 24
经过AOF重写后的命令就会简化成：
$ hset nba curry 30 $ hset nba kobe 24 复制代码
AOF重写这个过程，不会阻塞主线程。因为这个过程是通过后台子进程bgrewriteaof去完成的。重写这个过程，总结来说就是一个拷贝，两处日志。
一个拷贝 意思就是当AOF重写时，主线程会fork出一个子进程bgrewriteaof。同时，fork会将主线程的内存拷贝一份给子进程，这样子进程就能访问到最新的数据，bgrewriteaof就将需要拷贝的数据记录到重写日志。
两处日志 指的是：1. 正在使用的AOF日志，redis会将它写到缓冲区；2.新的AOF重写日志，也会被写到重写日志的缓冲区，等到拷贝数据的重写完成后，再将新的重写日志也写到AOF文件中。
归纳一下，每次AOF重写时，Redis会拷贝一份内存用于重写。然后2处日志就是保证重写过程中，新产生的数据不会丢失。
AOF重写的触发条件
我们可通过2个配置项去控制AOF重写的触发：
- auto-aof-rewrite-min-size: 表示运行AOF重写时文件的最小大小，默认为64MB
- auto-aof-rewrite-percentage: 当前AOF文件比上一次重写后AOF文件的增量大小，和上一次重写后AOF文件大小的比值。
当AOF文件大小同时超出2个配置项的值时，Redis就会触发AOF重写这个机制。
小结
Redis AOF日志，是Redis持久化机制的一种。当我们要选择此机制时，需要了解其写入规则及其重要参数，才能更好的配置好redis。
