Redis的数据都保存在内存，如果Redis宕机，数据将会全部丢失，因此必须有一种机制来保证Redis里的数据不会因为故障而丢失，这种机制就是Redis的持久化机制。
Redis持久化机制
1、快照
快照是一次全量 备份，快照是内存数据的二进制序列化形式，在存储上非常紧凑。
2、AOF日志
AOF日志是连续的增量 备份，AOF日志记录是内存数据修改的指令记录文本 。AOF日志在长期运行过程中会无比庞大，数据库重启时需要加载AOF日志进行指令重放，这个过程无比漫长，因此需要定期进行AOF重写，给AOF瘦身。
快照原理
我们知道Redis是单线程服务，Redis在处理服务请求的同时，还有进行内存快照。而内存快照需要将数据写到磁盘，进行IO操作，可文件的IO操作不能使用多路复用API。此外，那Redis是如何处理的呢？---Redis使用操作系统的多进程COW（Copy On Write）来实现快照持久化。
Redis在持久化时会调用glibc函数的fork产生一个子进程，快照持久化完全交给子进程处理，父进程继续处理客户端请求。
子进程做数据持久化不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘。但是父进程不一样，它必须持续服务客户端请求，然后对内存数据结构进行不间断的修改。
这个时候就会用到操作系统的COW机制来进行数据页面的分离。
如上图所示，数据段是由很多操作系统页面组合而成，当父进程对其中的一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。
随着父进程修改的持续进行，越来越多的共享页面被分离出来 ，内存就会持续增长，但是不会超出数据内存的2倍大小。另外，Redis实例里冷数据占比往往比较高，所以很少出现所有页面都被分离的情况。
子进程因为数据没有变化看，它能看到的丝毫内存里数据在进程产生的一瞬间就凝固了，再也不会改变。这就是为什么Redis的持久化叫快照的原因。
AOF原理
AOF日志存储的是Redis服务器的顺序指令序列，AOF日志只记录对内存进行修改的指令记录。
Redis会在收到客户端修改指令后，进行参数校验，逻辑处理，如果没有问题，就立即将该指令文本存储到AOF日志中。也就是说，先执行指令才将日志存盘。
AOF在长期运行过程中，会越拉越大，需要定期进行瘦身。Redis提供了bgrewriteaof指令对AOF日志进行瘦身，其原理就是开辟一个子进程对内存进行遍历，转换成一系列Redis的操作指令，序列化到一个新的AOF日志中。序列化完毕后再将操作期间发生的增量AOF日志追加到这个新的AOF日志文件中，追加完毕后就立即替代旧的AOF文件了，瘦身工作就完成了。
AOF日志是以文件的形式存在的，当程序对AOF日志文件进行写操作时，实际上是将内容写到了内核为文件描述符分配的一个内核缓存中，然后内核会异步将数据刷到磁盘中。
Linux的glibc提供了fsync(int fd)函数可以将指定文件的内容强制从内核缓存刷新到磁盘，但是fsync是磁盘IO操作很慢。生产环境中通常是1S调用一次fsync。
混合持久化
重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志相对于使用 rdb 来说要慢很多，这样在Redis 实例很大的时候，启动需要花费很长的时间。
Redis 4.0 为了解决这个问题，带来了一个新的持久化选项--混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。于是在 Redis 重启的时候，可以先加载rdb 的内容，然后再重放增量AOF 日志。就可以完全替代之前的AOF 全量文件重放，重启效率因此得到大幅提升。