1.RDB持久化
- RDB持久化把当前进程数据生成快照(.rdb)文件保存到硬盘的过程,有手动触发和自动触发。
- 手动触发有save和bgsave两命令
1.save命令:阻塞当前Redis,直到RDB持久化过程完成为止,若内存实例比较大会造成长时间阻塞,线上环境不建议用它;
2.bgsave命令:redis进程执行fork操作创建子进程,由子线程完成持久化,阻塞时间很短(微秒级),是save的优化,在执行redis-cli shutdown关闭redis服务时,如果没有开启AOF持久化,自动执行bgsave。
1.1bgsave运行流程
1.2RDB文件的操作
- 命令:config set dir /usr/local //设置rdb文件保存路径
- 备份:bgsave //将dump.rdb保存到usr/local下
- 恢复:将dump.rdb放到redis安装目录与redis.conf同级目录,重启redis即可
- 优点:
1.压缩后的二进制文,适用于备份、全量复制,用于灾难恢复
2.加载RDB恢复数据远快于AOF方式 - 缺点:
1.无法做到实时持久化,每次都要创建子进程,频繁操作成本过高
2.保存后的二进制文件,存在老版本不兼容新版本rdb文件的问题
2.AOF持久化
- 针对RDB不适合实时持久化,redis提供了AOF持久化方式来解决
开启:redis.conf设置:appendonly yes (默认不开启,为no)
默认文件名:appendfilename “appendonly.aof”
2.1AOF持久化流程
- 所有的写入命令(set hset)会append追加到aof_buf缓冲区中
- AOF缓冲区向硬盘做sync同步
- 随着AOF文件越来越大,需定期对AOF文件rewrite重写,达到压缩
- 当redis服务重启,可load加载AOF文件进行恢复
命令写入(append), 文件同步(sync), 文件重写(BGREWRITEAOF), 重启加载(load)
2.2AOF配置详解
- appendonly yes //启用aof持久化方式
- appendfsync always //每收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用
- appendfsync everysec //每秒强制写入磁盘一次,性能和持久化方面做了折中,推荐
- no-appendfsync-on-rewrite yes //正在导出rdb快照的过程中,要不要停止同步aof
- auto-aof-rewrite-percentage 100 //aof文件大小比起上次重写时的大小,增长率100%时,重写
- auto-aof-rewrite-min-size 64mb //aof文件,至少超过64M时,重写
2.3AOF如何恢复
- 设置appendonly yes;
- 将appendonly.aof放到dir参数指定的目录;
- 启动Redis,Redis会自动加载appendonly.aof文件。
3.redis重启时加载AOF与RDB的顺序
- 当AOF和RDB文件同时存在时,优先加载
- 若关闭了AOF,加载RDB文件
- 加载AOF/RDB成功,redis重启成功
- AOF/RDB存在错误,启动失败打印错误信息