Redis持久化机制（RDB VS AOF）

---

Redis持久化机制由来

Redis是一个基于内存数据库，数据保存在内存中，由此Redis的性能瓶颈并不是CPU，而是内存和网络带宽， 我们知道Redis速度极快，官网说明的QPS（每秒查询率）达到10W+，既然这么快，很多人会想，难道他是用多线程去处理的吗？可是你就确定多线程一定快吗？

对于Redis使用单线程去操作数据效率就是最高的，原因是：多线程会导致复杂的并发事物控制，并且操作CPU上下文会切换进而导致耗时的操作，然而对于内存系统来说，如果没有上下文切换效率就是最高的，多次读写都是在一个CPU上的，因此在内存系统存储数据的条件下，单线程就是最快的，当然内存中的数据最大的弊端就是数据容易发生丢失，一旦服务宕机，数据即消失。为了解决这个弊端Redis为我们提供了持久化的机制，分别是RDB(Redis DataBase)和AOF(Append Only File)。

一、RDB机制

在指定时间间隔后，将内存中的数据集快照写入数据库 ；在恢复时候，直接读取快照文件，进行数据的恢复 ；
默认情况下，Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。文件名可以在配置文件中进行自定义，默认保存在Redis服务bin目录下。

既然RDB机制是通过把某个时刻的所有数据生成一个快照来保存，那么就应该有一种触发机制，是实现这个过程。对于RDB来说，提供了三种机制：save、bgsave、自动化。

1、1 工作原理

在进行 RDB 的时候，redis 的主线程是不会做 io 操作的，主线程会 fork 一个子线程来完成该操作；

1、Redis 调用forks，同时拥有父进程和子进程。
2、子进程将数据集写入到一个临时 RDB 文件中。
3、当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益(因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求。)

1、2 RDB的配置

RDB持久化机制，我们知道其默认的二进制文件名称为：dump.rdb，我们查看Redis.conf配置文件，一探究竟：

默认配置文件名称：

默认配置触发RDB机制：

默认90秒内保存一次数据或者300秒内保存10次数据或者60秒内保存10000次数据都会触发我们RDB机制进行自动持久化数据操作，生成dump.rdb二进制文件

1、3 修改RDB配置的快照策略

修改触发策略：60秒内保存3次数据就触发我们的RDB持久化策略

1、3、1 自定义RDB持久化策略

删除之前的dump.rdb二进制文件：

进入客户端set数据，首先我们先set两条数据：

等待60秒过后再次检查是否触发RDB策略，然而并没有触发，因为我们设置的是60秒保存三个数据才触发RDB持久化机制：

再set第三个数据：

等待60秒过后再次检查是否触发RDB策略：

此时是不是触发了我们自定义的RDB触发策略。

1、3、2 服务宕机RDB持久化策略仍然生效

退出Redis服务：

查看Redis是否已经结束：

再次开启服务进入客户端查看数据是否已经持久化:


服务停掉之后，数据依然还在。

1、3、3 FlushALL也会触发RDB持久化策略

在上面的基础上，我们继续删除dump.rdb二进制文件：

进行FLUSHALL操作：

再次检查是否触发RDB策略：

1、4 总结RDB触发机制

1：save的规则满足的条件下，会自动触发rdb机制
2：服务宕机，退出redis服务，也会自动触发rdb机制
3：执行FLUSHALL命令，也会自动触发rdb机制

1、4 优缺点

优点：

适合大规模的数据恢复，对数据的完整性要求不高。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备。

缺点：

如果redis要故障时要尽可能少的丢失数据，RDB没有AOF好，例如16:30进行的快照，在16:31又要进行快照的时候服务突然宕机了，这个时候就会丢失1分钟的数据。另外fork进程的时候，会占用一定的内容空间。

二、AOF机制

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

2、1 AOF的配置

AOF持久化机制，默认是关闭的，并且其默认的二进制文件名称为：appendonly.aof，我们查看Redis.conf配置文件，一探究竟：

默认配置文件名称：

2、2 开启AOF持久化策略

将appendonly no修改为appendonly yes：

策略方式：

默认没一秒钟修改一次即可触发AOF持久化，即只可能丢失一秒钟的数据，对数据要求的完整性是比较时效的。

以及对数据的安全配置，是否支持重写，重写的精度等等。

2、3 测试AOF持久化策略

清除之前产生的持久化文件：

关闭服务，并且重启服务：

查看持久化策略：

可以发现AOF持久化策略已经开启了。
set我们的值：

一秒钟后查看appendonly.aof二进制文件：

2.4 文件修复

关闭服务：

破坏文件结构数据：


再次启动服务连接客户端：

此时边便无法进行连接了，我们需要使用redis-check-aof工具修复文件

redis-check-aof --fix appendonly.aof

重启服务即可恢复：

2.4 优缺点

优点：

文件完整性更好，每一秒就会同步一次数据，只会丢失一秒钟的数据，从不同步，效率最高。

缺点：

相对于数据文件来说，修复速度比RDB慢得多，并且记录的是日志文件，默认以文件的形式追加数据，会造成文件体积庞大，aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化。

三、如何选择RDB和AOF

1、如果是数据不那么敏感，且可以从其他地方重新生成补回的，那么可以关闭持久化
2、如果是数据比较重要，不想再从其他地方获取，且可以承受数分钟的数据丢失，比如缓存等，那么可以只使RDB
3、如果是用做内存数据库，要使用Redis的持久化，建议是RDB和AOF都开启，或者定期执行bgsave做快照备份，RDB方式更适合做数据的备份，AOF可以保证数据的不丢失