RDB（Redis DataBase）

通过Snapshot快照进行持久化

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

整个过程中，主进程是不进行任何IO操作的。 这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失

在配置文件中的SNAPSHOTTING配置

1
2
3
4
5
6
7
8
9
10
11

# The filename where to dump the DB
dbfilename dump.rdb      # 文件名

# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 change was performed
#   * After 300 seconds (5 minutes) if at least 100 changes were performed
#   * After 60 seconds if at least 10000 changes were performed
#
# You can set these explicitly by uncommenting the following line.
#
# save 3600 1 300 100 60 10000      # 持久化规则

优点：

• 适合大规模的数据恢复
• 对数据完整性要求不高

缺点：

• 需要一定时间间隔进行操作，意外宕机最后一次修改则会丢失
• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

AOF（Append Only File）

将所有命令都记录下来，恢复时则全部执行一遍（读取操作不记录）

默认是不开启的

1
2
3
4
5
6
7
8
9
10
11
12

appendonly no

appendfilename "appendonly.aof"
appenddirname "appendonlydir"

# appendfsync always
appendfsync everysec
# appendfsync no

no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

重写规则

当aof文件的大小超过设定值时，Redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集

重写原理：

aof文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件

触发机制：

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

校验机制

如果aof文件错误则启动不了redis，需要修复文件

1

redis-check-aof --fix 文件名

如果文件正常，重启就能恢复

优点：

• 每一次修改都同步，文件完整性更好
• 每秒同步一次可能会丢失1s的数据
• 从不同步效率是最高的

缺点：

• 相对于数据文件来说，aof远大于rdb，修复速度也慢于rdb
• 运行效率低