Redis persistence demystified - part 2

重写AOF

当AOF文件太大时，Redis将在临时文件重新写入新的内容。重写不会读取旧的AOF文件，而是直接访问内存中数据，以便让新产生的AOF文件最小，重写过程不需要读取磁盘。

重写完成后，Redis使用fsync系统调用将临时文件同步到磁盘，并替换原有AOF文件。

你可能想知道在重写过程中，如何处理写入服务器的数据。新的数据将会写入到旧的（当前）AOF文件，同时进入一个内存队列，当新的AOF文件完成后，将这部分遗失的内容写入新的AOF文件，并最终替换旧的AOF文件。

你可以看到，所有写入仍旧是追加形式写入，重写AOF文件时，仍旧将所有内容写入旧的AOF文件。这意味着我们不必考虑AOF文件会重写。真正的问题是，写入的频率和fsync系统调用的频率。

AOF耐用性（durability）

我很高兴已经介绍完前面的内容，也很高兴你能坚持读到这里。

Redis AOF使用执行新命令填充的用户空间buffer。每次事件循环的最后，Redis使用write系统调用将这个buffer写入（flush）到磁盘。实际上，有三个不同的配置值可以修改write尤其是fsync的行为。

这三个值通过appendfsync配置项控制，可以设置为no, everysec, always。这个配置也可以在Redis运行时通过CONFIG SET命令修改，因此可以不必停止Redis运行即可修改。

appendfsync no

appendfsync配置为no时，Redis不会调用fsync。然而，它要保证客户端没有使用pipelining。也就是说，等待收到响应后发送后续命令的客户端将收到命令的响应，表明命令已经在Redis正确执行，相关修改已经通过以调用write系统调用将命令写入AOF文件描述符的方式传递给内核。

由于这个配置不会调用fsync。数据将完全由内核控制写入磁盘。对于Linux系统来说，每30秒写入一次。

appendfsync everysec

Redis使用这个配置调用write将数据写入文件，每秒调用一次fsync将数据从内核同步到磁盘。通常，每次事件循环结束时执行写入，但这个机制并不完全可信（not guaranteed）。

如果磁盘不能提供背景fsync调用的带宽需求，那么随后的fsync调用可能被延迟（以避免阻塞主线程）。如果两秒钟内fysnc仍旧没有完成，Redis最终会调用write将数据同步到磁盘。

appendfsync always

如果客户端没有使用pipelining，而是等待前一个命令的响应，那么Redis不仅将数据写入文件并使用fsync将数据同步到磁盘，完成后将命令执行结果返回给客户端。

这是现在Redis可能取得的最高级别的耐用性，但也是最慢的一个。

Redis默认的配置是appendfsync everysec，是考虑速度和耐用性的折中方案。

pipelining的不同之处

以不同方式处理使用pipelining的客户端的原因是为了提升效率，它执行下一条命令前，牺牲了读取某一命令结果的能力。这对响应不感兴趣只要求速度的客户端来说，返回响应前提交数据毫无意义。但对使用pipelining的客户端，Redis返回事件循环时总会有write和fsync调用。

AOF与Redis事务

AOF可以保证正确执行MULTI/EXEC事务，不会导入在文件末尾包含不完整事务的AOF文件，Redis提供工具删除AOF文件末尾不完整事务。

对比PostrgreSQL

以AOF默认配置作为持久化引擎时，Redis的耐用性如何呢？

最坏场景：保证write和sync在两秒钟内完成

正常场景：响应客户端前执行write, 每秒钟执行一次fsync.

这时Redis仍旧很快，一个原因是fsync在背景线程执行，另外一个原因是Redis只以追加模式写入文件，这是一个大的优势。

如果需要最大的数据安全性且写入量不大时，可以使用fsync always获取所有数据库可能得到的最强数据耐用性。

和PostgreSQL比如何呢？它是一个非常可靠的优秀数据库。

引用一下PostgreSQL文档：

fsync（布尔值）

当这个参数为on时，PostgreSQL将使用fsync或其等效方法尽力保证更新写入到物理磁盘。这保证在操作系统或者硬件崩溃后，数据库集群可以将数据恢复到一致状态。

所以PostgreSQL需要使用fsync保证不损坏数据。幸运的是，Redis不存在这种问题，不可能有数据损坏发生。

对于PostgreSQL来说，如果需要提升速度那么去使能同步提交。同样对redis来说，提升速度就不能配置appendfsync always。

在PostgreSQL中,去使能同步提交类似于Redis中的appendsync everysec. 写入物理磁盘的延迟延迟约为600毫秒，而Redis默认是1秒。

MySQL InnoDB有同样的配置参数 -innodb_flush_log_at_trx_commit。

长话短说，Redis虽然是内存数据库，但它和其他构建在磁盘基础上的数据库一样提供良好的耐用性。

实际上，Redis提供AOF和RDB快照，并可以同时使用（这也是建议配置），提供易用性和数据耐用性。

现在为止所有讨论的关于Redis耐用性的内容不仅可以适用于把Redis作为数据存储的场景，也适用于将Redis作为队列并可将数据持久化到磁盘保证良好耐用性的场景。