RDB（Redis DataBase）：

RDB是什么？

在指定的时间间隔以内，执行数据集的时间点快照。

实现类似照片记录想过的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来，即使是宕机（假如直接断电），快照文件也不会丢失，数据的可靠性得到了保证。

快照文件称之为RDB文件

RDB能干嘛？

1.在指定时间间隔以内将内存中的数据集快照写入磁盘，也就是Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里

2.Redis的数据都在内存中，保存备份时它执行的是全量快照（我理解就是全局快照），也就是说，把内存中的所有数据都记录到磁盘中

3.Rdb保存的是dump.rdb

RDB自动触发

RDB手动触发

save和BGsave

save：使用save会阻塞当前redis服务器，直到持久化工作完成，并且在执行save命令期间，Redis不能处理其它命令，线上禁止使用

BGsave（默认）：不阻塞快照同时还可以相应客户端请求，该触发方式会fork（也就是复制一份）一个子进程由子进程复制持久化过程

RDB优点

• 适合大规模的数据恢复
• 对照业务定时备份
• 读数据完整性和一致性要求不高
• RDB文件在内存中的加载速度比AOF快得多

RDB缺点

• 在一定时间间隔做一次备份，所以如果Redis意外down掉，就会丢失从当前到最近一次快照期间的数据，快照之间的数据就会丢失
• 内存数据的全量同步，如果数据太大会导致I/O严重影响服务器性能
• RDB依赖主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致2倍的膨胀，需要考虑。

什么情况会触发RDB快照

• 配置文件中默认的快照配置
• 手动save/bgsave命令
• 执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
• 执行shutdown且没有设置开启AOF持久化
• 主从复制时，主节点自动触发

AOF（Append Only File）：

AOF是什么？

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

默认情况，redis没有开启AOF，开启AOF需要设置配置：appendonly yes

AOF能干嘛？

AOF保存的是appendonly.apf文件

AOF持久化工作流程

1	Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2	在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3	AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
4	随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
5	当Redis Server服务器重启的时候会从AOF文件载入数据。

AOF缓冲区三种写回策略

Always（总是）：

同步写回，每个命令执行完立刻同步的将日志写回磁盘。

Everysec 默认（每隔一秒）：

每秒写回，每一个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘。

No（从不）：

操作系统控制的写回，每个写命令执行完，只是先把日志写道AOF的内存缓冲区，由操作系统决定什么时候将缓冲区内容写回到磁盘。

写回策略总结：

配置项	写回时机	优点	缺点
Always	同步写回	可靠性高，数据基本不丢失	每个写命令都要落盘，性能影响较大
Everysec	每秒写回	性能适中	宕机时丢失1秒数据
No	操作系统控制写回	性能好	宕机时丢失数据较多

AOF优点

AOF缺点

• 相同数据集的数据而言，AOF文件要远大于RDB文件，恢复速度慢于RDB。
• AOF运行效率慢于RDB，每秒同步策略效率较好，不同步效率和RDB相同

AOF重写机制

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存就越大并且 AOF 恢复时间越长。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集或者可以手动使用命令bgrewriteaof来重写。

是什么？

！！！启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

触发机制：

官网默认配置：

• 根据上次重写后的AOF大小，判断当前AOF大小是不是增长了1倍。
• 重写时满足的文件大小

只有以上两点同时满足，才会触发AOF重写机制

自动触发：

满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍并且文件大于64MB时。

手动触发：

客户端向服务器发送bgrewriteaof命令

手动使用命令bgrewriteaof来重写。

重写原理

• 在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
• 与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
• 当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
• 当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
• 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

总结

RDB+AO混合持久化：

官网建议

两个可以混合使用

RDB vs AOF

能否共存？ 能

如果共存听谁的？听AOF

怎么选？用哪个？

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。

同时开启两种持久化方式

• 在这种情况下，当Redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？还是建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），留着RDB作为一个万一的手段。

推荐方式

RDB+AOF混合方式

结合了RDB和AOF的优点，既能快速加载又能避免丢失过多数据。

aof-use-rdb-preamble的值为yes yes表示开启 no表示关闭

结论：RDB镜像做全局持久化，AOF做增量持久化

纯缓存模式

同时关闭RDB+AOF

Save “”

禁用RDB save加上一个空字符串

禁用RDB持久化模式下，仍然可以使用命令save、bgsave生成RDB文件

AppendOnly No

禁用AOF

禁用AOF持久化模式下，仍然可以使用命令bgrewriteaof生成AOF文件