Redis的持久化

Persistence

RDB（Redis Database）

在指定的时间间隔内将内存的数据集体快照写入磁盘，也就是Snapshot快照，恢复时是将快照文件直接读到内存里。

Redis会单独创建Fork一个子进程来进行持久化，会先将数据写入到一个临时文件dump.rdb中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。dump.rdb会自动加载到内存（只要redis启动时路径下存在dump.rdb就会自动恢复）。

执行shutdown和flushall时会迅速生成dump.rdb。

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后数据可能丢失。

配置位置：redis.conf snapshotting;save seconds changes；修改完成要重启redis生效。

save或bgsave 命令也会直接调用备份。save时阻塞。bgsave是在后台异步快照，快照时还是可以相应客户端请求。

除此以外还有一些配置，如stop-write-on-bgsave-error保护dump.rdb不在硬盘故障时生成，rdbcompression进行压缩，rdbchecksum验证可用性，以及默认文件名及路径。

优势：

劣势：

redis-cli config set save “” 停止RDB保存（不建议）

redis-check-dump –fix 可以修复dump文件

AOF（Append Only File）

与RDB协作

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

开关在redis.conf中

默认是关闭

默认文件名为appendonly.aof，可以以文本形式打开。

rdb和aof是可以共存的，aof文件如果被破坏redis就无法正常启动。

修复aof文件：redis-check-aof –fix appendonly.aof

appendfsync：

auto-appendsync-on-rewrite：重写时是否可以运用appendfsync，用默认no即可，保证数据安全性

aof启动/修复/恢复：

rewrite

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

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

redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

优势

配置灵活，较rdb方式丢数据概率低

劣势

RDB or AOF

如果只希望数据在服务器运行的时候存在，可以不使用任何持久化方式。

同时开启两种持久化方式：

通常情况下，redis重启优先载入aof文件来恢复原始数据

因为在通常情况下，aof文件保存的数据集要比rdb文件保存的数据集要完整。

rdb数据不实时，同时使用两者时服务器重启也只会找aof文件。建议不要只使用aof文件，因为rdb更适合用于备份数据库（aof在不断变化不好备份），快速重启；而且不会有aof可能潜在的bug。