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作为队列并可将数据持久化到磁盘保证良好耐用性的场景。


上一篇:CI(CodeIgniter)框架中的增删改查操作


下一篇:Django中ORM表的创建以及基本增删改查