redis关于rdb

背景：因为aof的进行故障恢复的时候 需要执行每一行的命令行,如果操作日志非常多的话，redis就会恢复的很缓慢，就会影响到正常的redis使用。这不是理想的结果。所以在redis的文件恢复操作过程中会有另一种文件产生

就是RDB，与AOF文件相比，RDB记录的某一个时刻的redis数据快照，而不是操作记录。当redis宕机的时候 可以直接把RDB文件读入到内存中去。

 

生成RDB的方法

有两种方式可以生成RDB

1 save 在主线程生成RDB快照，会造成阻塞

2 bgsave：创建一个子线程，专门用于写入RDB文件，避免了主线程的阻塞。这是redis的默认配置。

生成RDB的流程

1 bgsave子线程是由主线程fork生成的，可以共享主线程所有的内存数据，bgsave子线程在运行的时候，会读取主线程的内存数据，并把他们写入RDB数据中去。

2  在同步过程中如果有读数据的请求 不会影响到子线程的同步，如果有有写请求的话 子线程就会把新的数据复制一份生成该数据的副本，bgsave子线程会把这个副本文件写入到RDB文件中去。

 

RDB文件的应用

如上文所示:

如果在T0时刻和T0+t 中间时刻发生宕机的话，那么可能会造成数据的丢失。

问题:如果缩小t的时间 去做RDB的话 不仅会带来磁盘的压力 也有可能会造成恶性循环的RDB文件，比如说主内存的数据是4G 同步的速度是0.2G/s 最终同步完的时间是20s。

redis恢复数据的解决方案

采用AOF文件和RDB文件共同工作的方式来实现redis的数据恢复

方案是：

1 隔一段时间生成一个RDB文件

2 在两次快照执行的间隙，使用AOF文件来执行这期间所有的命令操作。

优点：

1 不用频繁的fork主线程，因为在fork主线程的过程中也会对主线程有影响。

2 aof文件只记录两次rdb之间的操作 就不会出现文件过大的情况，避免重写的开销