-
概述
RDB持久化就是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化分为自动触发和手动触发 -
手动触发
a.save命令
阻塞当前redis服务器，直到RDB过程完成为止，当redis内存中有很多数据需要RDB时，RDB阻塞时间会比较长
说明：save命令执行完成后会将内存中的数据持久化到dump.rdb文件中，下次重启服务会还原到redis内存中；但是，save命令是阻塞的，也就是说在持久化这段时间里，redis是阻塞的，也就是不能处理其他命令（redis单线程架构的原因–同步处理）；这种方式可能会丢失部分数据，比如突然断电，那么最近一次RDB到现在这段时间的数据丢失。采用shutdown方式中断redis，会自动触发执行save,这种方式退出比较安全
b.bgsave命令
redis进程执行fork操作创建子进程，RDB持久化由子进程负责；bgsave方式可以解决save由于数据大阻塞的问题，但是在fork操作创建子进程这段时间，还是会阻塞的（可以忽略）
-
自动触发
所谓自动触发就是我们不需要手动执行save或者bgsave命令去生成RDB快照文件，而是配置文件中配置相应策略，当达到条件时就会触发save操作
a.save seconds changes (配置说明)
seconds表示时间，单位是秒，changes次数，也就是对于key写的次数；就是说如果在多少秒之内执行多少次写操作，那么就执行bgsave操作，可以配置多条策略
说明：我们可以看到，当在30s内，执行了五次写操作，redis会执行bgsave; 可以得知，redis内部都倾向于使用bgsave.(提示：这个需要指定配置文件启动，否则使用默认配置启动将不起作用，并且要在log文件查看) -
总结
无论是手动RDB还是自动，本质上都是一样的（save已经废弃，自动手动用的都是bgsave,区别也就是自动还是手动，都是fork子进程进行RDB），都是在某个时间点生成RDB文件，都有相同的优缺点。优点：
1.RDB方式是一个紧凑压缩的二进制文件，代表某个时间点的快照数据，文件小，恢复数据快（比较AOF，并且可以直接拷贝RDB文件放到新的redis服务目录下就可以恢复，前提条件要RDB文件兼容）缺点：
1.没办法做到实时持久化，会丢失数据（最后一次RDB到故障时间点）
2.每次RDB都要开启子进程fork / 阻塞同步RDB，成本高
3.RDB文件格式不兼容，老版本redis解析不了新版本redis数据，无法恢复
