Redis的RDB与AOF

Redis持久化的必要性

首先要明白redis是一个数据库, redis是一个内存数据库, 所有数据基本上都存在于内存当中, 会定时以追加或者快照的方式刷新到硬盘中. 由于redis是一个内存数据库, 所以读取写入的速度是非常快的, 所以经常被用来做数据, 页面等的缓存。

由于Redis的数据都存放在内存中,如果没有配置持久化,redis重启后数据就全丢失了,即便是重启后数据也无法很快恢复，而此时可能会有大量请求找到DB，DB扛不住，也就会出现所谓的“缓存雪崩”问题。

于是需要开启redis的持久化功能,将数据保存到磁盘上,当redis重启后,可以从磁盘中恢复数据。

Redis持久化的两种机制

1、RDB持久化

RDB是将当前数据生成快照保存到硬盘上。

RDB的工作流程：

• 执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
• 父进程执行fork操作创建子进程，fork操作过程中父进程被阻塞。（注意：父进程会被阻塞）
• 父进程fork完成后，bgsave命令返回“* Background saving started by pid xxx”信息，并不再阻塞父进程，可以继续响应其他命令。
• 父进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。根据lastsave命令可以获取最近一次生成RDB的时间，对应info Persistence中的rdb_last_save_time。
• 进程发送信号给父进程表示完成，父进程更新统计信息。

触发机制：

（1）手动触发

• 使用save命令：此命令会使用Redis的主线程进程同步存储，阻塞当前的Redis服务器，造成服务不可用，直到RDB过程完成。无论当前服务器数据量大小，线上不要用。
• 使用bgsave命令：此命令会通过fork()创建子进程，在后台进程存储。只有fork阶段会阻塞当前Redis服务器，不必到整个RDB过程结束，一般时间很短。因此Redis内部涉及到RDB都采用bgsave命令。这里注意一点，无论RDB还是AOF，由于使用了写时复制，fork出来的子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。

（2）自动触发

  Redis支持自动触发RDB持久化机制，配置都在redis.conf文件里面，看一下该配置文件中的

save 900 1
save 300 10
save 60 10000
#
stop-writes-on-bgsave-error yes
#
rdbcompression yes
#
rdbchecksum yes
#
dbfilename dump.rdb
#
dir /usr/local/var/db/redis/

• save m n：代表Redis服务器在m秒内数据存在n次修改时，自动触发rdb。这个参数比较关键。
• stop-writes-on-bgsave-error：如果是yes，当bgsave命令失败时Redis将停止写入操作。
• rdbcompression：是否对RDB文件进行压缩，但是在LZF压缩消耗更多CPU
• rdbchecksum：是否对RDB文件进程校验
• dbfilename：配置文件名称，默认dump.rdb
• dir：配置rdb文件存放的路径，这个参数比较重要。

RDB的优缺点：

• 因为bgsave每次运 行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。所以不适用于实时持久化
• 但是其数据体量小，执行速度快，适合备份。

2、AOF持久化

AOF以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令来恢复数据。AOF的主要作用 是解决了数据持久化的实时性

AOF的工作流程：

• 所有的写入命令追加到aof缓冲区
• AOF缓冲区根据对应appendfsync配置向硬盘做同步操作
• 定期对AOF文件进行重写
• Redis重启时，可以加载AOF文件进行数据恢复

触发机制：

（1）手动触发

 使用bgrewriteaof命令：Redis主进程fork子进程来执行AOF重写，这个子进程创建新的AOF文件来存储重写结果，防止影响旧文件。因为fork采用了写时复制机制，子进程不能访问在其被创建出来之后产生的新数据。Redis使用“AOF重写缓冲区”保存这部分新数据，最后父进程将AOF重写缓冲区的数据写入新的AOF文件中，然后使用新AOF文件替换老文件。

（2）自动触发

和RDB一样，配置在redis.conf文件里

appendonly no
#
appendfilename "appendonly.aof"
#
appendfsync everysec
#
no-appendfsync-on-rewrite no
#
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
#
aof-load-truncated yes
#
aof-use-rdb-preamble no

• appendonly：是否打开AOF持久化功能
• appendfilename：AOF文件名称
• appendfsync：同步频率
• auto-aof-rewrite-min-size：如果文件大小小于此值不会触发AOF，默认64MB
• auto-aof-rewrite-percentage：Redis记录最近的一次AOF操作的文件大小，如果当前AOF文件大小增长超过这个百分比则触发一次重写，默认100

这里介绍一下appendfsync参数的可配置值

• always：命令写入aof缓冲区后，每一次写入都需要同步，直到写入磁盘（阻塞，系统调用fsync）结束后返回。显然和Redis高性能背道而驰，不建议配置
• everysec：命令写入aof缓冲区后，在写入系统缓冲区直接返回（系统调用write），然后有专门线程每秒执行写入磁盘（阻塞，系统调用fsync）后返回
• no：命令写入aof缓冲区后，在写入系统缓冲区直接返回（系统调用write）。之后写入磁盘（阻塞，系统调用fsync）的操作由操作系统负责，通常最长30s

打开AOF功能把appendonly值改为yes即可。

AOF优缺点：

• 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
• AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据 如果你要保证一条数据都不丢失，也是可以的，将AOF的fsync设置为没写入一条数据就fsync一次，但是Redis的性能将会大幅度下降。
• AOF的持久化也可能会造成阻塞。

扩展：

AOF重写的流程。

• 执行AOF重写请求。
• 如果当前进程正在执行bgsave操作，重写命令会等待bgsave执行完后再执行。
• 父进程执行fork创建子进程。
• fork操作完成后，主进程会继续响应其它命令。所有修改命令依然会写入到aof_buf中，并根据appendfsync策略持久化到AOF文件中。
• 因fork操作运用的是写时复制技术，所以子进程只能共享fork操作时的内存数据，对于fork操作后，生成的数据，主进程会单独开辟一块aof_rewrite_buf保存。
• 子进程根据内存快照，按照命令合并规则写入到新的AOF文件中。每次批量写入磁盘的数据量由aof-rewrite-incremental-fsync参数控制，默认为32M，避免单次刷盘数据过多造成硬盘阻塞。
• 新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。
• 父进程将aof_rewrite_buf（AOF重写缓冲区）的数据写入到新的AOF文件中。
• 使用新AOF文件替换老文件，完成AOF重写。
• 实际上，当Redis节点执行完一个命令后，它会同时将这个写命令发送到AOF缓冲区和AOF重写缓冲区。