系列文章目录
第一章 3分钟理解Redis的RDB持久化机制【最成熟的NOSQL】|不懂来打我。
前言
这是Redis系列的第一篇，由于Redis基础在这个年代我相信绝大部分人都有，而且有大量Redis使用和操作的文章，在这就不再赘述。该文章也是由个人加以理解后产出，目的是为了在网络学习资源中提供自己的一份力量，帮助刚入门小白对于生涩难以理解的书本描述进行协助理解阅读，可能文中存在些许错误，请各位大神不吝赐教嘴下留情。
一、对Redis的了解
我们都知道，Redis做为非常成熟的内存数据库（NOSQL），常常会被选择在缓存场景中使用。说到Redis，我们第一印象几乎就是：速度快，单线程...
二、持久化机制RDB
我们可能经常在各种场景上使用到Redis，如：缓存，锁，消息队列...但是我们应该知道，不管是什么软件，什么系统，大部分都离不开持久化机制。（毕竟谁也不想使用一个，自己辛苦维护的数据因为宕机等原因全没了）而对于我们的Redis而言，也一样。
Redis提供了两种持久化机制，RDB以及AOF，本文我们研究的是RDB。
RDB（Redis Database），也可以称为数据快照，可以简单理解为当前Redis进程中保存的数据全量写入磁盘中。
该机制提供两种使用方式：SAVE和BGSAVE。
SAVE方式由于在持久化过程中需要使用主进程来执行持久化操作，而在执行过程中主进程会阻塞，也就是说这个状态下的主进程是无法向外提供服务的，也就无法处理客户端的命令，在性能上非常差劲，而在我们日常使用最多的以及Redis默认的模式也是BGSAVE方式，所以在这我们就不详细讨论（其实理解了BGSAVE肯定能理解SAVE，毕竟从名称上就知道BGSAVE只是SAVE的异步模式），后续我们的讨论大家可以直接默认都在讨论BGSAVE方式。
RDB持久化流程
简单画了个图，容我慢慢解释。
上图中，当客户端发起了BGSAVE的调用，服务端收到调用后就会fork出一个子进程，并且使用了copy-on-write（写时复制技术），简单来说fork出来的子进程并不会复制主进程的内存，仅仅只复制了主进程的页表，也就是说在这个场景中，主进程和子进程指向了相同的内存，使用这个技术的目的就是单纯的为了快，因为在fork的过程中主进程是会阻塞的，我猜测是为了减少服务的不可用时间而引入这个技术。
而子进程创建出来后，就会开始生成RDB文件。而在RDB文件生成的过程中，如果客户端有新的修改指令操作请求的话，主进程会对其中操作值占用的内存进行复制一份，并且在最新复制的那块内存中进行操作。并且操作完成后主进程对应的内存的指针会指向最新修改的内存，而子进程持久化的过程是不会被影响的。当然这也代表在RDB过程中的操作数据部分是不会被持久化。所以RDB持久化模式对于数据丢失量是比较大的。
RDB持久化会消耗非常多内存吗？
这个问题在上面的讨论中其实有答案，由于我们使用了写实复制技术，所以一开始其实是不会有什么太大内存消耗的，但是我们知道我们在该持久化过程中，如果我们有新的修改指令提交给服务器执行，服务器就会复制内存去把新旧数据进行隔离，而如果在这个过程中有大量操作请求进入的话，会导致内存的大量复制，甚至可能导致内存耗尽。如果机器开启了swap机制的话，可能还会触发swap。导致性能更加低下。
如何触发RDB持久化
触发RDB有两种方式，一种是上文说的手动执行BGSAVE，另一种就是根据配置进行自动触发。
我们先了解Redis进程数据结构中的几个关键值，dirty、lastsave、saveparam。
dirty 代表的是距离上次进行BGSAVE后，所对Redis进行的修改数据的数量。
lastsave 代表的是最后进行BGSAVE完成的时间戳。
saveparam 代表的是触发BGSAVE的规则。
其中saveparam配置可以在配置文件中进行配置，格式是：save m n（代表的是在m秒内执行了n次修改）
而具体触发是依靠cron定时器去循环扫描这些参数是否符合触发条件，如果符合就执行BGSAVE操作。
以下是大致流程：
如何从RDB文件中恢复数据？
比较简单就不画图了。直接口诉吧，偷点懒。
启动Redis的时候，会判断你是否开启AOF持久化模式，如果开启就载入AOF，反之载入RDB文件。
总结
以上就是RDB的大部分内容，简洁易懂，并且如果想要拿去面试的话也完全够了，如果还想深入，那你就去看源码吧，一般来说不对这些中间件进行二次开发的话，其实没必要去了解源码。如果对你有帮助，请各位程序员同胞们多关注！！！点赞！！不要吝啬小手！！这样才有动力继续更新啊！（哭）
655
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
