Redis持久化RDB

目录

1、简介：

2、如何执行?

3、Fork

4、redis实现RDB

5、优点

6、缺点

---

1、简介：

在指定的时间间隔内将内存的数据快照写入磁盘，也就是行话讲的快照，他恢复时是将快照的文件的直接读到内存里。

2、如何执行?

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

3、Fork

Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程
在Linux 程序中, fork(会产生一个和父进程完全相同的子进程,但子进程在此后多会exec系统调用,出于效率考虑, Linux中引入了“写时复制技术”。
一般情况父进程和子进程会共用同一 段物理内存，只有进程空间的各段的内容要
发生变化时,才会将父进程的内容复制一份给子进程。

 

复制的进程信息不会立即放到持久化文件中，而是有一个临时区域。先将数据放到临时区域，等待处同步完成再放到持久化文件中。

简单理解

 

为什么不直接放到持久化文件中呢？

假如说我程序正在执行但是我突然程序非正常挂掉了，而此时复制的不完整数据也被储存在了持久化文件中，这就造成持久化文件的不完整。这样就保证了数据的完整性，一致性和安全性。这就是写时复制技术。

4、redis实现RDB

首先在redis启动目录的bin下，可以看到dump.rdb文件

 然后持久化的相关配置是在redis.conf内部，，其中几个重要的部分

save

 save 900   1 是指在900秒内至少有1个key变化，就进行持久化操作。

 save 300   10是指在300秒内至少有10个key变化，就进行持久化操作

值得一提的是，save比较任性，他只管保存，其余啥都不管，全部阻塞。手动保存，不建议。

而bgsave：会在后台进行快照操作，快照同时还可以响应客户端请求。

dbfilename

 dir

 stop-writes-on- bgsave-error yes 推荐yes

rdbcompression

 rdbchecksum 检查完整性，在储存快照以后，进行数据校验，虽然这样做会消耗10%的性能但是，开启后会保证数据的正确性，为了提升效率也可以关闭

5、优点

适合大规模的数据恢复。

对数据完整性和一致性要求不高更适合使用。

节省磁盘空间。

恢复速度快。

6、缺点

Fork的时候，内存中的数据被克隆了一份，也就是内存使用应该是两倍。

即使redis在fork时使用了写拷贝技术，但是如果数据量庞大时还是消耗性能

周期性备份，若果某一时刻redis突然挂掉，会丢失最后一次数据。