Redis入门之浅谈rdb持久化机制

什么是redis的持久化呢？答案就是两个词：RDB、AOF，aof的基础操作我已经在另一篇文章中介绍了，现在我们来谈一谈redis的rdb原理。

什么是rdb呢，它是redis database的缩写，它是的主要工作就是在指定时间间隔内将内存中的数据集快照写入磁盘，redis是内存数据库，速度快是它的主要有点，但是一旦关闭电源，内存中的数据将不复存在，rdb就是姜数据即使的写入磁盘进行持久化。

首先我们先看看redis的配置文件，配置文件中，可以找到快照配置部分，这里面详细的介绍了rdb的配置。





可以看到，redis的rdb一共有三种工作方式：

1.      900秒（15分钟）内，只要有一个key被改动过；

2.      300秒，key被改动10次

3.      60秒改动10000次

注意，这里的第二种是我改动后的，方便实际测试，也就是两分钟内数据总共被修改了十次，那么将触发redis的持久化。下面我们来做个测试：



首先可以看到现在还没有dump.rdn文件（rdb机制就是每个一定时间将内存数据写入磁盘，生成一个文件，在配置文件中可以修改生成的rdb文件名，默认的是dump.rdb，并且新的rdb文件会覆盖掉原来的rdb文件），而且现在数据空中没有任何数据，那么我开始存储数据，然后测试是否能生成rdb文件：



可以看到，我连续存储了11条数据之后，就会生成一个dump.rdb文件。



需要注意的是，在实际应用中，我们需要将rdb文件放在另外一台机器上，以便当前服务器损坏，我们复制一份取名为dump_1.rdb，那么现在我们来模拟一下异常看看这个rdb文件是否能帮助我们恢复数据，也就是说它是否真的存储数据了。执行flushall+shutdown：



如上图所示，现在的数据库应该是空的，redis已经停止，这里有一个细节需要注意一下，我们的rdb文件的生成时间已经更改，看一下时间，可以知道现在这个dunp.rdb已经不是我们第一次的那个文件了，在我shutdown之后强行生成了一个新的rdb文件并且将原来的rdb文件覆盖掉了（这个是重点，画上，要考哈哈...往后看）。那么现在我们重新连接redis，按道理是应该可以恢复数据的，我们来看看：



可以看到，依然是空的，没有任何数据，难道rdb不好使了吗，当然不是啦，这其中的原因就是在上一步我们执行flushall的时候内存数据已经清空，再执行shutsown的时候redis会强制提交数据，类似于commit操作，这样，空的数据提交上去覆盖了原来的rdb文件，结果就是新的rdb文件里面什么也没记录。

不过没关系，还记得我们再flushall之前备份了一份rdb文件吧，现在删除这个dump.rdn文件，然后copy dump_1.rdn文件（注意，这个操作一定要先退出redis，否则你复制完了再退出，一样会强制生成空的rdb文件，我刚犯的错误...），再来测试一遍：



可以看到，数据确实成功恢复了。

那么现在又有一个需求，现在我有一个非常重要的数据，需要立即存储到磁盘中，不能等，怎么办呢，这里就需要使用save命令，这个命令就是立即持久化，马上生成rdb文件，我们可以测试一下：



现在的rdb文件生成时间是13:52,我插入一条数据，然后执行save，可以看到，再次显示文件的时候rdb文件的生成时间变成了13:55，看一下linux系统时间，也就是刚刚生成的，说明save命令会立即生成rdb文件。

注意：

    1. 如果想即刻备份，可以用save命令，同时还有一个gbsave命令，他们的区别是save是同步的，也就是说在进行备份的时候redis是阻塞状态，而bgsave是异步的。

    2.不光shutdown会产生rdb文件，flushall也会 产生rdb文件，只不过是空的文件。

最后，rdb机制适合大数据的存储，但是它的缺点很明显，每次备份的时候都会fork一个线程，与当前线程是一模一样的，这样影响系统效率。还有一点就是如果在备份的时候挂掉了，那么最后一次的数据将丢失。