像上述这样在redis.config中进行配置，如save 900 1 是指在 900 秒内，如果有一个或一个以上的修改操作，那么就自动进行一次自动化备份；save 300 10同样意味着在 300 秒内如果有十次或以上的修改操作，那么就进行数据备份，依次类推。
如果你不想进行数据持久化，只希望数据只在数据库运行时存在于内存中，那么你可以通过 save ""禁止掉数据持久化。
这里再介绍几个在配置文件中与 RDB 持久化相关的系数：
stop-writes-on-bgsave-error：默认值为yes，即当最后一次 RDB 持久化保存文件失败后，拒绝接收数据。这样做的好处是可以让用户意识到数据并没有被成功地持久化，避免后续更严重的业务问题的发生；
rdbcompression：默认值为yes，即代表将存储到磁盘中的快照进行压缩处理；
rdbchecksum：默认值为yes，在快照存储完成后，我们还可以通过CRC64算法来对数据进行校验，这会提升一定的性能消耗；
dbfilename：默认值为dump.rdb，即将快照存储命名为dump.rdb；
dir：设置快照的存储路径。
4. COW机制先前提到了Redis为了不阻塞线上业务，所以需要一边持久化一边响应客户端的请求，因此fork出一个子进程来处理这些保存工作。那么具体这个fork出来的子进程是如何做到使得Redis可以一边做持久化操作，一边做响应工作呢？这就涉及到COW (Copy On Write)机制，那我们具体讲解以下这个COW机制。
Redis在持久化的时候会去调用glibc的函数fork出一个子进程，快照持久化完成交由子进程来处理，父进程继续响应客户端的请求。而在子进程刚刚产生时，它其实使用的是父进程中的代码段和数据段。所以fork之后，kernel会将父进程中所有的内存页的权限都设置为read-only，然后子进程的地址空间指向父进程的地址空间。当父进程写内存时，CPU硬件检测到内存页是read-only的，就会触发页异常中断（page-fault），陷入 kernel 的一个中断例程。中断例程中，kernel就会把触发的异常的页复制一份，于是父子进程各自持有独立的一份。而此时子进程相应的数据还是没有发生变化，依旧是进程产生时那一瞬间的数据，故而子进程可以安心地遍历数据，进行序列化写入磁盘了。
随着父进程修改操作的持续进行，越来越多的共享页面将会被分离出来，内存就会持续增长，但是也不会超过原有数据内存的两倍大小（Redis实例里的冷数据占的比例往往是比较高的，所以很少出现所有页面都被分离的情况）。
COW机制的好处很明显：首先可以减少分配和复制时带来的瞬时延迟，还可以减少不必要的资源分配。但是缺点也很明显：如果父进程接收到大量的写操作，那么将会产生大量的分页错误（页异常中断page-fault）。
5. RDB的优劣相信通过上面内容的讲解，对于RDB持久化以该有一个大致的了解，那么接下来简单总结下RDB的优势以及它的劣势：
优势：
RDB 是一个非常紧凑（compact）的文件（保存二进制数据），它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本；
RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心；
RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作；
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
劣势：
如果业务上需要尽量避免在服务器故障时丢失数据，那么 RDB 并不适合。 虽然 Redis 允许在设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 由于 RDB 文件需要保存整个数据集的状态， 所以这个过程并不快，可能会至少 5 分钟才能完成一次 RDB 文件保存。 在这种情况下， 一旦发生故障停机， 就可能会丢失好几分钟的数据。
每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。
三、AOF 持久化