一、redis持久化机制
redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化,持久化可以避免因进程退出而造成数据丢失。比如断电恢复数据,就是利用了持久化,但是强制杀掉进程是不会被持久化的。
二、RDB
RDB持久化把当前进程数据生成快照(.rdb)文件保存到硬盘的过程,可以选择手动触发
和自动触发
。
手动触发有save和bgsave两命令
save命令:阻塞当前Redis,直到RDB持久化过程完成为止,若内存实例比较大会造成长时间阻塞,线上环境不建议用它
bgsave命令:redis进程执行fork操作创建子线程,由子线程完成持久化,阻塞时间很短(微秒级),是save的优化,在执行redis-cli shutdown关闭redis服务时,如果没有开启AOF持久化,自动执行bgsave;
RDB操作:
设置rdb文件存放路径:config set dir /usr/local/redisbackup
127.0.0.1:6379> config set dir /usr/local/redisbackup
OK
然后执行bgsave,可以看到/usr/local/redisbackup
下有个dump.rdb
文件
127.0.0.1:6379> bgsave
Background saving started
恢复: 将dump.rdb文件放在redis安装目录与redis.conf同级即可。然后重启redis。
RDB的优缺点
优点:
1、压缩后的二进制文件适用于备份、全量复制,用于灾难恢复
2、加载恢复速度远快于AOF
缺点:
1、无法做到实时的持久化
2、每次都要创建子线程,频繁操作成本过高
3、保存后的rdb文件,会存在版本不兼容问题
三、AOF
针对RDB不适合实时的持久化,redis提供了AOF来解决。
打开redis.conf文件,发现默认是关闭的。修改为yes。重启redis。
3.1 AOF持久流程
1、所有的写入命令会先追加到aof_buf(缓冲区)中。
2、aof_buf向硬盘做同步生成aof文件
3、随着aof文件的变大,需定期对aof文件重写(rewrite)
4、当redis重启,加载aof文件。
图解:
3.2 AOF 的一些配置
appendonly yes //启用aof持久化方式
appendfsync always //每收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用
appendfsync everysec //每秒强制写入磁盘一次,性能和持久化方面做了折中,推荐
appendfsync no //完全依赖os,性能最好,持久化没保证(操作系统自身的同步)
no-appendfsync-on-rewrite yes //正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100 //aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb //aof文件,至少超过64M时,重写
四、redis重启时加载AOF与RDB的顺序
1、当AOF和RDB文件同时存在时,优先加载AOF
2、若关闭了AOF,加载RDB文件
3、加载AOF/RDB成功,redis重启成功
4、AOF/RDB存在错误,启动失败打印错误信息