Redis持久化（RDB与AOF）

我们都知道Redis的数据都存在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证Redis的数据不会因为故障而丢失，这种机制就是Redis的持久化机制。

Redis的持久化机制主要是有两种，第一种是RDB快照，第二种是AOD日志。如果我们的服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库的状态。只有在AOF持久化功能处于关闭的状态的时候，服务器才能使用RDB文件来还原数据库状态。

服务器载入文件时的判断流程

RDB持久化

RDB持久化是通过快照来实现的，在指定的时间间隔内将内存的数据集快照写入磁盘，恢复的时候就是将快照文件读取到内存中。

可是我们知道Redis是单线程的，内存快照又要要求Redis进行文件IO操作，可是文件IO操作时不能使用多路复用API，这意味着我们单线程要处理服务器上的请求，还有处理文件IO操作，显然是会拖垮服务器请求的性能。

我们是如何解决的呢，这用到了COW(Copy On Write)来实现持久化。这样有一篇关于COW比较详细。（COW奶牛！Copy On Write机制了解一下）

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

持久化快照保存过程

子进程做数据持久化，它不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对内存数据结构进行不间断的修改。那我们不可能对同一片内存进行操作，所以用到了写入时复制。

数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享内存复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。所以才被称为快照的原因。（具体流程对应上图操作）

触发条件

我们上面也提到了RDB的操作，那么什么时候会触发呢？

指令触发：

SAVE：立刻redis数据持久化，其他全部阻塞
BGSAVE：redis会在后台异步进行快照操作，同时还可响应客户端的请求，可用命令 lastsave 获取最后一次成功执行快照的时间
FLUSHALL：清空命令也会触发持久化操作，但dump.rdb文件中是空的，无意义
SHUTDOWN ：关闭数据库命令也会触发redis持久化操作，前提是没有开启AOF持久化
DEBUG RELAOD：用该命令重新加载Redis时，也会自动触发save操作

配置文件触发：

在我们的Redis文件的redis.conf文件中可以设置save <seconds> <changes> 指定在 seconds 秒内有 changes 次跟新操作，就进行一次持久化。（用的也是BGSAVE）

#默认的配置如下：
save 900 1  # 900秒内有一个更改就触发
save 300 10 # 300秒内有10个更改就触发
save 60 10000 # 60秒内有10000个更改就触发

如果从节点执行全量复制操作，主节点自动执行BGSAVE 生成RDB文件并发送给从节点

优缺点

优点：

对数据的完整性要求不高
因为主进程不进行任何的IO操作，所以对数据的大规模恢复有着极高的性能

缺点：

fork进程的时候，会占用一定的内存空间
需要一定的时间间隔来进行操作，如果redis意外宕机了，那么最后一次修改的数据就没有了

恢复持久化文件：

将备份文件移动至 dir 参数配置持久化文件的目录下，并将文件名改为 dbfilename 参数配置持久化参数的文件名，然后启动数据库即可恢复数据。

若 dump.rdb 文件存在异常，数据恢复将报错。可使用命令 redis-check-dump --fix <filename> 命令对 dump.rdb 持久化文件进行修复，然后重启redis服务即可。

AOF(Append-Only-File)持久化

以独立日志的方式记录每次写命令，写入的内容直接是文本协议格式，重启时再重新执行AOF文件中的命令达到恢复数据的目的，解决了数据持久化实时性问题。

appendonly no # 默认为no不开启，改为yes为开启

如果开启了AOF，默认的文件名是appendonly.aof，路径与RDB文件同级。

ReWrite重写机制

引入重写机制背景：AOF采用文件追加的方式，将导致文件越来越大，故新增重写机制。当AOF文件大小超过所设置的阈值时，Redis将启动AOF内容压缩，只保留可以恢复数据的最小指令集。

原理：Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身（重写）。其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。序列化完毕后再将操作期间发生的增量AOF 日志追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。

AOF的具体工作流程：

命令的实时写入，调用到命令
所有的写入命令追加到aof_buf(缓冲区)中
AOF缓冲区根据对应的策略向硬盘做同步操作
随着AOF文件越来越大，需要定期对AOF文件进行重写，压缩，父进程执行fork创建子进程，由子进程根据内存快照执行AOF重写，父进行继续响应后面的命令，在子进程完成重写后，父进程再把新增的写入命令写入到新的AOF文件中
Redis服务重启，加载AOF文件进行数据恢复

触发机制

主动触发：

使用bgrewriteaof命令

被动触发：

配置文件设置，有两个参数

# 重写时，是否可以使用appendfsync(接受客户端的操作)，默认为no,保证数据安全性
no-appendfsync-on-rewrite no

#redis会记录上次重写AOF文件的大小，当AOF文件增加至上次重写文件的100%倍，且大小大于64MB时，触发AOF重写
#auto-aof-rewrite-percentage 用于设置相对于上次AOF文件百分比
auto-aof-rewrite-percentage 100
#auto-aof-rewrite-min-size 用于设置另一基准值
auto-aof-rewrite-min-size 64mb

优缺点

优点：

如果每一次都修改都同步的话，可以更好的保持数据完整性
如果每秒都同步一次的话，如果发生宕机什么的话，最多可能丢失一秒的数据
如果从不同步的话，具有效率最高的特点

缺点：

相对于数据文件来说，AOF远远大于RDB，修复的速度也比RDB慢
AOF运行效率也比RDB慢，所以我们Redis默认的配置就是RDB持久化

fsync同步策略

上面我们也说到了AOF缓冲区会根据对应的策略向硬盘做同步操作，那么具体有哪些同步策略呢？

AOF缓冲区同步策略，通过参数appendfsync控制，具体有三个配值

选项的值	说明	其他
always	命令写入aof_buf后调用系统fsync操作同步到AOF文件，fsync完成后线程返回	每次写入都要同步AOF文件，在一般的SATA硬盘很难达到高性能
everysec	命令写入aof_buf后调用系统write操作，write完成后线程返回。fsync同步操作由线程每秒调用一次（建议策略）	默认同步策略
no	命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期最长30秒	操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证

补充：如果同时开启了RDB和AOF的话，我们是优先加载AOF。因为AOF保存的数据更加完整，最多也就损失1s的数据。

关于AOF的面试题

AOF为什么直接采用文本协议格式？

文本协议具有良好的兼容性
开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免二次处理开销
文本协议具有可读性，方便直接修改和处理

AOF 为什么把命令追加到aof_buf中

写入缓存区aof_buf中，能提高性能，并且Redis提供了多种缓存区同步硬盘策略

重写后的AOF文件为什么可以变小？

进程内已经超时的数据不再写入文件
旧的AOF文件含有无效命令，重写使用进程内数据直接生成，新的AOF文件只保留最终数据的写入命令
多条写命令可以合并为一个，为了防止溢出，以64个元素为界拆分为多条

参考资料

《Redis设计与实现》

《Redis深度历险：核心原理与应用实践》

Redis之Redis持久化

Redis如何做持久化

阿提说说