我们在拍照的时候，通常摄影师是不让我们动的，因为一动可能照片就模糊了。在Redis 进行内存快照的时候也会如此。如果我们持久化的过程中，有些数据被修改了。那么就会破坏快照的正确性与完整性。
比如在t时刻,我们对内存进行快照，此时我们希望的是记录下来t时刻内存中所有的数据，假设我们的RDB操作需要10s的时间，而t+2s我们执行了一个修改操作把Key1的值由A修改成了B，而此时RDB操作却还没有把Key1的值写入磁盘。在t+5s的时候读取到key1的值写入磁盘。那么此次快照记录的Key1的值就是B，而不是t时刻的A。这样就破坏了RDB文件的正确性。
RDB文件的生成是需要时间的，如果快照执行期间数据不能被修改，对于业务系统来说不能接受的。那么Redis 是如何解决这个问题的呢？
Redis 借助了操作系统提供的写时复制技术（Copy-On-Write, COW），可以让在执行快照的同时，正常处理写操作。简单来说，bgsave fork子进程的时候，并不会完全复制主进程的内存数据，而是只复制必要的虚拟数据结构，并不为其分配真实的物理空间，它与父进程共享同一个物理内存空间。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据，此时会给子进程分配一块物理内存空间，把要修改的数据复制一份，生成该数据的副本到子进程的物理内存空间。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。
2.2 可以频繁进行快照操作吗假设我们在t 时刻做了一次快照，然后又在 t+n 时刻做了一次快照，而在这期间，发生了数据修改。而此时宕机了，那么，只能按照 t 时刻的快照进行恢复。那么这n秒的数据就彻底丢失无法恢复了。
所以，要想尽可能恢复数据，就只能缩短快照执行的时间间隔，间隔的时间越小，丢失数据也就越少。那么可以频繁的执行快照操作吗？
我们知道bgsave 执行时并不阻塞主线程，但是这不代表可以频繁执行快照操作。
一方面，持久化是一个写入磁盘的过程，频繁将全量数据写入磁盘，会给磁盘带来很大压力，频繁执行快照也容易导致前一个快照还没有执行完，后一个又开始了，这样多个快照竞争有限的磁盘带宽，容易造成恶性循环。
再者，bgsave所fork出来的子进程执行操作虽然并不会阻塞父进程的操作，但是fork出子进程的操作却是由主进程完成的，会阻塞主进程，fork子进程需要拷贝进程必要的数据结构，其中有一项就是拷贝内存页表（虚拟内存和物理内存的映射索引表），这个拷贝过程会消耗大量CPU资源，拷贝完成之前整个进程是会阻塞的，阻塞时间取决于整个实例的内存大小，实例越大，内存页表越大，fork阻塞时间也就越久。
也许有人会想到是否可以做增量快照呢？也就是只对上一次快照之后的数据做快照。
首先思路肯定是可以，但是增量快照要求记住哪些数据上一次快照之后产生的。这就需要额外的元数据来记录这些信息，会引入额外的空间消耗。这对于内存资源宝贵的 Redis 来说，并不是一个很好的方案。
如果不能频繁执行快照操作，那么该如何解决两次快照之间的数据丢失的问题呢？Redis 还提供了另外一种持久化方式——AOF(append to file)日志。
关于AOF日志请看Redis持久化——AOF日志