Redis持久化机制：AOF日志

前言

说到关系型数据库，最常想到的就是MySQL、oracle了；说到非关系型数据库，最常想到的就是redis、MongoDB了。而Redis因其速度快的优势，广泛应用在各种缓存场景中。

但redis数据是存储在内存中，所以数据的持久化就显得尤为重要，我们都知道，Redis有两大持久化机制，分别是 AOF日志 和 RDB快照，今天就先来说说AOF日志的重要知识吧。

AOF写入规则

简单来说，AOF写入规则就是：

1. redis执行命令
2. 执行成功后，将命令记录到日志中（注意，是将命令记录起来）

注意，命令成功后才会记录命令，这样就可以避免记录大量错误命令到日志中了。

AOF存在2个潜在风险：

• 丢失数据，比如刚执行完一个命令，AOF日志还没记录就宕机了，此时会丢失这个命令日志。
• 会阻塞Redis主线程：AOF不会阻塞当前的操作，但是可能会给下一操作带来阻塞的风险，因为AOF日志也是在Redis的主线程中完成的。

AOF的3种写回策略

为了解决丢失数据的风险，AOF有提供了3种写回策略，分别是：

• Always 同步写回：每个写命令执行完成，立刻同步地将日志写回磁盘；
• Everysec 每秒写回：每个写命令执行后，日志先写到内存缓冲区，每1秒将缓冲区的内容写入磁盘；
• No 操作系统控制的写回：每个写命令执行后，把日志写到AOF文件的内存缓冲区，写入时机由操作系统决定。

每种策略都有各自的优缺点，总结就是：

根据每种策略的优缺点，我们结合项目的要求来选择策略。比如说我们的数据可靠性的要求特别高，就选择Always策略；如果想高性能，可靠性要求不是很高，就选择No策略；如果允许数据有少部分丢失，性能要求不能受太大影响，我们可选择Everysec策略。

当AOF记录的日志越来越多，日志文件也会随着增大，我们需要注意随之产生的性能问题。总结有3点：

1. 系统会限制保存过大的文件；
2. 文件太大，追加日志的话，效率会变低；
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重写的触发：

1. auto-aof-rewrite-min-size: 表示运行AOF重写时文件的最小大小，默认为64MB
2. auto-aof-rewrite-percentage: 当前AOF文件比上一次重写后AOF文件的增量大小，和上一次重写后AOF文件大小的比值。

当AOF文件大小同时超出2个配置项的值时，Redis就会触发AOF重写这个机制。

小结

Redis AOF日志，是Redis持久化机制的一种。当我们要选择此机制时，需要了解其写入规则及其重要参数，才能更好的配置好redis。