Redis学习笔记——持久化RDB和AOF

RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读入到内存里。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。
RDB的缺点是最后一次持久化后的数据可能丢失。

fork

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全进的进程，并作为原进程的子进程。

dump.rdb文件

RDB保存的是dump.rdb文件。

配置文件

redis.conf中搜索SNAPSHOTTING，即使该功能模块的配置。
save <seconds> <changes>，在seconds秒内发生changes次改变，则进行数据保存。
默认：一分钟改了10000次，5分钟改了10次，15分钟改了一次，都会出发RDB快照。
注意：进行shutdown时，会自动保存一次dump.rdb，最后的更改是保留的。

数据恢复

拷贝出dump.rdb到远程备份机，需要恢复时，拷贝回来，覆盖dump.rdb，启动服务即可恢复。

触发RDB快照

（1）配置文件中默认的快照配置【冷拷贝后重新使用（远程备份机）】
（2）使用save命令，save只管保存，其他不管，全部阻塞。
（3）使用bgsave命令，Redis会在后台异步进行快照操作，快照同时可以响应客户端的请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
（3）使用FLUSHALL命令，立刻清空保存（无意义）。

恢复数据

（1）将备份文件（dump.rdb）移动到redis安装目录并启动服务即可。
（2）config get dir，获取目录

优势

（1）适合大规模的数据恢复
（2）对数据完整性和一致性要求不高

劣势

（1）在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。
（2）Fork的时候，内存中的数据被克隆了一份，2倍的膨胀性需要考虑。

如何停止RDB

redis-cli config set save ""，通过设置空串，进行停止RDB。

RDB总结

AOF（Append Only File）

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重构数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作。

配置开启AOP

appendonly

在redis.conf中，找到appendonly no（默认关闭）改为appendonly yes。

appendfilename

AOF模式的文件名。

共存

RDB和AOF是可以共存的，Redis会先加载AOF，若AOF文件出错，则Redis服务启动失败。

AOF文件修复

使用命令redis-check-aof --fix appendonly.aof，进行文件修复，在尝试启动（工程上请先备份）。

ReWrite

AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用bgrewriteaof。

重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后在rename），遍历新进程的内存中的数据，每条记录有一条set语句。重写AOF文件额时候，并没有读取旧的aof文件
，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

触发机制

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。在redis.conf中有如下默认配置：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

优势

每修改同步：appendfsync always 同步持久化，性能差但完整性好。
每秒同步：appendfsync everysec 异步操作，每秒记录。
不同步：appendfsync no

劣势

（1）相同数据集的数据而言AOF文件要远大于RDB文件，恢复速度慢于RDB。
（2）AOF运行效率要慢于RDB，每秒同步策略效率较好，不同步效率和RDB相同。

AOF总结

总结

（1）RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储。
（2）AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来回复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾。
（3）Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

场景

只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不适用任何持久化方式。
同时开始两种持久化方式：
在这种情况下，当redis重启的时候回优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据要比RDB文件保存的数据集更完整。
RDB的数据不实时，同时使用两者时，服务器重启也只会找AOF文件。

要不要只使用AOF

不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的BUG，留着以防万一（只是损失一段时间的数据）。

性能建议