2015
05-29

剖析Redis持久化之AOF方式

上一篇对redis持久化之RDB方式进行了剖析。除了RDB持久化功能之外,Redis还提供了AOF(Append Only File)持久化功能。下面就来介绍一下AOF持久化功能。


1、AOF持久化原理

与RDB持久化通过保存数据库中的键值对来记录数据库状态不同,AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。并在服务器启动时,通过重新执行这些命令来还原数据库。如下图:
aof.png

顺便提一句,被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的。因为Redis的命令请求协议是纯文本格式,所以我们是可以直接打开一个AOF文件,观察里面的内容的。


2、AOF持久化配置

首先在redis.conf文件开启aof持久化(默认没开启)

appendonly yes

然后对redis.conf文件中的“appendfsync”选项进行规则配置。不同的appendfsync值产生的持久化行为也不相同。

appendfsync=always

appendfsync设置为always时,服务器在每个事件循环中将aof_buf缓冲区中的所有内容写入并同步到AOF文件。从效率来说,是三个选项值当中最慢的一个,但从安全性来说,always是最安全的,因为即使出现故障停机,AOF持久化也只会丢失一个事件循环中所产生的命令数据。


#默认选项
appendfsync=everysec

appendfsync设置为everysec时,服务器在每个事件循环中将aof_buf缓冲区中的所有内容写入到AOF文件,并且每隔一秒将再次对AOF文件进行同步,并且这个同步操作是由一个线程专门负责执行的。从效率上来说,everysec模式足够快,并且就算出现故障停机,数据库也只丢失一秒钟的命令数据。


appendfsync=no

appendfsync设置为no时,服务器在每个事件循环中,将aof_buf缓冲区中的所有内容写入到AOF文件,但并不对AOF文件进行同步,何时同步由操作系统决定。从效率上来说,与everysec模式相当。AOF文件写入速度是最快的,但是单次同步时长是三种模式中最长的,当出现故障停机时,服务器将丢失上次同步AOF文件之后的所有写命令数据。

不论设置为以上三种的任一种情况,AOF持久化功能的实现基本可以分为命令追加(append)、文件写入、文件同步(sync)三个步骤。


3、AOF文件载入与数据还原

因为AOF文件里面包含了重建数据库状态所需的所有写命令,所以服务器只要读入并重新执行一遍AOF文件里面保存的写命令,就可以还原服务器关闭之前的数据库状态。
aof.png


4、AOF重写

因为AOF持久化是通过保存被执行的写命令来记录数据库状态的,所以随着服务器运行时间的流逝,AOF文件中的内容会越来越多,文件的体积也会越来越大,如果不加以控制的话,体积过大的AOF文件很可能对Redis服务器、甚至整个服务器造成影响,并且AOF文件的体积越大,使用AOF文件来进行数据还原所需的时间就越多。
为了解决AOF文件体积膨胀的问题,Redis提供了AOF文件重写功能。通过该功能,Redis服务器会启动一个子进程,来创建一个新的AOF文件来替代现有的AOF文件,新旧两个AOF文件所保存的数据库状态相同,但新AOF文件不会包含任何浪费空间的冗余命令,所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。


5、RDB持久化与AOF持久化对比

AOF文件的更新频率通常比RDB文件的更新频率高,所以如果服务器开启了AOF持久化功能,那么服务器会优先使用AOF文件来还原数据库状态;只有在AOF持久化功能处于关闭状态时,服务器才会使用RDB文件来还原数据库状态。

「真诚赞赏,手留余香」
您的支持将鼓励我继续创作 :)