【Redis】持久化机制详解之RDB

持久化其实就4个单词： write data to disk

加强数据安全

Redis支持两种不同的持久化机制，RDB和AOF，今天这篇文章我们来介绍RDB(￣∇￣)/

RDB（默认）

RDB（Redis Database）持久化机制是按照指定的时间间隔将Redis在内存中的数据快照（snapshot）保存到磁盘上 。该机制可以在指定的时间间隔内将内存中的数据保存到磁盘上（📃dump.rdb二进制备份文件），以便在Redis重启后恢复数据。RDB机制能够快速进行备份和恢复操作，并且对于大规模数据的恢复速度比AOF方式更快，但可能会丢失最后一次快照之后的所有更改。

自动触发 🆚 手动触发

按照时间修改频次的自动触发

Redis 7.0（括号内为6.2以前的版本）RDB持久化机制的配置文件redis.conf里配置的选项如下：

复制代码

save 900  1  （3600 1）
save 300  10 （300 100）
save 60 10000（60 10000）

其中，每行配置项表示一个"保存条件"，分别为：

save { seconds} {changes}：在 {seconds} 秒内，如果发生了 {changes} 次修改，则进行持久化。

注意⚠️

物理恢复，服务一定要和备份分机隔离
如果dump.rdb文件报错，可以使用redis-check-rdb /myredis/dumpfiles/dump6379.rdb 命令进行修复（/myredis/dumpfiles/dump6379.rdb需要替换为自己的真实路径）

顺便介绍下配置文件redis.conf中RDB相关的其他配置

snapshotting模块中的配置项
- dbfilename 配置dump.rdb的文件名（建议可以加上端口号，例如dump6379.rdb）
- dir 配置dump.rdb的路径
- stop-write-on-bgsave-error 配置当快照写入失败时，Redis是否继续接受新的写请求
  - 默认yes，即不会，保证数据一致性
- rdbcompression 配置是否进行压缩存储
  - 默认yes，会采用LZF算法进行压缩
- rdbchecksum 配置是否进行数据校验
  - 默认yes，会使用CRC64算法来进行数据校验，这样会增加约10%的性能消耗，希望提升性能可以关闭此功能
- rdb-del-sync-files 配置是否允许在没有持久性的情况下删除复制中使用的RDB文件
  - 默认no
如何禁用快照
- 取消配置文件redis.conf中的# save ""的注释（永久）
- 也可以通过redis-cli config set save ""动态停止RDB保存（重启后失效）

config get/set port/XXX 可以获取/修改配置文件值
- config get dir 可以获取dumpfiles的目录
- config set：动态修改参数，重启后失效
config rewrite：将动态命令写到redis.conf中（redis 2.8及以后才能用）
- config rewrite命令对 redis.conf 文件的重写是原子性的，并且是一致的
  - 如果重写出错或重写期间服务器崩溃，那么重写失败，原有 redis.conf 文件不会被修改
  - 如果重写成功，那么 redis.conf 文件为重写后的新文件

立刻执行的手动触发

save 同步，主程序会阻塞，不再对外提供缓存功能，直到完成文件备份（线上不会使用）
bgsave 异步，不阻塞，备份由后台异步完成，会fork一个子进程由子进程复制持久化过程
- fork 为当前进程制作一个副本（和父进程完全一致的子进程）
- lastsave 查看最后一次成功执行快照的时间（时间戳）
  - date - d @时间戳 根据上面获取的时间戳显示Linux侧时间
- COW 写时复制技术Copy On Write

如何修复RDB文件📃

redis-check-rdb 文件路径

优点

RDB在保存RDB文件时父进程唯一要做的就是fork出一个子进程，接下来的操作都交由子进程来做，父进程无需进行其他任何IO操作，所以RDB持久化方式可以最大化redis的性能
格式紧凑 ，并且RDB文件在内存中加载速度要比AOF快很多
可以按照业务定时备份，适合大规模的数据恢复，以及对数据完整性和一致性要求不高的场景

缺点

数据丢失风险大
- 在一定间隔时间做一次备份，所以如果redis意外down掉的话就会丢失从当前时间到最近的一次快照期间的数据
数据量太大时会影响服务性能
- RDB是内存数据的全量同步，如果数据量太大，I/O操作会严重影响数据库性能
- RDB依赖于主进程的fork，fork的时候内存中的数据被克隆了一份，数据集较大会导致占用内存较高，导致服务请求瞬间延迟

何时会触发RDB快照

符合配置文件中的快照配置
执行save/bgsave命令
执行flushall/flushdb命令（会清空）
执行shutdown并且没有开启AOF持久化
主从复制时，主节点会自动触发

搞定～撒花🎉～～～