Redis持久化(AOF、RDB)用到的写时复制到底是什么

        Redis中有两种持久化方式，分别为AOF和RDB，这两种方式都会使用写时复制（Copy on Write）,那到底他们是如何工作的呢？

        本文作为Redis持久化AOF和RDB还会配合使用？-CSDN博客的补充内容，请先看上文在看本文，如以了解可跳过。

写时复制(Copy On Write)

        写时复制时计算机领域一种通用的优化策略，其核心思想是，如果有多个调用者同时访问相同的资源(如内存或磁盘中的数据)，它们会共同获取相同的指针指向相同的资源，指针指的是内存页表(虚拟内存和物理内存的映射表)，直到某个调用者修改资源时，系统才会真正复制一份专用副本给该调用者，而其他调用者所见到的最初资源仍然保持不变，这期间对其他调用者是透明的。此做法的主要优点是如果调用者没有修改资源，就不会有副本被创建，因此多个调用者只是读取操作时可以共享一份资源。

        JDK的CopyOnWriteArrayList和CopyOnWriteArraySet容器正是采用了这一思想。简单来说就是平时查询时，都不需要加锁，随便访问，只有在更新的时候，才会从原来的数据复制一个副本出来，然后修改这个副本，最后把原数据替换成这个副本。修改操作时读操作不会阻塞，而是继续读取旧数据。

Redis持久化(AOF、RDB)使用写时复制

        Redis在使用RDB方式进行持久化、AOF重写时，会用到写时复制（Copy On Write）。对Redis来说，主线程fork出bgsave子进程后，bgsave子进程实际是复制了主线程的页表。这些页表中保存了在执行bgsave命令时，主线程的所有数据块在内存中的物理地址。这样一来，bgsave子进程生成RDB时就可以根据页表读取这些数据，再写入磁盘。

        如果此时，主线程接收到写入或修改操作，主线程会使用写时复制机制。具体来说，写时复制就是主线程在有写操作时，才会把这个新写或修改的数据写入到一个新的物理地址中，并修改自己的页表映射。​​​​​​​

        bgsave子进程复制主线程的页表以后，假设主线程需要修改虚拟页3里的数据，那么主线程就需要重新分配一个物理页(假设物理页42)，然后把修改后的物理页3里的数据写到物理页42上，而虚拟页3里原来的数据仍然保存在物理页12上，这时虚拟页3和物理页12的关系，仍然保留在bgsave子进程中。这样可以把虚拟页3中数据写入到RDB文件中。

        因为主线程未阻塞，仍然可以处理新来的请求。如果此时有写操作，Redis会利用操作系统的写时复制(Copy On Write)写入到缓冲区，这样即使宕机了，可以用于恢复。

         虽然写实复制避免了主线程的阻塞，但是还是存在一定程度的阻塞风险。

        首先从主线程fork子进程的一瞬间，主线程还是会阻塞的，fork用操作系统提供的写时复制(Copy On Write)机制，就是为了避免一次性拷贝大量内存数据给子进程造成时间阻塞问题，但fork子进程需要拷贝进程必要的数据结构，其中有一项就是拷贝内存页面（虚拟内存和物理内存的映射索引表），这个拷贝过程会消耗大量的CPU资源，拷贝完成前整个进程造成长时间的阻塞。阻塞时间取决于整个实例的内存大小，实例越大，内存表越大，fork阻塞时间越久。拷贝内存页表完成后，子进程与父进程指向相同的内存地址空间，也就是说此时虽然产生了子进程，但是并没有申请与父进程相同的内存大小。

往期经典内容推荐

透视Redis大key背后的I/O挑战-CSDN博客

直击Redis集群痛点：数据倾斜优化实战，打造高效分布式缓存架构-CSDN博客

Redis突破性能瓶颈：揭示缓存污染之谜并采取革命性防御措施-CSDN博客