Redis持久化-深入理解AOF，RDB

Redis数据全部在内存中，如果宕机，数据必然丢失，因此必须有一种机制保证Redis数据不会因为故障丢失，这就是Redis的持久化机制
持久化方式两种：AOF，RDB，如下图
- RDB快照模式是一次全量备份，是内存数据的二进制序列化形式，存储紧凑
- AOF日志方式是连续增量的备份。是内存数据修改指令的记录文本。AOF日志长期运行下来会异常庞大，Redis重启后加载AOF日志会很慢需要定期重写AOF日志。

Redis单线程，需要同时负责N个客户端套接字读写，内存数据结构逻辑读写，定时任务处理（上一节中说明），现在还需要内存快照，而且RDB是必须进行IO操作，此处IO操作是不能用底层select的多路复用。
以上如果都是单线程完成那么肯会有两个问题：
- 第一RDB的IO操作的时候回严重拖慢服务器性能。因为需要一边IO操作，一边响应客户端socket
- 第二IO持久化同时，内存还在修改，比如大型hash结构，持久化一半修改了怎么处理？
Redis使用操作系统的多进程COW（Copy on write）机制来实现快照持久化。

pid = os.fock()
if pid > 0:handle_client_requests();   //父进程处理客户端
if pid == 0:handle_snapshot_write();    //子进程处理快照
if pid < 0:error;

fork的模式解决了上文中第一个问题IO高效性问题，那么第二个问题如何解决
子进程在做数据RDB时候，不会修改现有内存结构，只对据结构进行遍历读取。父进程必须响应客户端，修改内存数据。
这个时候才是使用操作系统的copy on write 机制的时候，在fork之后，子进程就认为当前的内存中所有数据都算做此次需要RDB到磁盘的快照，而一旦父进程在此期间需要修改某个数据段，会将共享的当前数据段分离出来，单做现在最新的内存数据，而老的数据当老版本的数据。这时候子进程的相应的数据段页面是不会变化的，还是fork瞬间的那个版本。如下示意图。
如上图示意，随着父进程的修改操作越多，只会COW出更多数据页而已，占用部分内存，但是也不可能超过原内存2倍（不可能所有页都在修改）。另外Redis冷数据占比更大，所以Redis实例中被COW的数据页只有一小部分而已。每个页大小4KB，一个Redis实例一般有成千上万个页面。
子进程没有因为数据变化影响，他们看到内存中数据就是fork产生的瞬间的那个内存中的所有数据，我们将这瞬间的数据看成是一个SNASHOP，所以RDB也叫快照的原因。

Redis提供了bgrewriteaof指令对AOF日志瘦身。原理如下：
- fork一个子进程对内存进行遍历，转换成一些列Redis的操作指令例如set， hset等，重写序列化到新的AOF文件中
- 完成存量的AOF之后，在操作期间的增量AOF日志追加到新的AOF日志文件中，然后替代原有AOF文件。

还回归到IO操作的问题上，在AOF日志写入时候，实际上是将内容写到内核为文件描述符分配的的一个内存缓冲区中。然后内核在异步将数据刷回磁盘，这时候宕机，AOF日志可能丢失
Linux的glibc提供了fsync（int fd）函数可以指定文件的内容强制从内核缓冲区刷新到磁盘。Redis调用fsync就可以保证不丢失，但是IO一次很慢，每次一条命令都一次IO操作性能会很受影响。
Redis提供两种策略：
- 一个永不主动调用fsync，让系统决定何时同步磁盘，非安全性的操作
- 另一个每个指令都调用fsync一次，会导致Redis延迟变得异常大，影响效率，不推荐

快照是通过开启子进程方式进行，他比较消耗资源的操作
- 遍历整个内存，大块写磁盘家中系统负载
- AOF的fsync是耗时的IO操作，会降低Redis性能，同时频繁IO增加系统负担。
利用从节点进行持久化，在备份节点没有来自客户端压力，操作系统资源充沛，问题在于需要保证从节点的数据完整性，例如异地多活导致的网络分区，造成数据延迟，会导致一部分数据延迟此时持久化就丢了这部分数据量。应该增加数据监控，保证完了畅通或者能快速恢复

重启Redis时候，很少使用RDB恢复，因为会丢失大量数据。我们通常用AOF回放，但是AOF回放启动时候加载太慢，导致启动时间变长。
Redis4.0 解决了这个问题，兼具AOF，RDB的长处-----混合持久化
- 将RDB文件的内容与RDB之后的增量修改AOF文件保存在一起
- 此处AOF日志不是全量日志，而是RDB结束后的AOF日志信息，这样日志量就少太多
- Redis重启后，先加载Rdb内容，在回放AOF日志，可以完全替代之前的AOF全量，重启效率增加
如下图。