Redis持久化

1、RDB（Redis DataBase）

1.1 概念

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

1.2 备份是如何执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化进程都结束了，再使用临时文件替代上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不敏感，那RDB方式要比AOF方式更加高效，但是可能会造成最后一次持久化后的数据丢失。

1.3 Fork

• Fork的作用是复制一个与当前进程同样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是这个全新的进程，作为原进程的子进程。
• fork()会产生一个和父进程完全相同的子进程，但子进程在此后会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”。
• 一般情况下父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发送变化时，才会将父进程的内容复制一份给子进程。

1.4 RDB持久化流程

1. 执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如果存在则直接返回。
2. 父进程fork一个子进程（forK的过程中会造成阻塞的情况），这个过程可以使用info stats命令查看latest_fork_usec选项，查看最近一次fork操作消耗的时间，单位是微秒。
3. 父进程fork完之后，则会返回Background saving started信息提升，此时fork阻塞解除。
4. fork出的子进程开始根据父进程内存数据生成临时的快照文件，然后替换原文件。使用lastsave命令可以查看最后生成rdb的时间，对于info的rdb_last_save_time选项。
5. 当备份完毕之后向父进程发送完成消息，具体可见info persistence下的rdb_*选项。

1.5 RDB相关的配置

# RDB的文件名，默认为dump.rdb
dbfilename dump.rdb

# rdb文件保存路径，默认为Redis启动时命令行所在的目录下
dir ./

# 默认的触发快照配置
# 3600秒最少一个key发送变化
save 3600 1
save 300 10
save 60 10000

# 当Redis无法写入磁盘时，直接关闭Redis的写操作，推荐yes。
stop-writes-on-bgsave-error yes

# 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果值为yes，redis会采用LSF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以关闭此功能。推荐yes。
rdbcompression yes

# 在存储快照后，还可以让redis使用CRC64算法来进行数据校验。但是这样会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。推荐yes。
rdbchecksum yes
复制代码

1.6 优势VS劣势

1.6.1 优势

• RDB是某一时间点的快照，是一个紧凑的单个文件，更多用于数据备份。可以按每小时或媒体来备份，方便从不同的版本恢复时间。
• 单文件容易传输到远程服务做故障恢复。
• 文件采用压缩的二进制文件，当重启服务时加载数据文件，比AOF方式更快。

1.6.2 劣势

• RDB采用加密的二进制格式存储文件，由于Redis各个版本之间的兼容性问题可能导致RDB文件在其他版本使用不了。
• Redis在fork时虽然使用写时拷贝技术，但是数据量大时，消耗性能会比较大。
• 在备份周期在一定间隔时间做一次备份，如果Redis意外down掉的话，会丢失最后一次快照后的所有修改。

1.7 其他

1.7.1 save VS bgsave

• save：save只管保存，其他命令全部阻塞。手动保存，不建议。
• bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。

1.7.2 动态停止RDB持久化

redis-cli config set save " "
复制代码

同理，其他动态配置config:

redis-cli config set XX
复制代码

2、AOF（Append Only File）

2.1 概念

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

2.2 AOF持久化流程

1. 客户端的请求写命令会被append追加到AOF缓冲区内；
2. AOF缓冲区根据AOF持久化策略[always, everysec, no]将操作sync同步到磁盘的AOF文件中。
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量。
4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的。

2.3 AOF同步频率设置

• appendfsync always：始终同步，每次Redis的写入都会立刻记录日志；性能较差但数据完整性好。
• appendfsync everysec（默认）：每秒同步，每秒记录日志一次，如果宕机，本秒的数据可能丢失。
• appendfsync no：Redis不主动进行同步，把同步时机交给操作系统。

2.4 Rewrite压缩

2.4.1 概念

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

2.4.2 原理

AOF文件持续增长而过大时，会fork出一个新进程来将文件重写（也是先写临时文件最后再rename），redis4.0版本后的重写，是指把rdb的快照，以二进制的形式附在新的AOF头部，作为已有的历史数据，替换掉原来的流水账操作。

• no-appendfsync-on-rewrite：

• 如果no-appendfsync-on-rewrite=yes，不写入AOF文件只写入缓存，用户请求不会阻塞，但是在这段时间宕机会丢失这段时间的缓存数据（降低数据安全性，提高性能）。
• 如果no-appendfsync-on-rewrite=no，还是会把数据往磁盘里刷，但是遇到重写操作，可能会出现阻塞（数据安全，但是性能降低）。

2.4.3 触发机制

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

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写会有一定的负担，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，默认为文件达到100%时开始重写（文件是原来重写后文件的2倍）。

auto-aof-rewrite-min-size：设置重写的基准值，默认为64MB。两个配置都符合则开始重写。

系统载入时或上次重写完毕时，Redis会记录此时AOF大小，设为base_size，如果Redis的AOF当前大小 >= base_size + base_size * 100%（默认）取当前大小 >= 64MB（默认）的情况下，Redis会对AOF进行重写。

2.4.4 重写流程

1. bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后在继续执行。
2. 主进程fork出子进程执行重写操作，保证主进程不会阻塞。
3. 子进程遍历Redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓存区和aof_rewrite_buf重写缓存区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

4.1 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
4.2 主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
5. 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

2.5 优势VS劣势

2.5.1 优势

• 备份机制更稳健，丢失数据概率小。
• 可读性强，由于使用的是文本协议格式来存储的数据，可直接查看命令。

2.5.2 劣势

• 相比于RDB占用更多的磁盘空间。
• 恢复备份速度更慢。
• 在大量写入和载入的时候，AOF的效率会比RDB低。

3、 官方建议

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾。
• 只做缓存：如果只希望你的数据在服务器运行的时候存在，可以不使用任何持久化。
• 建议同时开启两种持久化方式。两种同时开启的情况下，当Redis重启的时候会优先载入AOF文件来恢复原始的数据，意外在通常情况下AOF文件保存的数据要比RDB文件保存的数据要完整。
• 建议不要只开启AOF方式。因为RDB更适合用于备份数据库（AOF会不断变化），而且不会有AOF可能潜在bug。
• 因为RDB文件只作为后备用途，建议只在slave上持久化RDB文件，而且只要15分钟备份一次就够看，只保留save 900 1这条规则。
• 如果使用AOF，好处在于最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单load AOF文件就行了。而所带来的代价：一是带来了持续的IO，而是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞是不可避免的。所以只要硬盘许可，应该尽量减少AOF rewrite的频率。