Redis 持久化

现在大家都习惯与用Redis作为缓存系统，并且在其中放入常用的热点数据，从而减少直接对数据库访问的操作。

Redis 持久化就是将 Redis 内存数据永久存储到磁盘中的操作

Redis提供的两种持久化方式

• RDB （Redis DataBase）

  在不同间隔时间点将 Redis 内存数据生成快照并存储到磁盘中（存储数据）

• AOF（Append Only File）

  记录Redis执行过的所有写指令（存储指令）

RDB（Redis DataBase）

是指Redis将某一时刻的数据记录生成快照，存储到磁盘中

上述图可以看出，Redis在进行持久化数据时，会先将内存数据写入临时文件中，然后再将临时文件保存入内盘（替换原有的持久化文件）

上述操作是以周期性进行的，也就是说：过多长时间，操作多少数据，他就会记录一次。

RDB主要有以下周期

这样可以有效地避免：如果Redis直接将数据写入硬盘中，首先要清除原有的数据，然后在写入新的数据。若是发生系统故障或者断电，就会导致新旧数据都会损失。

并且这种方式，RDB会直接创建一个子进程来进行持久化，主进程不进行任何的读写操作

RDB持久化的优点

• 体积更小：相同数据量的RDB文件比AOF更小
• 恢复更快：只是进行数据的记录，不用进行数据操作
• 性能更高：父进程在保存 RDB 文件时只需要 fork() 一个子进程，无需父进程的进行其他 I、O操作，从而保证 Redis 服务器的性能

RDB持久化的缺点

• 数据有丢失的风险： Redis 服务器出故障时，使用RDB持久化可能丢失数据
• 耐久性差：数据量很大时RDB比AOF持久化更加消耗时间和CPU资源

使用场景：由于RDB这种方式持久化数据是不注重数据的完整性。若你需要大量数据的恢复，并且对数据的完整性要求不高，就可以使用RDB。

AOF（Append Only File）

AOF持久化，从英文名可以看出，只允许追加不允许改写文件的持久化

RDB记录的是数据。那么AOF记录的是数据的操作。

举个例子：授人与鱼不如授人与渔

RDB就是授的鱼（数据），AOF是授的渔（数据的操作）。

对于AOF的配置中，我们简单了解一下其级别即可：

我们重点学习的为AOF的重写原理

AOF文件的重写原理

为什么要进行AOF文件重写

首先我们知道AOF记录Redis执行过的所有写指令，这些记录统一记录到AOF文件中。但是随着写指令的增多，文件就会越来越大，文件太大就会对Redis服务器造成影响，并且还原AOF文件所需的时间也会越长。

为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写功能

先来看图：

解释一下：

首先我们看到AOF文件重写有两个进程：

• 主进程：用来接收新的写指令，并将其放入缓存区。
• 子进程：负责重写，分为以下几步
  1. 读取原本的AOF文件
  2. 分析原本文件和新的写指令，并将其压缩后放入一个临时AOF文件
  3. 将临时的文件写入内存中，代替原本AOF文件成为新的AOF文件

AOF支持化优缺点

AOF支持化优点

• 故障数据不丢失：可以设置 appendfsync 策略，一般默认是 everysec，也可以设置每次写入追加，所以即使服务故障宕机，也最多丢失1秒数据
• AOF 文件重写：当 AOF 文件大小到达一定程度的时候，后台会自动的去执行 AOF 文件重写，此过程不会影响主进程，重写完成后，新的写入将会写到新的 AOF 中，旧的就会被删除掉

AOF支持化缺点

• 性能相对较差：AOF 持久化操作模式决定会对 Redis 的性能有所损耗
• AOF 文件更大：尽管有 AOF 文件重写，但是随着 Redis 服务器写操作增多，AOF 文件依然会增大
• 恢复速度更慢：还原数据库状态是通过加载AOF文件内容，逐条执行记录的写操作，显然速度比RDB更慢

如何选择 Redis 持久化策略

官方的建议是两个同时使用，可以提供更可靠的持久化方案。但是AOF默认是关闭的。