转载和引用,请注明原文出处! Fork me on GitHub
结局很美妙的事,开头并非如此!

Redis系列七:redis持久化

redis支持RDB和AOF两种持久化机制,持久化可以避免因进程退出而造成数据丢失

一、RDB持久化

RDB持久化把当前进程数据生成快照(.rdb)文件保存到硬盘的过程,有手动触发和自动触发
手动触发有save和bgsave两命令
save命令:阻塞当前Redis,直到RDB持久化过程完成为止,若内存实例比较大会造成长时间阻塞,线上环境不建议用它
bgsave命令:redis进程执行fork操作创建子线程,由子线程完成持久化,阻塞时间很短(微秒级),是save的优化,在执行redis-cli shutdown关闭redis服务时,如果没有开启AOF持久化,自动执行bgsave;
显然bgsave是对save的优化。

bgsave运行流程

RDB文件的操作

   命令:config set dir /usr/local  //设置rdb文件保存路径

   备份:bgsave  //将dump.rdb保存到usr/local下

   恢复:将dump.rdb放到redis安装目录与redis.conf同级目录,重启redis即可

   优点:1,压缩后的二进制文文件适用于备份、全量复制,用于灾难恢复

              2,加载RDB恢复数据远快于AOF方式

   缺点:1,无法做到实时持久化,每次都要创建子进程,频繁操作成本过高

              2,保存后的二进制文件,存在老版本不兼容新版本rdb文件的问题  

二、AOF持久化

针对RDB不适合实时持久化,redis提供了AOF持久化方式来解决

开启:redis.conf设置:appendonly yes  (默认不开启,为no)

默认文件名:appendfilename "appendonly.aof"   

      流程说明:

    1,所有的写入命令(set hset)append追加到aof_buf缓冲区中

         2AOF缓冲区向硬盘做sync同步

         3,随着AOF文件越来越大,需定期对AOF文件rewrite重写,达到压缩

         4,当redis服务重启,可load加载AOF文件进行恢复

AOF持久化流程:命令写入(append),文件同步(sync),文件重写(rewrite),重启加载(load)

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,重写

如何从AOF恢复?

1. 设置appendonly yes

2. appendonly.aof放到dir参数指定的目录;

3. 启动RedisRedis会自动加载appendonly.aof文件。

redis重启时恢复加载AOF与RDB顺序及流程:

1,当AOFRDB文件同时存在时,优先加载AOF

2,若关闭了AOF,加载RDB文件

3,加载AOF/RDB成功,redis重启成功

4AOF/RDB存在错误,redis启动失败并打印错误信息

 

posted @ 2018-01-29 22:20  小不点啊  阅读(2070)  评论(0编辑  收藏  举报