Redis之持久化

1.RDB持久化

1.1 RDB持久化配置

Redis默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即生成一个dump.rdb文件，Redis服务重启后会重新加载此文件，完成持久化操作。可以把rdb文件想象成持久化文件，用于记录Redis的写操作。

#
# Save the DB on disk:
#
#   save <指定时间间隔> <执行指定次数更新操作>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#   
#   save ""

save 900 1
save 300 10
save 60 10000

若想关闭RDB持久化，则需要开启 save ""，其他的配置注释掉即可。

以下配置用于指定持久化文件名称。

# The filename where to dump the DB
dbfilename dump.rdb

以下配置用于指定持久化文件的路径：

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

配置数据是否压缩：

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

1.2 RDB持久化测试

设置以下配置：

save 10 1

表示10s内有一次写操作就进行一次持久化。然后进行set操作。

set rdbKey rdbValue

然后kill掉Redis的进程，删除dump.rdb文件，重启启动后就会发现redis里面没有了键名为rdbKey的字符串值。说明Redis在启动的时候没有加载到dump.rdb，所以缓存数据也就丢失了。

redis-check-dump 命令 用于检测快照文件的状态，对于快照文件，由于RDB文件经过压缩，可能无法通过这个命令来扫描出错误的执行指令，所以在使用RDB持久化的时候，尽可能的多备份RDB文件。

如何触发：

• 在指定的时间间隔内，执行指定次数的写操作，也就是redis.conf配置。
• 执行save（同步阻塞， 保存快照，其他的等待） 或者是bgsave （异步）命令。
• flushall 命令，清空数据库所有数据，不推荐使用。
• shutdown 命令，保证服务器正常关闭且不丢失任何数据。
• keys * 匹配数据库中所有 key。

1.3 RDB持久化优点及缺点

优点：

• 适合大规模的数据恢复，如灾难恢复
• 如果业务对数据完整性和一致性要求不高，RDB是很好的选择
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

缺点：

• 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
• 备份时占用内存，因为Redis 在备份时会独立fork出一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍），最后再将临时文件替换之前的备份文件。所以Redis 的持久化和数据的恢复要在请求量少的时候进行比较合理的。

2.AOF持久化

AOF 持久化是将被执行的命令追加到AOF文件后面，以此来记录数据的变化。所以只要从头到尾执行一次AOF文件的命令，就可以恢复AOF的记录的数据集。AOF持久化主要通过以下几点配置：

2.1AOF持久化配置

AOF持久化启用开关，默认是no：

appendonly no

指定本地数据库文件名，默认值为 appendonly.aof

appendfilename "appendonly.aof"

指定更新日志条件

# appendfsync always
appendfsync everysec
# appendfsync no

默认是everysec。一共有三种选项。

选项类型	含义
always	每个redis的写命令都要同步写入硬盘，可以保持数据完整性，影响性能。
everysec	出厂默认推荐，每秒异步记录一次（默认值）
no	把同步的权利交由操作系统控制

使用everysec进行每秒同步一次aof文件和不使用持久化的情况下性能相差无几。即使出现系统崩溃的情况，也就会丢失一秒的数据，同时，redis也会根据硬盘的写操作的速度来控制aof持久化同步的速度。

2.2AOF持久化优点及缺点

优点：

将数据丢失的时间窗口降低至1秒，而且可以快速的进行定期的持久化操作。

缺点：

随着写命令一直追加到aof文件里，就会导致aof文件越来越大，一是占用了太多的空间，二是执行aof文件加载的操作就会更加耗时。

2.3AOF持久化重写机制

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

表示当aof文件的体积大于64m，并且aof文件的体积比上一次重写之后的体积大了至少一倍的时候，redis将执行BGREWRITEAOF命令。BGREWRITEAOF命令的原理和BGSAVE类似，同样是fork出一个子进程负责对aof文件的重写，主要是通过异常aof文件中冗余的命令来实现，所以它最终的结果会尽可能的缩小aof文件的内容。

redis-check-aof 用于检测和修复aof文件，它的主要原理是扫描aof文件，当发现不完整或者不正确的命令时，将错误的命令之后的所有命令进行删除，只保留出错之前的命令。

总结

• Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
• RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
• AOF默认关闭，若要开启需要手工配置操作。
• AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
• 若只打算用Redis 做缓存，可以关闭持久化。
• 若打算使用Redis 的持久化。建议RDB和AOF都开启。