1、RDB和AOF区别对比
2、RDB 持久化
把当前进程数据生成快照(.rdb)文件保存到硬盘的过程,有手动触发 和自动触发
2.1 手动触发有 save 和 bgsave 两命令
2.1.1 save 命令:
- save命令会阻塞当前Redis执行,由于Redis是单线程的,直到RDB保存完毕之后,才能对键值进行操作;
- 如果此时内存数据比较大,会造成长时间的阻塞,不建议线上环境使用这个方法。
使用方式:
127.0.0.1:6379> save
OK
save的配置
如果60秒内有10000个更改,就save,否则300秒内有10个更改就save,否则900秒内有1个更改就save
2.1.2 bgsave 命令:
- redis 进程执行 fork 操作创建子线程,由子线程完成持久化,阻塞时 间很短(微秒级),是 save 的优化,
- 在执行 redis-cli shutdown 关闭 redis 服务时,如果没有开 启 AOF 持久化,自动执行 bgsave; 显然 bgsave 是对 save 的优化。
使用方式
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379>
保存完毕之后,数据会保存到dump.rdb文件中
2.2 RDB 文件的操作
设置 rdb 文件保存路径
config set dir /usr/local
将 dump.rdb 保存到 usr/local 下
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379>
数据恢复
将 dump.rdb 放到 redis 安装目录与 redis.conf 同级目录,重启 redis 即可
RDB优缺点
优点 | 缺点 |
压缩后的二进制文件,适合备份、复制,用来做灾难恢复 | 无法做到实时持久化,每次都要创建子进程 |
加载RDB数据比AOF更快 | 二进制文件老版本不兼容新版本***.rdb文件 |
2.3 AOF 持久化
2.3.1 aof打开方式和数据文件
说明:RDB不支持实时持久化,使用AOF来解决这个问题
打开方式:在redis.conf中设置appendonly yes,看配置文件注释,默认是no关闭的;
默认的数据文件是:appendonly.aof
2.3.2 AOF持久化流程说明:
- 所有的写入命令(set hset mset zset lset)会 append 追加到 aof_buf 缓冲区中
- AOF 缓冲区向硬盘做 sync 同步
- 随着 AOF 文件越来越大,需定期对 AOF 文件 rewrite 重写,达到压缩
- 当 redis 服务重启,可 load 加载 AOF 文件进行恢复
2.3.3 redis持久化配置参数说明
同步时间配置appendfsync
appendonly yes | 打开aof持久化 |
appendfsync always | 只要收到命令就强制写入磁盘,最慢,最安全,不推荐使用 |
appendfsync everysec | 每秒强制写入磁盘,性能和持久化都适中,推荐使用(默认) |
appendfsync no | 让操作系统自己决定,持久化没有保障 |
文件压缩rewrite指令,在文件中的默认值截图
三个参数说明
no-appendfsync-on-rewrite yes | 正在导出 rdb 快照的过程中,要不要停止同步 aof |
auto-aof-rewrite-percentage 100 |
aof
文件大小比起上次重写时的大小
,增长率 100%
时
,
重写
|
auto-aof-rewrite-min-size 64mb | aof 文件>64M,重写 |
2.3.4 AOF数据恢复
1.
设置
appendonly yes
;
2.
将
appendonly.aof
放到
dir
参数指定的目录;
3.
启动
Redis
,
Redis
会自动加载
appendonly.aof
文件。
2.3 redis 重启时恢复加载 AOF 与 RDB 顺序及流程:
1
,当
AOF
和
RDB
文件同时存在时,优先加载AOF
2
,若关闭了
AOF
,加载
RDB
文件
3
,加载
AOF/RDB
成功,
redis
重启成功
4
,
AOF/RDB
存在错误,
redis
启动失败并打印错误信息