Redis持久化（RDB和AOF）

Redis因为是基础内存存储数据的，因此在我们平时程序中常用为缓存，但是正是因为基于内存存储的数据，导致了Redis一旦宕机，那么存储在里面的数据便会丢失，因此我们需要有一定的方法将Redis存储在内存中的数据存储到硬盘中，使数据持久化，这样就算宕机了，数据也保存到了磁盘中，到时候根据磁盘中的数据恢复即可。

那么，如何使Redis中的数据持久化呢？这里介绍常见的两种技术：①RDB ②AOF。

---

RDB

首先，我们先需要知道什么是RDB？

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

主要流程如下图：

首先，我们需要知道：在Linux系统中，任何一个程序都无法直接对内存进行读写的。一般来说内存会生成一个虚拟内存（称为：页面），每个页表都有对应映射的内存，因此我们的程序只需要对页表进行读写即可完成对内存的读写。并且呢，如果主进程对内存进行备份的时候一般是阻塞性的。

OK，那我们现在来说说上述流程图是什么意思：首先所有进程都会有对应的页表来操作对应映射的内存。然后由于备份的时候是阻塞性的，因此为了不阻碍主进程的运行，主进程会fork出一个子进程（子进程的页表与主进程是同一个页表，因此两个进程操作的内存区是同一个内存区），这样的话，子进程负责将内存中的数据读取到磁盘文件中。那么，这里有个疑问了：“如果此时用户请求对内存写操作怎么办？”因为如果一边读数据，一边更新数据可能会导致脏读的情况出现，因此如果主进程要对内存进行写操作的时候，一般会对原数据进行一个拷贝后，在拷贝副本里面操作数据，等原数据都保存完后，将拷贝并且修改的最新数据覆盖原数据。

以上便是RDB的大致流程，还有几个细节需要说一下：

①RDB默认是服务停止的时候执行，如果想修改执行策略的话，可以去配置文件中（redis.conf）修改如下配置：

900 1意思是900秒内至少有1条数据被修改，则会触发RDB，备份一次内存。下面300 10和60 10000同理。

②RDB的其他配置：

RDB总结：

①RDB方式bgsave的基本流程？

fork主进程得到一个子进程，共享内存空间

子进程读取内存数据并写入新的RDB文件

用新RDB文件替换旧的RDB文件。

②RDB会在什么时候执行？save 60 1000代表什么含义？

默认是服务停止时。

代表60秒内至少执行1000次修改则触发RDB

③RDB的缺点？

RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险

fork子进程、压缩、写出RDB文件都比较耗时

---

AOF

首先，我们需要知道什么是AOF？AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

好的，我们这里需要知道一个概念：什么是“命令日志文件”？命令日志文件是指文件中记录的都是完整的命令。比如我们执行“set num 1” 那么这整条命令都会记录到文件中。看到这，很多小伙伴便明白了AOF恢复数据的机制：“根据记录的命令一个个执行不就好了吗！”对！AOF确实是这样来恢复数据的，但是这样还是有挺大不足的：①因为要记录的是所有操作，所以就算一些读操作对于恢复数据没用的操作也会记录下来，甚至有可能比如之前修改了七八次num这个key的值，但是最后我直接delete了num这个key，那么前面记录的那些修改操作是不是就没用了？②因为记录的是操作！所以AOF一定会比RDB文件大得多得多，因此占用空间会更大！

好，AOF的机制比较简单，就是记录所有操作，恢复的时候根据记录的操作一个个全部执行一遍就可以了。

接下来说几个配置AOF的东西：

①AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF:

②AOF的命令记录的频率也可以通过redis.conf文件来配:

③AOF可以在配置中配置一些东西，使得记录的命令压缩，减少文件大小：

---

二者对比图如下：

总结：RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。