Redis持久化之RDB

RDB介绍

RDB（Redis DataBase）是Redis持久化的默认机制，RDB持久化方案和AOF有本质的区别，RDB记录的是一瞬间数据库值的快照，而AOF记录的是正确执行的每条命令，这两个持久化的区别映射到现实中有点类似下棋遇到棋手有事，棋局暂停，但是为了下次不需要从头再来，RDB的方式就是给棋盘拍一张照片下次下棋直接按照照片恢复棋盘即可，而AOF则是将棋手走的每一步记录，恢复棋盘的时候需要按顺序执行每一步记录，所以在数据量大的情况下RDB持久化是很占优势的。

RDB持久化如何触发

自动触发

自动的在redis.conf配置文件中有默认配置如下所示

配置save m n表示在m秒内数据集在n次修改后将自动执行bgsave指令，触发RDB持久化。

手动触发

手动触发按照执行的线程又分为两种

• save：在主线程中执行，Redis主线程将阻塞无法处理其它客户端请求，直到RDB持久化结束。
• bgsave：在子线程中执行，Redis会fork一个子进程用于持久化RDB，RDB操作不会对主线程产生影响，但是fork的瞬间如果实例过大一样存在阻塞主线程的风险，这也是RDB持久化的默认配置。

补充点：

• flushall：清空所有数据库的命令时会生成dump.rdb文件，但是毫无意义。
• shutdown：关闭远程服务时会生成dump.rdb文件，这个是有意义的可以保证redis服务关闭，但是RDB持久化条件还未满足时，不会丢失修改数据。

持久化期间是否只读

持久化期间是否允许客户端修改数据呢？这个答案肯定是毋庸置疑的，如果Redis持久化的数据有4个G，持久化的速度为0.2G每秒，那么持久化的时间为20S，如果客户端在持久化期间无法修改数据，那相当于这20S内无法处理写请求，这对于一个高速的内存数据库而言是致命的，那么Redis是如何做到持久化时还能写入的呢？

Redis采用了操作系统提供的优化策略COW（copy on write写入时复制）,在主线程fork子进程时，就会将主线程的内存页表复制一份，子线程就可以通过页表共享主线程的内存数据，当有新数据写入或者修改时主线程会将新数据或修改后的数据写到新的物理内存地址上，并修改主线程自己的内存页表，这时主线程和子线程读取的内存数据就分开了，主线程正常修改对子线程的持久化没有影响，示例图如下所示。

快照间隔如何确定

RDB持久化的间隔对Redis可靠性的保证是十分关键的，如下所示，如果Redis在t1时刻持久化完毕，还没等到t2持久化这时Redis宕机，t1时刻和t2时刻之间的修改将无法恢复。

Redis每次RDB持久化都是全量快照，这样就存在两个快照执行的中间时间修改了数据，但是服务器宕机导致中间时刻数据丢失，如果想要尽量避免只能将t1时刻和t2时刻的时间间隔缩小，这样丢失数据的风险就会降低，但是时间间隔缩小带来的影响就是频繁的持久化，虽然持久化是由子线程完成并不会阻塞当前的主线程，但这也会带来如下几方面的影响

• 频繁的RDB持久化，也就是会频繁的往磁盘写入数据，对磁盘的压力大。
• 虽然持久化不是主线程完成，但是fork子线程这个动作是在主线程做的，随着实例的增大，fork阻塞的时间会延长，频繁的持久化就会阻塞主线程，影响正常业务。

综上两方面考虑缩短t1时刻和t2时刻的时间间隔来达到减低数据丢失的风险，其实并不可取，那么到底如何实现呢？可以记录两次持久化间隔的每一次数据修改或新增即增量快照就可以解决数据丢失问题，如下所示。

但如果特意给RDB持久化单独保存日志信息，那么一条数据修改N次就会有N条修改记录这对于Redis的内存开销是巨大的，显然无法实施，那么有没有替代方案呢？

在Redis4.0推出了正式解决方案，AOF+RDB混合使用，内存快照RDB还是按照一定频率执行，AOF记录两次快照间的命令操作，这样就可以解决因为快照间隔时长导致的数据丢失问题，就算数据丢失也是极少量的数据。

AOF和RDB选择的问题

通过上面的思路我们知道了AOF和RDB其实可以混合使用，但是一定一定注意，不要无脑使用AOF+RDB的形式，一般可以采用如下建议

• AOF和RDB混用的方案适用于数据不能丢失的业务场景。
• 如果允许数据少量丢失我们可以选择RDB持久化方案。
• 如果需要使用AOF做持久化方案那么回写策略可以选择everysec，它是可靠性和性能的折中选择。