煮酒听雨

Redis持久化：快照(RDB)和AOF简解

编辑时间：2018-06-16 编辑：忘尘阅读：1137

简述: Redis之所以速度这么快，是因为Redis是基于内存的数据库，进行读写操作时，redis都会现在内存中完成，然后定时的刷新到磁盘中去，快照(RDB)和AOF就是两种持久化内存中数据的方式。RDB快照可以将某一时刻的所有数据写入硬盘中，相当于复制了一份数据；而AOF会在redis执行写命令时，将被执行的写命令复制到磁盘中，恢复数据的时候，redis会在原有基础上依次执行AOF文件中的写命令，从而恢复数据。

#### 1、快照持久化(RDB)
Redis将某一时刻的快照（备份的数据库数据）保存成一种称为RDB格式的文件中，这种格式是经过压缩的二进制文件，默认开启。

手动保存RDB数据的命令有两种，一个是save，一个是bgsave，一般用的都是bgsave命令。
- save
save命令会阻塞redis服务器的进程，直到RDB文件创建完，在该期间，redis不能处理任何的命令请求，这就是save命令最大的缺陷。
- bgsave
与save命令不同的是，bgsave在生成RDB文件时，会派生出一个子进程，子进程负责创建RDB文件，在此期间，主进程和子进程是同时存在的，因此不会阻塞redis服务器进程。

但一般是不会直接手动使用命令来生成RDB文件的，redis提供了自动生成RDB文件的功能。
redis提供了使用配置文件配置的方式每隔一段时间自动执行一次bgsave命令，配置在redis.conf中，例如下面三条命令，只要满足了一个，bgsave就会被执行。

``` linux
#快照持久化的备份频率配置
save 900 1       #900秒内进行了至少1次修改
save 300 10      #300秒内进行了至少10次修改
save 60 10000    #60秒内进行了至少10000次修改

#相关配置
dbfilename dump.rdb              #配置 RDB 文件名称，一般叫dump.rdb    
dir ./                           #配置 RDB 文件存放的路径（./ 以启动redis服务时所在目录为准）
stop-writes-on-bgsave-error yes  #当生成RDB 文件出错时是否继续处理 Redis 写命令，默认为不处理
rdbcompression yes               #是否对 RDB 文件进行压缩
rdbchecksum yes                  #是否对 RDB 文件进行校验和校验
```

> 其中 dump.rdb 或 appendonly.aof 存放位置是不固定的，默认是存放在启动redis时的当前目录，建议更改成指定目录，这样就不会存在每次启动服务时所在的目录不一样导致dump文件找不到的问题

#### 2、AOF持久化
AOF是redis对将所有的写命令保存到一个aof文件中，根据这些写命令(添加、修改、删除)，实现数据的持久化和数据恢复。

在redis.conf文件中配置
```
appendonly yes

#相关配置
appendfilename "appendonly.aof"
# appendfsync always      #每次有一个写命令,就把命令存入aof文件里
appendfsync everysec      #每秒存入aof文件一次(建议选用)
# appendfsync no          #不同步到硬盘aof文件（让操作系统来决定何时进行同步）
```
AOF优势:
- 提供了多种同步命令的方式，默认1秒同步一次写命令，最多会丢失1秒内的数据

AOF劣势:
- aof文件的体积可能会很大(可能比快照文件还大)
- 在系统重启的时候回从aof里读命令,如果aof文件太大,读命令也就需要较长时间

------------

#### 数据恢复机制
有关redis恢复机制，即在开启aof并且存在文件的情况下，优先从aof文件中恢复

- 如果只配置 AOF ，重启时加载 AOF 文件恢复数据
- 如果同时配置了 RDB 和 AOF ，启动是只加载 AOF 文件恢复数据
- 如果只配置 RDB，启动是将加载 dump 文件恢复数据

##### 相关文章
https://my.oschina.net/davehe/blog/174662

来说两句吧