七、Redis的持久化策略

 两种持久化策略:

        Redis这个缓存存放的数据是存到内存的，假如宕机了，那么就会数据丢失。如何避免这种情况呢？由此，Redis推出了两种持久化机制。

        第一种机制就是以二进制序列形式存储数据的RDB快照，第二种机制就是以命令形式存放的aof日志。

        那么Redis为什么不推出一种统一的持久化机制，而是采用了两种呢？其实就是对应不同的两种使用场景。

        设想一种场景，Redis机器重启时，这时候需要重新加载所有的数据来恢复内存。

        但有一种场景，不需要重新加载数据，而只需要加载增量的数据。此时，其实就可以获取后续增量的指令，执行这些指令，自然就能获取所有的数据。

RDB快照原理

        Redis是单线程执行命令，当执行RDB快照时，会不会发送堵塞？答案是不会，RDB快照时涉及到了一个思想，写时复制 copy on write。

        执行快照吗，其实就是执行save命令。主进程会fork一个子进程，此时，主子进程都会共享这一瞬间，相同一块的内存空间（即操作系统的数据段）。主进程负责响应客户端的请求，子进程负责遍历内存数据，执行持久化。

        从这个流程也可以看出来RDB的局限性，它只是保存一瞬间的快照，并不能保存全量的数据。

AOF的原理

        一句话，AOF的原理就是记录Redis服务器的顺序的写指令。当然，由于其记录的是指令，会占据太多无用的内存空间。因此，时间一长，就不得不清理这些冗余的指令，这就触发了redis的aof重写，即:bgrewriteaof指令。

        AOF的重写，也如同rdb快照一样，都是让子进程执行的，通过精简各种指令，减少重复指令等减少内存占用。

        AOF形式持久化的缺点就是，当恢复数据时，由于单线程顺序执行aof的指令，其回复速度非常慢。

混合持久化

        前面的介绍可以看出来，RDB占据的空间相对小，并且恢复起来速度快，但会丢失数据。AOF可以保存到指令级的数据，但由于其顺序执行指令才能持久化数据。那么混合持久化应运而生，将增量的AOF文件和RDB快照结合一起，汲取两者的优点。