在前一篇文章中，已经介绍了Redis的基础数据结构，这篇文章将继续介绍Redis的持久化原理。
简介
众所周知Redis的所有数据都存在于内存之中，这就会存在因内存问题而导致的数据丢失，为了避免这一问题，可采取Redis的持久化机制来解决这一问题。
详解
Redis持久化有两种方式，分别是RDB（又称快照）与AOF。对于两种方式各有优缺点，具体如下：
RDB：全量一次同步内存中所有序列化的二进制数据，同步慢，数据较小。
AOF：增量同步操作指令，同步较快，数据量随时间增加而增多，需定期进行AOF文件重写，以便减小日志文件。
RDB原理
SAVE：该命令会阻塞当前Redis服务，导致Redis服务不可用，直至RDB持久化进程完毕，所以一般都不采取该方式进行RDB持久化。
BGSAVE：当使用该命令进行RDB持久化时，Redis会fork产生一个子进程，由子进程进行RDB持久化操作，父进程接受客户端的操作请求。子进程只会遍历读取内存中的数据，写入磁盘，并不会修改数据，若父进程在子进程读取数据过后进行了数据修改，子进程就会与父进程存在数据不一致的问题。
Copy on Write：众所周知Redis是单线程程序，文件IO操作不能进行多路复用，于是在BGSAVE进行RDB持久化时Redis采用操作系统的Copy on Write机制进行RDB持久化。
单独使用RDB持久化，存在数据丢失风险
AOF原理
AOF日志存储的是，Redis执行的顺序写指令。当开启AOF持久化时，Redis会先执行数据的写指令，再将指令写入AOF日志中。
fsync：实际情况中，AOF机制会先将Redis写指令写入内存缓冲区中，再根据配置情况，定时调用fsync将缓冲区文件写入AOF日志中。我们可以根据实际情况设置fsync频率：
-
always：每次修改，立即提交磁盘。该方式数据完整性良好，但是IO开销大，影响效率.
-
everysec： 每秒同步一次到磁盘。该方式只会丢失一秒内的数据，
-
no： 从不同步到磁盘。
思考
从上述的原理中，可以看出无论是RDB还是AOF，都存在一定的缺点。
在日常操作中，一般都是从AOF日志中来恢复数据，因为RDB会丢失大量数据。但是AOF恢复数据又会花费较长时间。
于是从Redis4.0开始，Redis开始支持混合持久化。即将RDB与AOF结合使用，RDB负责定时全量持久化数据，AOF负责记录最后一次RDB后的增量日志。使得Redis的数据恢复在恢复效率与数据完整性之间取得一个完美的平衡点。