redis(18):持久化-AOF方式

继续看redis持久化的第二种方式 AOF

一、概述

当使用Redis存储非临时数据时,一般需要打开AOF持久化来降低进程中止导致的数据丢失。

AOF可以将Redis执行的每一条写命令追加到硬盘文件中,这一过程显然会降低Redis 的性能,但是大部分情况下这个影响是可以接受的,另外使用较快的硬盘可以提高AOF的性能。


二、开启AOF

默认情况下Redis没有开启AOF(append only file)方式的持久化,可以通过 appendonly 参数启用:

appendonly yes

开启AOF持久化后每执行一条会更改Redis中的数据的命令,Redis就会将该命令写入硬 盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同,都是通过dir参数设置的,默 认的文件名是appendonly.aof,可以通过appendfilename参数修改:

appendfilename appendonly.aof

三、AOF的实现

AOF文件以纯文本的形式记录了Redis执行的写命令,例如在开启AOF持久化的情况下执 行了如下4个命令:

SET foo 1 
SET foo 2 
SET foo 3 
GET foo 

Redis会将前3条命令写入AOF文件中,此时AOF文件中的内容如下:

*2
$6
SELECT 
$1
0
*3
$3
set 
$3
foo 
$1
1
*3
$3
set 
$3
foo
$1
2
*3
$3
set 
$3
foo 
$1
3

可见 AOF文件的内容正是 Redis 客户端向 Redis 发送的原始通信协议的内容,从中可见 Redis确实只记录了前3条命令。然而这时有一个问题是前2条命令其实都是冗余的,因为这两条的执行结果会被第三条命令覆盖。随着执行的命令越来越多,AOF文件的大小也会越来越 大,即使内存中实际的数据可能并没有多少。
很自然地,我们希望 Redis 可以自动优化AOF 文件,就上例而言,就是将前两条无用的记录删除,只保留第三条。实际上Redis也正是这样 做的,每当达到一定条件时Redis就会自动重写AOF文件,这个条件可以在配置文件中设置:

  • auto-aof-rewrite-percentage 100 //当目前的AOF文件大小超过上一次重写时的 AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF文 件大小为依据
  • auto-aof-rewrite-min-size 64mb //限制了允许重写的最小AOF文件大小,通常在 AOF文件很小的情况下即使其中有很多冗余的命令我们也并不太关心

除了让Redis自动执行 重写外,我们还可以主动使用BGREWRITEAOF命令手动执行AOF重写。

上例中的AOF文件重写后的内容为:

*2
$6
SELECT 
$1
0
*3
$3
SET 
$3
foo 
$1
3

可见冗余的命令已经被删除了。重写的过程只和内存中的数据有关,和之前的 AOF文件 无关,这与RDB很相似,只不过二者的文件格式完全不同。
在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中,载入的速度相较RDB会慢一些


四、同步硬盘数据

虽然每次执行更改数据库内容的操作时,AOF都会将命令记录在AOF文件中,但是事实 上,由于操作系统的缓存机制,数据并没有真正地写入硬盘,而是进入了系统的硬盘缓存。 在默认情况下系统每30秒会执行一次同步操作,以便将硬盘缓存中的内容真正地写入硬盘, 在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来讲启用AOF持 久化的应用都无法容忍这样的损失,这就需要Redis在写入AOF文件后主动要求系统将缓存内 容同步到硬盘中。在 Redis 中我们可以通过 appendfsync 参数设置同步的时机:

#appendfsync alway s 
appendfsync everysec 
#appendfsync no 

默认情况下Redis采用everysec规则,即每秒执行一次同步操作。always表示每次执行写 入都会执行同步,这是最安全也是最慢的方式。no表示不主动进行同步操作,而是完全交由 操作系统来做(即每30秒一次),这是最快但最不安全的方式。一般情况下使用默认值 everysec就足够了,既兼顾了性能又保证了安全。
Redis 允许同时开启 AOF 和 RDB,既保证了数据安全又使得进行备份等操作十分容易。 此时重新启动Redis后Redis会使用AOF文件来恢复数据,因为AOF方式的持久化可能丢失的 数据更少。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 酷酷鲨 设计师:CSDN官方博客 返回首页