Redis持久化之RDB原理

一、为什么需要持久化

        redis里有10gb数据，突然停电或者意外宕机了，再启动的时候10gb都没了？！所以需要持久化，宕机后再通过持久化文件将数据恢复。

二、优缺点

1、rdb文件

        rdb文件都是二进制，很小。比如内存数据有10gb，rdb文件可能就1gb，只是举例。

2、优点

        由于rdb文件都是二进制文件，所以很小，在灾难恢复的时候会快些。

        他的效率（主进程处理命令的效率，而不是持久化的效率）相对于aof要高（bgsave而不是save），因为每来个请求他都不会处理任何事，只是bgsave的时候他会fork()子进程且可能copyonwrite，但copyonwrite只是一个寻址的过程，纳秒级别的。而aof每次都是写盘操作，毫秒级别。没法比。

3、缺点

        数据可靠性比aof低，也就是会丢失的多。因为aof可以配置每秒都持久化或者每个命令处理完就持久化一次这种高频率的操作，而rdb的话虽然也是靠配置进行bgsave，但是没有aof配置那么灵活，也没aof持久化快，因为rdb每次全量，aof每次只追加。

三、RDB持久化的两种方法

        配置文件也可以配置触发rdb的规则。配置文件配置的规则采取的是bgsave的原理。

1、save

        1.1、描述

        同步、阻塞

        1.2、缺点

        致命的问题，持久化的时候redis服务阻塞（准确的说会阻塞当前执行save命令的线程，但是redis是单线程的，所以整个服务会阻塞），不能继对外提供请求，GG！数据量小的话肯定影响不大，数据量大呢？每次复制需要1小时，那就相当于停机一小时。

2、bgsave

        2.1、描述

        异步、非阻塞

        2.2、原理

        fork() + copyonwrite

        2.3、优点

        他可以一边进行持久化，一边对外提供读写服务，互不影响，新写的数据对我持久化不会造成数据影响，你持久化的过程中报错或者耗时太久都对我当前对外提供请求的服务不会产生任何影响。持久化完会将新的rdb文件覆盖之前的。

四、fork()

        bgsave原理是fork() + copyonwrite，那么现在来聊一下fork()

1、fork()是什么

        fork()是unix和linux这种操作系统的一个api，而不是Redis的api。

2、fork()有什么用

        fork()用于创建一个子进程，注意是子进程，不是子线程。fork()出来的进程共享其父类的内存数据。仅仅是共享fork()出子进程的那一刻的内存数据，后期主进程修改数据对子进程不可见，同理，子进程修改的数据对主进程也不可见。比如：A进程fork()了一个子进程B，那么A进程就称之为主进程，这时候主进程子进程所指向的内存空间是同一个，所以他们的数据一致。但是A修改了内存上的一条数据，这时候B是看不到的，A新增一条数据，删除一条数据，B都是看不到的。而且子进程B出问题了，对我主进程A完全没影响，我依然可以对外提供服务，但是主进程挂了，子进程也必须跟随一起挂。这一点有点像守护线程的概念。Redis正是巧妙的运用了fork()这个牛逼的api来完成RDB的持久化操作。

五、Redis中的fork()

        Redis巧妙的运用了fork()。当bgsave执行时，Redis主进程会判断当前是否有fork()出来的子进程，若有则忽略，若没有则会fork()出一个子进程来执行rdb文件持久化的工作，子进程与Redis主进程共享同一份内存空间，所以子进程可以搞他的rdb文件持久化工作，主进程又能继续他的对外提供服务，二者互不影响。我们说了他们之后的修改内存数据对彼此不可见，但是明明指向的都是同一块内存空间，这是咋搞得？肯定不可能是fork()出来子进程后顺带复制了一份数据出来，如果是这样的话比如我有4g内存，那么其实最大有限空间是2g，我要给rdb留出一半空间来，扯淡一样！那他咋做的？采取了copyonwrite技术。
 

六、copyonwrite

很简单，现在不就是主进程和子进程共享了一块内存空间，怎么做到的彼此更改互不影响吗？(执行快照时，数据能被修改吗？写时复制技术（Copy-On-Write, COW）)

1、原理

        主进程fork()子进程之后，内核把主进程中所有的内存页的权限都设为read-only，然后子进程的地址空间指向主进程。这也就是共享了主进程的内存，当其中某个进程写内存时(这里肯定是主进程写，因为子进程只负责rdb文件持久化工作，不参与客户端的请求)，CPU硬件检测到内存页是read-only的，于是触发页异常中断（page-fault），陷入内核的一个中断例程。中断例程中，内核就会把触发的异常的页复制一份（这里仅仅复制异常页，也就是所修改的那个数据页，而不是内存中的全部数据），于是主子进程各自持有独立的一份。

        copyonwrite的意思就是写时复制，创建子进程的时候不复制，这样创建进程就变快了，说白了玩的就是指针。

        父子进程的数据是隔离的。父进程调用了一个fock(),创建了一个子进程，写的速度更快，而且不会栈出内存，父进程如果有10个G，并不是把10个G拷贝过来，而是一些地址的映射关系等

 数据修改之前的样子

数据修改之后的样子

每个小格子代表数据页，假设k1数据页是主进程里面的第三个格子

黑色格子表示k1发生cow（copyonwrite）后新的内存地址，其他格子内存地址不变，子进程中的数据页的内存地址依然是旧的内存地址 

如果主线程要修改一块数据(例如图中的键值对 C)， 那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

细心的同学，肯定发现了，bgsave 快照过程中，如果主线程修改了共享数据，发生了写时复制后，RDB 快照保存的是原本的内存数据，而主线程刚修改的数据，是没办法在这一时间写入 RDB 文件的，只能交由下一次的 bgsave 快照。

所以 Redis 在使用 bgsave 快照过程中，如果主线程修改了内存数据，不管是否是共享的内存数据，RDB 快照都无法写入主线程刚修改的数据，因为此时主线程（父进程）的内存数据和子进程的内存数据已经分离了，子进程写入到 RDB 文件的内存数据只能是原本的内存数据。

如果系统恰好在 RDB 快照文件创建完毕后崩溃了，那么 Redis 将会丢失主线程在快照期间修改的数据。

另外，写时复制的时候会出现这么个极端的情况。

在 Redis 执行 RDB 持久化期间，刚 fork 时，主进程和子进程共享同一物理内存，但是途中主进程处理了写操作，修改了共享内存，于是当前被修改的数据的物理内存就会被复制一份。

那么极端情况下，如果所有的共享内存都被修改，则此时的内存占用是原先的 2 倍。

所以，针对写操作多的场景，我们要留意下快照过程中内存的变化，防止内存被占满了。

2、回到原问题

        其实就是更改数据的之前进行copy一份更改数据的数据页出来，比如主进程收到了set k 1请求(之前k的值是2)，然后这同时又有子进程在rdb持久化，那么主进程就会把k这个key的数据页拷贝一份，并且主进程中k这个指针指向新拷贝出来的数据页地址上，然后进行更改值为1的操作，这个主进程k元素地址引用的新拷贝出来的地址，而子进程引用的内存数据k还是修改之前的。

3、一段话总结

        copyonwritefork()出来的子进程共享主进程的物理空间，当主子进程有内存写入操作时，read-only内存页发生中断，将触发的异常的内存页复制一份(其余的页还是共享主进程的)。

4、额外补充

        在 Redis 服务中，子进程只会读取共享内存中的数据，它并不会执行任何写操作，只有主进程会在写入时才会触发这一机制，而对于大多数的 Redis 服务或者数据库，写请求往往都是远小于读请求的，所以使用fork()加上写时拷贝这一机制能够带来非常好的性能，也让BGSAVE这一操作的实现变得很简单。

快照的频率

如果频繁地执行全量快照，也会带来两方面的开销。

• 频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前后交叉，容易造成恶性循环。
• bgsave 子进程通过 fork 操作从主线程创建出来，fork 这个创建过程本身会阻塞主线程，之后不会。
  fork主线程的内存越大，阻塞时间越长
  如果频繁 fork 出 bgsave 子进程，这就会频繁阻塞主线程了。

增量快照

做了一次全量快照后，后续的快照只对修改的数据进行快照记录，这样可以避免每次全量快照的开销。

和AOF 相比，快照的恢复速度快，但快照的频率不好把握

• 如果频率太低，两次快照间一旦宕机，就可能有比较多的数据丢失。
• 如果频率太高， 又会产生额外开销

在第一次做完全量快照后，T1 和 T2 时刻如果再做快照，我们只需要将被修改的数据写入 快照文件就行。但是，这么做的前提是，我们需要记住哪些数据被修改了。

混合日志和快照

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。
内存快照以一 定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

 

七、疑问

0、调用fork()也会阻塞啊

        我只能说没毛病，但是这个阻塞真的可以忽略不计。尤其是相对于阻塞主线程的save。

1、会同时存在多个子进程吗？

        不会，主进程每次收到bgsave命令需要fork()子进程之前都会判断是否存在子进程了，若存在也会忽略掉这次bgsave请求。若不存在我会fork()出子进程进行工作。

为什么这么搞？

我猜测原因如下:

        1.如果支持并行存在多个子进程，那么不仅会拉低服务器性能，还会造成数据问题，比如八点的bgsave在工作，九点又来个bgsave命令。这时候九点的先执行完了，八点的后执行完了，那九点的不白执行了吗？这是我所谓的数据问题。再比如，都没执行完，十点又开一个bgsave，越积越多，服务器性能被拉低。

        2.那为什么不阻塞？判断有子进程在工作，就等待，等他执行完我在上场，那一样，越积越多，文件过大，只会造成堆积。

2、如果没有copyonwrite这种技术是什么效果？

        1.假设是全量复制，那么内存空间直接减半，浪费资源不说，数据量10g，全量复制这10g的时间也够长的。这谁顶得住？2.如果不全量复制，会是怎样？相当于我一边复制，你一边写数据，看着貌似问题不大，其实不然。比如现在Redis里有k1的值是1，k2的值是

        2，比如bgsave了，这时候rdb写入了k1的值，在写k2的值之前时，有个客户端请求

set k1 11 
set k2 22

        那么持久化进去的是k2 22，但是k1的值还是1，而不是最新的11，所以会造成数据问题，所以采取了copyonwrite技术来保证触发bgsave请求的时候无论你怎么更改，都对我rdb文件的数据持久化不会造成任何影响。

 
————————————————
版权声明：本文为CSDN博主「会飞的IT蜗牛」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ymb615ymb/article/details/123392106

————————————————
版权声明：本文为CSDN博主「程序员面试那点事儿」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_23864697/article/details/110395710