Redis持久化——rdb

        rdb是在指定的时间间隔内内存中的数据集快照写入磁盘，也就是常说的Snapshot快照，它恢复时是将快照文件直接读到内存里.

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

Fork:作用是复制一个与当前进程一样的进程。新进程的所有数据（变量，环境变量，程序计数器等等），数值都会和当前进程一样，但是是一个全新的进程，并作为原进程的子进程。隐患就是如果当前进程特别大，本来程序就慢，又fork了一份，又会降低速度

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

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

RDB保存的是dump.rdb文件

                 

 满足3个条件之一就会触发RDB，生成dump.rdb文件，一般情况下生产上的dump文件都会有备份，如果生产机器上的rdb文件损坏，从备份文件中恢复。也就是冷拷贝，从主机拷贝到备机上，可以cp dump.rdb dump_new.rdb

恢复方式：将备份文件（dump.rdb）移动到redis安装目录并启动服务即可 ，config get dir 可以获取目录

想要禁用的话：save "" 

如果碰到特别重要的数据，需要立刻保存，set之后回车再输入一下save或bgsave就会立刻存到rdb中

save:save时只管保存，其他不管，全部阻塞

bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间

注意：执行flushall命令，也会产生dump.rdb，但是回事空的，没有意义

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

                 

stop-writes-on-bgsave-error yes：后台在保存出错的时候要停止写

rdbcompression yes：对于存储到磁盘中的快照，可以设置成是否进行压缩存储，如果是的话，redis会采用LZF算法进行压缩，如果不想消耗cpu来进行压缩，可以关闭此功能

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

dbfilename dump.rdb：rdb的名字

dir ./：目录