Redis的两种持久化方式AOF和RDB
Redis之所以速度这么快,是因为Redis是基于内存的数据库,进行读写操作时,redis都会先在内存中完成,然后定时的刷新到磁盘中去,RDB和AOF就是两种持久化内存中数据的方式。笼统来讲,RDB可以将某一时刻的所有数据写入硬盘中,相当于复制了一份数据;而AOF会在redis执行写命令时,将被执行的写命令复制到磁盘中,恢复数据的时候,redis会在原有基础上依次执行AOF文件中的写命令,从而恢复数据。
快照RDB
Redis将某一时刻的快照(备份的数据库数据)保存成一种称为RDB格式的文件中,这种格式是经过压缩的二进制文件。redis保存和恢复文件,如图1和图2所示:
保存RDB数据的命令有两种:一个是save,一个是bgsave,一般用的都是bgsave命令。
- save命令:save命令会阻塞redis服务器的进程,直到RDB文件创建完,在该期间,redis不能处理任何的命令请求,这就是save命令最大的缺陷。
- bgsave命令:与save命令不同的是,bgsave在生成RDB文件时,会派生出一个子进程,子进程负责创建RDB文件,在此期间,主进程和子进程是同时存在的,因此不会阻塞redis服务器进程。(可用lastsave命令查看生成RDB文件是否成功)。
自动保存RDB文件
除了特殊情况外,我们一般是不会直接使用命令来生成RDB文件的,redis提供了自动生成RDB文件的功能。redis提供了使用配置文件配置的方式每隔一段时间自动执行一次bgsave命令,配置在redis.conf中,例如下面三条命令,只要满足了一个,bgsave就会被执行:
save 900 1
save 300 10
save 60 10000
含义:
Redis 服务器在 900 秒之内,对数据库进行了至少一次修改
Redis 服务器在 300 秒之内,对数据库进行了至少 10 次修改
Redis 服务器在 60 秒之内,对数据库进行了至少 10000 次修改
另外,设计RDB文件的配置选项还有:
dbfilename dump.rdb
dir ./
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
含义:
dbfilename:配置 RDB 文件名称,一般叫dump.rdb
dir:配置 RDB 文件存放的路径
stop-writes-on-bgsave-error:当生成 RDB 文件出错时是否继续处理 Redis 写命令,默认为不处理
rdbcompression:是否对 RDB 文件进行压缩
rdbchecksum:是否对 RDB 文件进行校验和校验
RDB快照持久化数据的优缺点
优点:
- 采用子线程创建RDB文件,不会对redis服务器性能造成大的影响;
- 快照生成的RDB文件是一种压缩的二进制文件,可以方便的在网络中传输和保存。通过RDB文件,可以方便的将redis数据恢复到某一历史时刻,可以提高数据安全性,避免宕机等意外对数据的影响。
缺点:
-
在redis文件在时间点A生成,之后产生了新数据,还未到达另一次生成RDB文件的条件,redis服务器崩溃了,那么在时间点A之后的数据会丢失掉,数据一致性不是完美的好,如果可以接受这部分丢失的数据,可以用生成RDB的方式;
- 快照持久化方法通过调用fork()方法创建子线程。当redis内存的数据量比较大时,创建子线程和生成RDB文件会占用大量的系统资源和处理时间,对 redis处理正常的客户端请求造成较大影响。
AOF
AOF是redis对将所有的写命令保存到一个aof文件中,根据这些写命令,实现数据的持久化和数据恢复。
AOF配置
配置在redis.conf文件中,通过将appendonly:yes打开创建AOF文件功能。
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
含义:
- appendonly:是否打开 AOF 持久化功能
- appendfilename:AOF 文件名称
- appendfsync:同步频率
对于同步频率有三种方式:
- always:redis执行每个写命令时,都同步写入硬盘,这样会严重降低redis性能;
- everysec:每秒执行一次,显示的在这一秒内执行的写命令同步到硬盘;
- no:不同步到硬盘(让操作系统来决定何时进行同步)。
AOF文件生成机制
生成过程包括三个步骤:命令追加、文件写入、文件同步。
redis打开AOF持久化功能之后,redis在执行完一个写命令后,把执行的命令首先追加到redis内部的aof_buf缓冲区膜末尾,此时缓冲区的记录还没有写到appendonly.aof文件中。
然后,缓冲区的写命令会被写入到 AOF 文件,这一过程是文件写入过程。
对于操作系统来说,调用write函数并不会立刻将数据写入到硬盘,为了将数据真正写入硬盘,还需要调用fsync函数,调用fsync函数即是文件同步的过程,只有经过了文件的同步过程,写命令才真正的被保存到了AOF文件中。appendfsync 就是配置同步的频率的选项。
AOF重写
redis不断的将写命令保存到AOF文件中,导致AOF文件越来越大,当AOF文件体积过大时,数据恢复的时间也是非常长的,因此,redis提供了重写或者说压缩AOF文件的功能。
比如对key1初始值是0,调用incr命,100次,key1的值变为100,那么其实直接一句set key1 100 就可以顶之前的100次调用,AOF重写功能就是干这个事情的。
重写时,可以调用BGREWRITEAOF命令重写AOF文件,与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。
auto-aof-rewrite-percentage 100 #当前AOF文件大小和上一次重写时AOF文件大小的比值
auto-aof-rewrite-min-size 64mb #文件的最小体积
重写步骤:
- 创建子进程进行AOF重写
- 将客户端的写命令追加到AOF重写缓冲区
- 子进程完成AOF重写工作后,会向父进程发送一个信号
- 父进程接收到信号后,将AOF重写缓冲区的所有内容写入到新AOF文件中
- 对新的AOF文件进行改名,原子的覆盖现有的AOF文件
AOF优缺点
- 提供了多种同步命令的方式,默认1秒同步一次写命令,最多丢失1秒内的数据;
-
如果AOF文件有错误,比如在写AOF文件时redis崩溃了,redis提供了多种恢复AOF文件的方式,例如使用redis-check-aof工具修正AOF文件(一般都是最后一条写命令有问题,可以手动取出最后一条写命令);
- AOF文件可读性交强,也可手动操作写命令。
- AOF文件比RDB文件较大;
- redis负载较高时,RDB文件比AOF文件具有更好的性能;
-
RDB使用快照的方式持久化整个redis数据,而aof只是追加写命令,因此从理论上来说,RDB比AOF方式更加健壮,另外,官方文档也指出,在某些情况下,AOF的确也存在一些bug,比如使用阻塞命令时,这些bug的场景RDB是不存在的。
参考: |