完全搞懂Redis持久化之RDB原理

http://www.javashuo.com/article/p-uiavjars-kp.html

• 1、为何须要持久化
• 2、优缺点
  • 一、rdb文件
  • 二、优势
  • 三、缺点
• 3、RDB持久化的两种方法
  • 一、save
    • 1.一、描述
    • 1.二、缺点
  • 二、bgsave
    • 2.一、描述
    • 2.二、原理
    • 2.三、优势
  • 一、fork()是什么
  • 二、fork()有什么用
• 5、Redis中的fork()
• 6、copyonwrite
  • 一、原理
  • 二、回到原问题
  • 三、一段话总结
  • 四、额外补充
• 7、疑问
  • 0、调用fork()也会阻塞啊
  • 一、会同时存在多个子进程吗？
  • 二、若是没有copyonwrite这种技术是什么效果？
• 8、总结

1、为何须要持久化

redis里有10gb数据，忽然停电或者意外宕机了，再启动的时候10gb都没了？！因此须要持久化，宕机后再经过持久化文件将数据恢复。linux

2、优缺点

一、rdb文件

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

二、优势

• 因为rdb文件都是二进制文件，因此很小，在灾难恢复的时候会快些。
• 他的效率（主进程处理命令的效率，而不是持久化的效率）相对于aof要高（bgsave而不是save），由于每来个请求他都不会处理任何事，只是bgsave的时候他会fork()子进程且可能copyonwrite，但copyonwrite只是一个寻址的过程，纳秒级别的。而aof每次都是写盘操做，毫米级别。无法比。

三、缺点

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

3、RDB持久化的两种方法

配置文件也能够配置触发rdb的规则。配置文件配置的规则采起的是bgsave的原理。数据库

一、save

1.一、描述

同步、阻塞编程

1.二、缺点

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

二、bgsave

2.一、描述

异步、非阻塞服务器

2.二、原理

fork() + copyonwrite微信

2.三、优势

他能够一边进行持久化，一边对外提供读写服务，互不影响，新写的数据对我持久化不会形成数据影响，你持久化的过程当中报错或者耗时过久都对我当前对外提供请求的服务不会产生任何影响。持久化完会将新的rdb文件覆盖以前的。
四 3、fork()异步

bgsave原理是fork() + copyonwrite，那么如今来聊一下fork()svg

一、fork()是什么

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

二、fork()有什么用

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

5、Redis中的fork()

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

6、copyonwrite

很简单，如今不就是主进程和子进程共享了一块内存空间，怎么作到的彼此更改互不影响吗？

一、原理

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

数据修改以后的样子

 

二、回到原问题

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

三、一段话总结

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

四、额外补充

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

7、疑问

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

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

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

不会，主进程每次收到bgsave命令须要fork()子进程以前都会判断是否存在子进程了，若存在也会忽略掉此次bgsave请求。若不存在我会fork()出子进程进行工做。
为何这么搞？
我猜想缘由以下:
1.若是支持并行存在多个子进程，那么不只会拉低服务器性能，还会形成数据问题，好比八点的bgsave在工做，九点又来个bgsave命令。这时候九点的先执行完了，八点的后执行完了，那九点的不白执行了吗？这是我所谓的数据问题。再好比，都没执行完，十点又开一个bgsave，越积越多，服务器性能被拉低。
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文件的数据持久化不会形成任何影响。

8、总结

此篇都是重点，废话不多。没啥可总结的。Redis做者对底层操做系统了解的不少，先是epoll，又是如今的fork()和copyonwrite。佩服三连！！！