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

喜欢ヅ旅行 2022-12-20 12:32 126阅读 0赞

#### 持久化 ####

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

##### RDB快照原理 #####

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

##### fork多进程 #####

*  Redis在持久化时候会调用glibc函数，fork产生一个子进程，持久化是由子进程完成，父进程处理客户端请求。
 *  子进程产生和父进程共享内存中代码段与数据段，这是linux操作系统机制，为节约内存，可以尽可能让他们共享，分离瞬间内存增长几乎不变。
 *  用如下伪代码来说明fork过程，fork时候在父进程中返回子进程pid，子进程返回0，资源不足返回error。

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瞬间的那个版本。如下示意图。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center 1]
 *  如上图示意，随着父进程的修改操作越多，只会COW出更多数据页而已，占用部分内存，但是也不可能超过原内存2倍（不可能所有页都在修改）。另外Redis冷数据占比更大，所以Redis实例中被COW的数据页只有一小部分而已。每个页大小4KB，一个Redis实例一般有成千上万个页面。
 *  子进程没有因为数据变化影响，他们看到内存中数据就是fork产生的瞬间的那个内存中的所有数据，我们将这瞬间的数据看成是一个SNASHOP，所以RDB也叫快照的原因。

#### AOF原理 ####

*  AOF日志存储的是Redis服务器的顺序指令执行序列，AOF日志只记录内存进行修改的指令记录
 *  例如有一份AOF日志记录了Redis实例从创建以来的所有修改性指令，那么就可以通过对一个空Redis实例顺序执行所有指令的方式来复刻当前Redis的状态。
 *  Redis收到客户端指令，先进行校验，逻辑处理，没有问题，在存储AOF日志。先执行在存盘。
 *  缺点，AOF日志随着Redis不断运行逐渐变大，加入宕机，加载AOF文件可能需要非常久时间，期间无法对外提供服务。

##### AOF重写 #####

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

##### fsync #####

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

##### 生产做法 #####

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

##### Redis4.0 混合持久化 #####

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

[上一篇：Redis高效性探索–管道][Redis]  
[下一篇：Redis–事务][Redis 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/3fa1cec1c99842879915beb92819b4ff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/6770742377554e0caeaff5174cecac22.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20201112151353589.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy,size_16,color_FFFFFF,t_70#pic_center
[Redis]: https://blog.csdn.net/liaojiamin0102/article/details/109646371
[Redis 1]: https://blog.csdn.net/liaojiamin0102/article/details/109688568