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配置文件中有如下配置：
ave 900 1 /*900秒内至少发生1次key变换*/
save 60 10 /*60秒内至少发生10次key变换*/
dbfilename dump.rdb /*快照文件名*/
dir ./ /*快照文件存放目录*/
rdbcompression yes /*是否压缩*/AOF机制：
RDB机制是全量持久化，效率较低，我们需要一种更加高效的机制AOF，在redis.conf配置文件中有如下配置：
ppendonly 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文件，达到压缩目的。
- 主进程创建子进程，由子进程进行AOF文件的重写操作。
- 重写期间，如果主进程收到命令，继续追加AOF缓存区，然后定期追加到原AOF文件，现有的AOF文件不受影响。
- 同时，主进程将命令追加到AOF重写缓存区。
- 子进程完成重写，向主进程发信号。
- 主进程将AOF重写缓存区数据追加到新AOF文件。
- 主进程替换原AOF文件为新AOF文件。
- 继续接收命令。
混合机制：
混合机制为RDB和AOF机制的有效组合，为redis4.0版本新增，有兴趣的可以查阅一下资料，这里不再赘述，在redis.conf配置文件中有如下配置：
aof-use-rdb-preamble yes /*开启混合持久化*/
RDB和AOF的比较：
特性 | RDB | AOF |
启动优先级 | 低 | 高 |
速度 | 快 | 慢 |
大小 | 小 | 大 |
丢失数据 | 会丢数据 | 取决于策略 |
量级 | 重 | 轻 |
结语：
Redis在用的人还是不少的，像我一直把Redis当作缓存来用，而且数据量不是很大，一般不会考虑持久化的问题，大不了再到数据库或者其他数据源中取一次，然后再写到Redis里就可以了，但是如果把Redis当成一个数据库，用来存储业务数据，就不得不好好地考虑持久化的问题了。
PS：如有任何问题或疑问，请留言告诉我。
