1.3.1 RDB 快照存储
将内存中的所有数据完整的保存到硬盘中
机制
fork 出一个子进程, 专门进行数据持久化, 将内存中所有数据保存到单个 rdb 文件中 (默认为 dump.rdb)
Redis 重启后, 会加载 rdb 文件中的数据到内存中
触发方式
配置中设置自动持久化策略
SAVE | BGSAVE | SHUTDOWN (前提是设置了自动持久化策略)
相关配置
- save 60 1000 # 多久执行一次自动快照操作 60 秒内如果更新了 1000 次, 则持久化一次
- stop-writes-on-bgsave-error no # 创建快照失败后, 是否继续执行写命令
- rdbcompression yes # 是否对快照文件进行压缩
- dbfilename dump.rdb # 如何命名快照文件
- dir ./ # 快照文件保存的位置
- save # 关闭 RDB 机制
优缺点
优点
方便数据备份: 由于保存到单独的文件中, 易于数据备份 (可以使用定时任务, 定时将文件发送给数据备份中心)
写时复制: 子进程单独完成持久化操作, 父进程不参与 IO 操作, 最大化 Redis 性能
恢复大量数据时, 速度优于 AOF
缺点
不是实时保存数据, 如果 Redis 意外停止工作 (如电源断电等), 则可能会丢失一段时间的数据
数据量大时, fork 进程会比较慢, 持久化时使 Redis 响应速度变慢
1.3.2 AOF 只追加文件
Append-only file 只追加文件
只追加 而 不是全部重新写入
追加命令, 而不是数据
机制
主线程将 写命令 追加到 aof_buf(缓冲区) 中, 根据使用的策略不同, 子线程 将缓存区的命令写入到 aof 文件中 (不使用子进程)
当 Redis 重启时, 会重新执行 aof 文件中的命令来恢复数据
如果同时开启了 RDB, 则优先使用 AOF
文件修复
如果 AOF 出错 (磁盘满了 / 写入中途宕机等), 则 Redis 重启时会拒绝使用该 AOF 文件
修复步骤
首先备份 AOF 文件
使用 Redis-check-aof 工具进行修复 (一般会删除末尾无法恢复的命令)
重启 Redis 服务器, 自动载入修复后的 AOF 文件, 进行数据恢复
- $ Redis-check-aof -fix
- # 可选操作: 使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份, 查看两个文件之间的不同之处.
文件重写 / 压缩
AOF 提供了重写 / 压缩机制 (优化命令), 以避免 AOF 文件过大
fork 子进程来完成 AOF 重写
相关配置
- appendonly no # 是否开启 AOF 机制
- appendfsync everysec # 多久将写入的内容同步到硬盘 每秒一次
- no-appendfsync-on-rewirete no # 重写 aof 文件时是否执行同步操作
- auto-aof-rewrite-percentage 100 # 多久执行一次 aof 重写, 当 aof 文件的体积比上一次重写后的 aof 文件大了一倍时
- auto-aof-rewrite-min-size 64mb # 多久执行一次 aof 重写, 当 aof 文件体积大于 64mb 时
- appendfilename appendonly.aof # aof 文件名
- dir ./ # aof 文件保存的位置 (和 rdb 文件共享该配置)
优缺点
优点
更可靠 默认每秒同步一次操作, 最多丢失一秒数据
提供了三种策略, 还可以自动同步 / 每次写同步 / 每秒同步
可以进行文件重写, 以避免 AOF 文件过大
缺点
相同数据集, AOF 文件比 RDB 体积大, 恢复速度慢
1.3.3 如何选择
对于更新频繁, 一致性要求不是非常高的数据 可以选择使用 Redis 进行持久化存储
RDB or AOF
数据安全性要求高, 都打开
可以接受短时间的数据丢失, 只使用 RDB
即使使用 AOF, 最好也开启 RDB, 因为便于备份并且回复速度快, bug 更少
项目中的应用
使用 Redis 进行一部分数据的持久化存储
用户的阅读历史 / 搜索历史
两种持久化机制都开启了
来源: http://www.bubuko.com/infodetail-3171135.html