9.Redis持久化之RDB

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.

　　　　save 900 10    #如果900秒内有10条Key信息发生变化，则进行快照

　　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持久化方式来解决实时持久化问题。