Redis持久化之RDB（二）

上一篇博客中我们介绍了如何安装Redis，如果你还不了解请点击：RabbitMQ 入门 Helloworld。这篇中我们将会开始介绍Redis的持久化，持久化在工作当中用的是非常多的，例如hibernate，mybatis……，那么在Redis中的持久化分为RDB，AOF，在本篇博客中将介绍RDB

1.RDB（Redis DataBase）是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里，Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程，也就是说在fork会将内存瞬间增大一倍

2.如何触发RDB快照

在redis的安装目录中，我们可以发现，有这么一个文件

没错，这个就是RDB保存的是dump.rdb，那么这个文件是怎么生成的呢？

首先打开配置文件redis.conf

在配置文件里呢我们会看到这么一段配置，那么这个是什么意思呢？也就是说redis将会在给定的时间的范围之内key的改变此时达到次数，redis将会自动保存keys的改变

例如：

save 900 1

在900秒内如果有一次keys的set或者get操作，redis将会自动保存keys的改变。

那么接下来呢我们将模拟一次触发RDB快照

1);修改redis.conf配置

2)：删除之前生成的dump.rdb

rm -f dump.rdb

3)：执行命令

首先查看文件是否生成了

那么这个时候启动redis，查看keys是否保存了之前的改动

发现这里是空的，并没有保存之前的改动。你这不是坑我吗？你不是说会自动保存的吗？兄弟，消消气，听我细细道来
前面我改的配置是在10秒钟内有两次改动就会自动保存到dump.rdb中，但是我在这里执行了FLUSHALL命令（flushall的意思是清除所有的缓存，也就是删除之前的数据），因为我的这个flushall命令是在10秒钟之内操作的，也就是说这个时候redis并没有保存改动，你执行了flushall就清除了所有的改动，所以并没有保存，这里是故意给大家挖的一个坑。如果没有执行flushall命令，redis将会正常的将keys的改动保存。

有的时候呢有这样的需求：有些比较重要的数据我等不了这个长时间去保存，因为这样可以防止服务器宕机后数据的丢失，那么这个时候呢我们也可以通过save命令手动的保存

OK，模拟触发RDB就到这了

记下来还是回到redis.conf的配置文件，我们可以看到

这个的意思就是说当RDB在后台进程保存失败的时候前台进程就停止写的操作了，默认是yes，如果设置为no，表示你不在乎数据的不一致或者是你还有其他的手段发现和控制

这里询问你是否需要启动压缩算法

rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据的校验，但是这样会增大10%的性能消耗，如果希望得到最大的性能提升，可关闭此功能

第一个是RDB保存文件的名称，第二个是保存的目录

RDB就介绍到这里，到最后我们来看看RDB的优缺点

优势：适合大规模的数据恢复，对数据完整性和一致性要求不高

劣势：在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改，fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

那么该怎么停止RDB快照呢？

动态所有停止RDB保存规则的方法：redis-cli config set save ""

下一次介绍Redis持久化之AOF