针对Redis的话题估计有些读者已经开始反感了，昨天还是有一些读者困惑，这就具体讲述下Redis持久化方式-RDB的实现方式~
01
触发时机
手动触发:
save: 阻塞当前 Redis 服务器, 直到 RDB 过程完成为止, 对于内存比较大的实例会造成长时间阻塞, 线上环境不建议使用
bgsave: Redis 进程执行 fork 操作创建子进程, RDB 持久化过程由子进程负责, 完成后自动结束。阻塞只发生在 fork 阶段, 一般时间很短
自动触发 RDB 的持久化机制, 例如以下场景:
使用 save 相关配置, 如 “save m n”。表示 m 秒内数据集存在 n 次修改时, 自动触发 bgsave。
如果从节点执行全量复制操作, 主节点自动执行 bgsave 生成RDB文件并发送给从节点, 更多细节见6.3节介绍的复制原理。
执行 debug reload 命令重新加载 Redis 时, 也会自动触发 save 操作。(不清楚是 save 还是 bgsave)
默认情况下执行 shutdown 命令时, 如果没有开启 AOF 持久化功能则自动执行 bgsave。
02
流程说明
03
RDB的文件处理
保存: RDB 文件保存在 dir 配置指定的目录下, 文件名通过 dbfilename 配置指定。可以通过执行 config set dir {newDir} 和 config set dbfilename {newFileName} 运行期动态执行, 当下次运行时 RDB 文件会保存到新目录。
压缩: Redis 默认采用 LZF 算法对生成的 RDB 文件做压缩处理, 压缩后的文件远远小于内存大小, 默认开启, 可以通过参数 config set rdbcompression {yes|no} 动态修改。
校验: 如果 Redis 加载损坏 的RDB 文件时拒绝启动, 并打印如下日志:
# Short read or OOM loading DB. Unrecoverable error, aborting now.
这时可以使用 Redis 提供的 redis-check-dump 工具检测 RDB 文件并获取对应的错误报告。
04
RDB的优缺点
优点:
RDB 是一个紧凑压缩的二进制文件, 代表 Redis 在某个时间点上的数据快照。非常适用于备份, 全量复制等场景
Redis 加载 RDB 恢复数据远远快于 AOF 的方式
缺点:
RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程, 属于重量级操作, 频繁执行成本过高
RDB 文件使用特定二进制格式保存, Redis 版本演进过程中有多个格式的 RDB 版本, 存在老版本 Redis 服务无法兼容新版 RDB 格式的问题
- END -
针对Redis的持久化方式原先有整理过一期视频
往期推荐
[
如何提高你的代码设计能力？
](https://www.oschina.net/action/GoToLink?url=http%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzU3OTc1MDM1Mg%3D%3D%26mid%3D2247493387%26idx%3D1%26sn%3D2e0793e9333fef0b083cb31424b71df7%26chksm%3Dfd63f7b4ca147ea272ef73b8766068282acd1849c7ca1c43e2bffd74c1c42d38bb6759cc925d%26scene%3D21%23wechat_redirect)
[
什么是存储过程，在实际项目中用得多么？
](https://www.oschina.net/action/GoToLink?url=http%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzU3OTc1MDM1Mg%3D%3D%26mid%3D2247493138%26idx%3D1%26sn%3Ddb8ad5e787ef93be7ba4304c51928891%26chksm%3Dfd63f6adca147fbb522b00f7fcd661d5051fe1c35f7c43d94c75b59d4a07360e6082a0751f9a%26scene%3D21%23wechat_redirect)
[
Redis主从同步与故障切换，有哪些坑？
](https://www.oschina.net/action/GoToLink?url=http%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzU3OTc1MDM1Mg%3D%3D%26mid%3D2247493021%26idx%3D1%26sn%3D162ff38221f54424e39a9b28a2434991%26chksm%3Dfd63f522ca147c34bfacaaf3a51cacfd246b7268d4c1fe7304cb3dde4d2bdbee971fc220bb46%26scene%3D21%23wechat_redirect)
[
怎么能避免写出慢SQL？
](https://www.oschina.net/action/GoToLink?url=http%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzU3OTc1MDM1Mg%3D%3D%26mid%3D2247492933%26idx%3D1%26sn%3D23f3519f6041f12b900b490c7b0bbf34%26chksm%3Dfd63f5faca147cec8dff49cfde512083f2e451771159e59a49db8c27c9d2974814804102462b%26scene%3D21%23wechat_redirect)
[
如何防止Redis脑裂导致数据丢失？
](https://www.oschina.net/action/GoToLink?url=http%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzU3OTc1MDM1Mg%3D%3D%26mid%3D2247492793%26idx%3D1%26sn%3D2dcc268eb5ede00699a4a2fe99b705e4%26chksm%3Dfd63f406ca147d104b9c6a806c9c1242acbdbadd3d5028a0b268aac83aeadbc731d65653bee7%26scene%3D21%23wechat_redirect)
[
一个几乎每个系统必踩的坑儿：访问数据库超时
](https://www.oschina.net/action/GoToLink?url=http%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzU3OTc1MDM1Mg%3D%3D%26mid%3D2247492745%26idx%3D1%26sn%3Dc9caa6056d282c6ce9796f9c33c3189b%26chksm%3Dfd63f436ca147d209474bcbb5570235f18f405174af8f02df76762508dd2b61f1d0aa5a8b3a5%26scene%3D21%23wechat_redirect)
本文分享自微信公众号 - 码农架构（iByteCoding）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
