走近Redis持久化：RDB和AOF

Redis持久化

Redis是一个内存数据库，如果服务器进程出现异常状态导致退出之后，服务器中的数据库状态也会消失，必须将内存中的数据状态持久化到硬盘中。因此，redis提供了数据持久化的功能。

RDB(Redis DataBase)

什么是RDB？

RDB就是在一段时间内达到一定的数据修改次数，就把内存中的数据集快照写入磁盘。Redis默认是开启RDB的，且会将快照保存到一个名为dump.rdb的文件中，该文件默认是与redis启动命令（redis-server）在同一目录下的。

RDB持久化的原理

Redis开启RDB时会fork一个子进程来处理数据的持久化。当持久化开始时，子进程将内存中的数据写入一个临时的RDB文件中，当持久化过程结束（数据集快照写入完成）后，临时的RDB文件会替代以前旧的RDB文件成为新的正式文件保存数据。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。

RDB的相关配置

#如果900s内，有至少1个key进行了修改，就进行持久化
save 900 1  
#如果300s内，有至少10个key进行了修改，就进行持久化
save 300 10
#如果60秒内，有至少10000个key进行了修改，就进行持久化
save 60 10000

stop-writes-on-bgsave-error yes #持久化如果出错，是否需要继续工作，默认是yes
rdbcompression yes # 是否压缩rdb文件，需要消耗一些cpu资源
rdbchecksum yes # 运行rdb文件时进行检查
dbfilename dump.rdb # rdb文件名字，默认是dump.rdb
dir ./ # rdb文件保存的目录，默认是redis的安装目录

RDB持久化的数据是如何恢复到内存中的呢？

Redis是基于内存的，所以需要将之前持久化的数据恢复到内存中，这也是设计持久化的初衷。

在不修改配置的情况下（一般情况就使用默认的配置）：

我们只需要将dump.rdb文件移动到redis安装目录下并启动服务即可，Redis启动时会自动加载rdb文件，阻塞式地将数据恢复。

什么情况会触发RDB？

RDB虽然是默认开启的，但是不一定会触发，需要满足一定的条件：

1. 满足配置文件中的save的规则时，关闭redis服务时rdb文件会出现在目录中

2. 执行save命令时，持久化后面所有的数据，会立刻生成rdb文件

3. 执行bgsave命令时，Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间，会立刻生成rdb文件

4. 执行flushall命令时，会立刻生成一个没有数据集的rdb文件，没有什么意义。
   
   

使用RDB的优缺点

优点：

1. 适合大规模的数据恢复
2. 对数据的完整性要求不高
3. 最大限度地提升了Redis的性能，在持久化的原理中有提到，父进程为了持久化创建了子进程，而其本身并不进行磁盘IO或者类似的操作。
4. RDB文件适合备份

缺点：

1. 需要一定的时间间隔进行操作，如果redis意外宕机，最后修改的数据就会丢失
2. RDB经常需要fork以便使用子进程在磁盘上持久化。如果数据集很大，fork可能会很耗时且cpu性能不是很好，可能会导致Redis停止为客户端停止服务一小段时间。这与Redis的高性能是相悖的。
   
   

AOF(Append Only File)

什么是AOF ？

以日志的形式保存所有的写操作（增删改），默认是保存到appendonly.aof文件中，这个文件和rdb文件一样默认是在redis的安装目录下的。再次启动Redis会读取该文件，把之前的命令执行一遍重构数据。

AOF默认是关闭的，需要手动配置开启。appendonly yes

我们开启aof来测试一下：

执行以下命令

来看看aof文件

AOF持久化的原理

和RDB类似，Redis会（fork）一个子进程，子进程将根据内存中的数据快照先将这部分数据的“写命令”写入临时的aof文件中；而父进程将新的“写命令”放入缓存，同时把“写命令”写入旧的aof文件中（如果子进程重写失败，依然能够保证数据的完整性）。当子进程完成写临时aof文件时，父进程会收到一个信号，并将内存缓冲区附加到子进程生成的aof文件的末尾，再用临时文件替代旧的aof文件并将其重命名，使其成为新的aof文件。

AOF数据持久化策略

AOF有三种持久化策略：

fsync：同步内存中所有已修改的文件数据到储存设备

appendfsync always：每次有“写命令”进入缓存，就进行一次fsync，性能较差，但是数据的完整性较好。

appendfsync everysec：默认策略。每秒执行一次fsync，足够快，和使用快照差不多，出现故障也只会丢失1秒内的数据。

appendfsync no：不使用fsync，把数据集交给操作系统来处理，由操作系统决定什么时候同步数据到aof文件中。

aof文件出问题了该怎么处理？

aof文件中如果存在错误，会导致redis无法正常启动！

可以使用redis-check-aof去修复aof文件redis-check-aof --fix

日志重写

随着“写命令"的堆积，aof文件会越来越大，当超过一定的阈值后，Redis就会对aof文件内容进行压缩（保留能够恢复数据集的最短命令序列），也叫日志重写。

手动触发：可以使用bgrewriteaof进行日志重写

自动触发：Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍，且文件大于64M时触发。64M有点小，一般会设置成较大的数值。

使用AOF的优缺点

优点：

1. ao可用性比较好，支持三种fsync策略。
2. 安全性较高，aof日志文件是仅能附加型，所以不存在断电后数据损坏的问题，就算日志文件在某种情况下（磁盘满了或者其他原因）导致命令以不完整形式结束，redis-check-aof 工具也能够轻松修复它。
3. 易于操作，aof文件存储的是我们能够看懂的命令，即使不小心使用了flushall命令刷新了所有内容，只要在此期间没有重写日志，我们可以通过停止服务器并删除最新的命令，再次启动服务器来恢复数据。

缺点：

1. 相对于rdb文件来说，aof文件所占内存是很大的，修复数据的速度也会更慢
2. aof运行效率可能比rdb慢，具体取决于fsync策略

如何选择持久化的方式

RDB和AOF各有利弊，我们该怎样去选择持久化的方式呢？

如果需要数据的安全性与PostgreSQL相当，那么可以同时开启RDB和AOF。同时开启两种持久化方式时，Redis重启时会有限加载aof文件来恢复数据，因为通常情况下aof文件保存的数据集更完整。

如果可以忍受Redis出现宕机时丢失几分钟的数据，可以只使用RDB。

那么能不能单独使用AOF呢？

可以，但是官方不建议单独使用AOF，因为RDB更适用于数据库备份，Redis快速启动而且不会出现AOF潜在的bug，可以拿来作为一种兜底的手段。

当然，如果Redis只用来做缓存，即只希望数据在服务器运行时存在，那么可以不采用任何持久化。