Redis作为常见的缓存工具，我们是如何进行redis缓存持久化的呢？

Redis的数据是全部存储在内存之中，但如果这时候Redis服务宕机，那存储在内存中的数据也会一并丢失，所以为了让redis的数据避免丢失或者是少丢失一点，就要利用策略来将redis的数据存入到磁盘之中，所以就诞生了redis的持久化。即Redis持久化的意义就是为了保证突然宕机，内存数据不会全部丢失。

redis做为缓存，数据的持久化是怎么做的呢？

Redis提供了两种数据持久化的方式 ： 1.RDB 2. AOF

(如今有3种，在Redis4.0版本之后,RDB和AOF混合使用，诞生第三种)

一、RDB持久化:

RDB 全程就是Redis数据备份文件，也叫Redis数据快照。他的用处就是将内存中的数据记录到磁盘之中，当服务宕机,或者Redis实例故障重启之后，再从磁盘中读取快照文件，以用来恢复数据。

这是用到的两个命令行 1-主进程来执行RDB，但是会阻塞所有命令。2-开启子进程来执行RDB，避免主进程受到影响。建议使用bgsave。也叫主动备份。

同时Redis内部也有出发RDB的机制，可以在Redis.conf文件中找到。

900秒内有1个数据被修改 - 触发RDB

300秒内有10个数据被修改 - 触发RDB

60秒内有10000个数据被修改 - 触发RDB

以上都触发bgsave。

执行原理:

当bgsave开始的时候，会fork主进程来得到一个子进程，子进程共享主进程的内存数据。完成fork之后读取内存数据并写入RDB文件之中。

##数据都是存储在物理内存之中的，而操作系统给我们的主进程中分配了一个虚拟内存。在主进程中还有一个表，叫做页表。页表是用来记录虚拟地址和物理地址的映射关系的，页表在主进程中，也就成为了主进程虚拟内存和物理内存沟通的桥梁。主进程可以通过页表来读取物理内存之中的数据。

但是当主进程fork了一个子进程之后，在子进程读取数据并写入RDB的时候，主进程是可以接收用户的请求，并且对内存数据进行修改。如果主进程同时修改数据，子进程同时读取数据，会产生脏数据。为了避免这种脏数据的发生，在fork底层来使用了一种copy-on-write的技术。 也就是说 当主进程执行读操作的时候，访问共享数据，此时共享数据为read-only。但是当主线程执行写操作的时候，则会拷贝一份数据来进行写操作。

二、AOF持久化:

AOF全程被称为追加文件，Redis处理的每一个写命令都会被记录在AOF文件之中，可以看作是命令日志文件。

这边的命令中我们输入了set num 123这段命令。而同时，当redis接受这段命令的时候，会同时的将这段命令分别输入到AOF日志文件之中。

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

AOF的命令记录频率也可以在文件中进行修改

这也分为三种记录的频率，也叫做刷盘策略。

1.Always 被称为 同步刷盘 优点: 可靠性高，几乎不丢数据 缺点: 性能影响大

2.everysec 被称为 每秒刷盘 优点: 性能适中 缺点: 最多丢失一秒的数据

3.no 被称为操作系统控制 优点: 性能最好 缺点: 可靠性较差，可能丢失大量数据

在上面三种策略中，我们一般使用第二种 everysec来进行记录。

因为AOF是记录命令，所以AOF文件会比RDB文件大很多，而且AOF会记录同一个key的多次写操作，但是只有最后一次写操作才有意义，这时候就可以通过bgrewriteaof命令，来让AOF文件执行重写功能，用最少的命令达到最好的效果。

重写前:

重写后:

当然在Redis中也可以通过配置文件的修改来进行一个阈值的配置，让阈值超过多少之后AOF自动触发重写功能。

以上就是RDB持久化和AOF持久化的介绍，以下我们来对他做一个对比。

以上可见，AOF和RDB都有自己的优点和缺点，所以在实际项目开发中，往往会结合两者来一起使用。