Redis数据刷盘：来看一看技术行业的缓存神器是如何做的

Redis为了提高数据的读写性能，将数据存放在内存中，但是内存中的数据会随着Redis Server的停止或者其他故障而丢失，为了防止这种情况的出现，我们需要将内存中的数据保存到磁盘上，以便Redis Server重启时能从磁盘中快速恢复原有数据。这个过程就叫做Redis持久化。

Redis持久化有三种机制：

1、RDB机制（Redis DataBase）：也叫快照机制，将某一时刻的内存快照数据以二进制方式写入磁盘。

2、AOF机制（Append Only File）：也叫文件追加机制，将所有的操作命令按顺序记录下来，追加到特殊的文件中。

3、混合机制：顾名思义，为RDB和AOF机制的组合，综合了各自的优点，先将当前的数据以RDB方式写入文件，再将操作命令以AOF方式写入文件。

实际运用时，需要根据业务场景的特点选择不同的持久化方案，我们分别来看一下。

RDB机制：

RDB机制会生成全量rdb文件，可通过redis.conf配置文件名和目录。

RDB机制有两种触发方式：

1、主动方式：即手动触发，涉及两个操作命令：SAVE 和 BGSAVE，区别在于前者会堵塞主进程，导致主进程不能处理其他命令，直到RDB过程完成；后者会创建子进程，利用COW技术，由子进程负责RDB过程，主进程可以继续处理其他命令。

2、自动方式：由配置文件来完成，自动触发 BGSAVE命令，在redis.conf配置文件中有如下配置：

save 900 1 /*900秒内至少发生1次key变换*/

save 60 10 /*60秒内至少发生10次key变换*/

dbfilename dump.rdb /*快照文件名*/

dir ./ /*快照文件存放目录*/

rdbcompression yes /*是否压缩*/

AOF机制：

RDB机制是全量持久化，效率较低，我们需要一种更加高效的机制AOF，在redis.conf配置文件中有如下配置：

appendonly yes /*开启aof*/

appendfilename "appendonly.aof" /*aof文件名*/

appendfsync always /*一次命令追加一次*/

appendfsync everysec /*每秒追加一次*/

appendfsync no /*从不追加*/

1、AOF文件：AOF机制将收到的每一个写命令按顺序追加到aof文件中。

由于每一个写命令都被顺序记录下来，我们只要将这个aof文件执行一遍，即可得到全部的数据。

2、AOF文件重写：AOF机制也带来了一个问题:AOF文件会越来越大。为此，Redis提供了一个AOF文件重写的功能，将内存中的全部数据以命令的方式全部重写为一个新的AOF文件，来替换之前的AOF文件。

举个例子：对于同一个key，我们分别执行了N次set操作，则AOF文件会记录N条记录，但是最终内存中的value是唯一的，只有最后一次set起到决定作用，那我们就可以根据内存中的key和value，将N条记录写成一条set操作命令记录，来替换之前的AOF文件，达到压缩目的。

（1）主进程创建子进程，由子进程进行AOF文件的重写操作。

（2）重写期间，如果主进程收到命令，继续追加AOF缓存区，然后定期追加到原AOF文件，现有的AOF文件不受影响。

（3）同时，主进程将命令追加到AOF重写缓存区。

（4）子进程完成重写，向主进程发信号。

（5）主进程将AOF重写缓存区数据追加到新AOF文件。

（6）主进程替换原AOF文件为新AOF文件。

（7）继续接收命令。

混合机制：

混合机制为RDB和AOF机制的有效组合，为redis4.0版本新增，有兴趣的可以查阅一下资料，这里不再赘述，在redis.conf配置文件中有如下配置：

aof-use-rdb-preamble yes /*开启混合持久化*/

结语：

Redis在用的人还是不少的，像我一直把Redis当作缓存来用，而且数据量不是很大，一般不会考虑持久化的问题，大不了再到数据库或者其他数据源中取一次，然后再写到Redis里就可以了，但是如果把Redis当成一个数据库，用来存储业务数据，就不得不好好地考虑持久化的问题了。

PS：如有任何问题或疑问，请留言告诉我。