1.前言
Redis支持RDB和AOF两种持久化机制，持久化功能有效避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。
2.RDB
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化的过程分为手动触发和自动触发
3.触发机制
手动触发对应的命令是save和bgsave命令：
- save命令：阻塞当前redis服务器，直到服务器RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上不建议使用
- bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程有子进程负责，完成后自动结束。阻塞只发生fork阶段，一般时间很短。
bgsave命令是针对save阻塞问题做了优化，因此Redis内存所有涉及RDB的操作都采用的bgsave，而save命令已经被废弃
自动触发机制：
1）当使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave.
2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
3）执行debug reload命令重新加载redis时，也会自动触发save操作。
4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave
5) 参数：1. dbfilename xxxxx：配置持久化RDB文件名 2. rdbcompression yes 3. rdbchecksum yes 4. stop-writes-on-bgsave-error yes
4.RDB文件处理
RDB文件位置：RDB文件一般会保存在dir配置执行的目录下，文件名通过dbfilename配置指定。可以通过执行config set dir{newdir}和config set dbfilename{newfilename}运行期动态执行，当下次运行时RDB文件会保存到新目录。
另外当遇到坏盘或磁盘写满等情况时，可以通过config set dir{newdir}在线修改文件路径到可用的磁盘路径，之后执行bgsave进行磁盘切换，同样适用于AOF持久化文件。
压缩：虽然压缩RDB会消耗CPU，但可大幅度降低文件体积，方便保存到硬盘或通过网络发送给从节点，因此线上建议开启
校验：如果redis 加载损坏的RDB文件时拒绝启动，并打印如下日志：
# short read or OOM loading DB. Unrecoverable error. aborting now
这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告
5.RDB的优缺点
优点：
- RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适合备份，全量复制等。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器上或者文件系统中(hdfs)，用于灾难恢复
- Redis加载RDB恢复数据远远快于AOF方式
缺点：
- RDB方式数据没办法做到实时持久化/秒级持久化，因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
- RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版本RDB格式的问题。
总结：RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决实时持久化问题。