Redis持久化机制（RDBAOF详解）

一、Redis持久化介绍

Redis的数据都存放在内存中，如果没有配置持久化，Redis重启后数据就丢失了，于是需要打开Redis的持久化功能，将数据保存到磁盘上，当Redis重启后，可以从磁盘中恢复数据。

---

二、Redis持久化方式

1、RDB持久化

(1) 介绍

RDB持久化能在指定的时间间隔对你的数据进行快照存储。客户端直接通过命令bgsave或者save来创建一个内存快照。

• bgsave调用fork来创建一个子进程，子进程负责将快照写入磁盘，而父进程则继续处理命令。
• save执行过程中，不再响应其它命令。

在redis.conf文件中调整save配置选项，当在规定的时间内，Redis发生了写操作的个数满足条件会触发bgsave命令。

注意：900秒和300秒的意思是Redis每隔900秒、300秒检查写的次数。

(2) RDB持久化触发机制

手动触发：

• 通过save命令：会阻塞当前Redis服务器，直到生成完RDB文件，内存比较大的实例会造成长时间的阻塞。
• 通过bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，阻塞只发生在fork阶段。

被动触发：
配置文件中开启save seconds number配置，自动触发bgsave。从节点执行全量复制，主节点自动执行bgsave生成rdb文件。

备注：默认情况下客户端执行shutdown命令，如果没有开启aof持久化则自动执行bgsave。

(3) RDB优点和缺点

(4) RDB流程

1. Redis Fork一个子进程，此时有父、子两个进程。
2. 子进程开始写入数据集到临时的RDB文件中。
3. 子进程完成写入新的RDB文件后，替换掉旧的。

备注：这种方式利用了写时复制。

---

2、AOF(append only file)持久化

(1) 介绍

AOF持久化记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复复原始的数据。

注意：建议使用默认的策略每秒同步，这种策略相对快且安全。

(2) AOF优点和缺点

补充：

• 相同数据集AOF文件通常比RDB大。
• AOF持久化更慢，取决与具体的fsync策略。
• 如果重写过程中有写的请求，AOF可能需要更多的内存。
• 重写过程中，所有写的命令会刷到磁盘两次。

(3) AOF文件重写

不断的写入操作会导致AOF文件越来越大，例如：如果使用incr命令对某个key累加100次，最后的值为100，但AOF文件中会有100条记录，前面99条实际上是无用的。

因此Redis支持一个特性：后台重建AOF，而不影响对外服务，通过发起BGREWRITEAOF命令可以实现AOF文件重写。

在Redis2.2版本中使用AOF每次都需要运行BGREWRITEAOF命令，Redis2.4版本通过配置可以触发自动重写，自动重写默认配置项如下：

• auto-aof-rewrite-percentage 100：如果当前aof文件大小与上次重写后AOF文件大小的增长百分比为100%，则进行触发BGREWRITEAOF进行自动重写，例如：上次重写后AOF文件大小为5m，当前AOF文件大小为10m，增长百分比为(10-5)/5=100%。
• auto-aof-rewrite-min-size 64mb：为了避免符合增长百分比触发AOF重写，但AOF文件仍然很小的情况，可以指定重写时的最小文件大小，只有两项条件都满足才触发AOF重写。

(4) AOF文件重写流程

AOF文件重写和RDB也是同样的套路，也是copy-on-write，具体流程如下：

1. Redis fork一个子进程，此时有父、子两个进程。
2. 子进程开始在临时文件写入新的AOF内容。
3. 父进程把所有新的数据变化命令累积到内存缓冲中(同时把新的数据变化命令写到旧的AOF文件)，如果重写失败，数据不会丢失。
4. 子进程完成AOF文件重写后通知父进程，父进程收到信号后，把内存缓冲中的命令追加到子进程生成的新AOF文件末尾。
5. Redis自动对新文件重命名为旧文件的AOF文件名，新的数据变化命令追加到新的AOF文件中。

---

三、AOF和RDB持久化注意事项

Redis2.4以上版本要避免RDB持久化时触发AOF重写，或者AOF重写时进行BGSAVE操作，不然两者同时进行磁盘I/O负载很大。

当RDB在进行中时，此时用户请求AOF文件重写，服务器会响应状态码OK，以告知用户操作正在计划中，一旦内存快照生成，AOF文件重新就会开始。

如果AOF和RDB都启用，那么Redis重启时会优先使用AOF文件进行数据集重建，因为AOF能确保数据是最完整的。