redis持久化

Redis作为一种典型的nosql内存数据库，因其读写速度的快的优势在很多项目中被广泛使用。Redis的数据是存储到内存中的，为了保证数据在Redis 重启之后不丢失，需要将数据从内存中以某种方式同步到硬盘中，这一过程就是持久化。

Redis支持两种方式的持久化，一种是RDB方式，一种是AOF(append only file)方式。可以单独使用，也可以结合使用。两种持久化方式的开启都是在redis.conf这个文件中进行相应的配置，另外说明一下两种方式实现流程和对比分析，可以为以后选择和调优提供一下参考。

一、 两种持久化方式的开启

1、RDB方式
RDB是Redis默认采用的持久化方式，在配置文件中已经预置了3个条件

  Save  900  1

  Save  300  10

  Save  60   10000

  Save  900  1的意思是在900秒内有至少一个键被更改则进行快照，其他条件的含义类似

2、AOF方式

 在默认情况下Redis没有开启AOF(append only file)方式的持久化，可以通过appendonly参数开启：

 Appendonly  yes

二、两种持久化方式的实现过程

 两种持久化方式的数据流向如下图所示：

image.png

RDB方式的持久化是通过快照完成的，快照的过程如下：

1、redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；

2、进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；

3、子进程写入完所有数据后会用该临时文件替换旧的RDB文件(dump.rdb)，至此一次快照操作完成。

AOF方式的持久化是每执行一条会更改Redis中的数据的命令，Redis会通过write函数将该命令写入系统的硬盘缓存，然后系统每隔一定的时间（默认是30秒）会执行一次同步操作，将硬盘缓存中的内容写入硬盘(appendonly.aof)。

三、两种持久化方式的区别

通过对比两种持久化方式的实现过程，可以得到它们的区别：

1、RDB方式，Redis只有在满足一定的条件才使用fork函数复制一份当前进程（父进程）的副本（子进程），而AOF方式，每当发生数据变化的时候，Redis就会将改数据写去硬盘缓存当中。

2、RDB方式，当所有数据都写入临时文件后，该临时文件会将旧的RDB文件替换，旧的文件就被覆盖了；而AOF方式，硬盘缓存中的数据是追加到AOF文件中的，不会将以前的数据覆盖。

3、RDB文件是经过压缩的二进制文件，占用的空间小于内存中的数据大小；AOF文件是纯文本文件，其内容是Redis客户端向Redis发送的原始通信协议的内容，占用空间较大。

四、两种持久化方式的优缺点

通过分析两种持久化方式的区别，可以得到它们的优缺点：

1、通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据，AOF方式就不存在这个问题，AOF方式比RDB方式有更好的持久化性。

2、RDB方式是满足一定条件才进行快照操作，AOF方式是实时写，所以AOF方式影响性能更多一些。

3、RDB方式是覆盖写，一旦操作失误（例如不小心清空了redis里面的数据），旧的dump.rdb文件是不可恢复的；AOF方式是追加写，appendonly.aof文件就不存在这种问题。

4、RDB文件载入内存的速度很快，而AOF文件载入内存的速度就要慢的多。

五、Redis服务器数据的恢复

当Redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存：

1、如果只配置AOF,重启时加载AOF文件恢复数据；
2、如果同时 配置了RDB和AOF,启动是只加载AOF文件恢复数据；
3、如果只配置RDB,启动是将加载dump文件恢复数据。

也就是说，AOF的优先级要高于RDB，因为AOF本身对数据的完整性保障要高于RDB。

通过上述分析可知，两种持久化的方式各有优缺点，在具体的情况下可根据不同的需要来进行选择。

image.png

Redis 4.0 混合持久化重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。通过如下配置可以开启混合持久化：# aof-use-rdb-preamble yes

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换。于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的AOF 全量文件重放，因此重启效率大幅得到提升。

混合持久化AOF文件结构

image.png