Redis的持久化

Redis的持久化取舍和选择

在这里插入图片描述

持久化的作用

什么是持久化

redis所有的数据都是保存在内存中,对数据的更新将异步的保存在磁盘中,如果数据没有持久到硬盘中,当redis服务器重启,redis数据将会丢失 在这里插入图片描述

RDB

什么是RDB

  • RDB持久化是把当前进程数据生成快照保存到硬盘的过程,触发RDB持久化过程分为手动触发和自动触发。

在这里插入图片描述

RDB触发机制 -- 主要三种

  • save (同步)

    save命令:阻塞当前Redis服务器,知道RDB过程完成为止,对于内存比较大的实例会造成长时间阻塞,先上环境不建议使用

127.0.0.1:6379> save
OK

文件策略 :如存在老的 RDB文件 ,新老替换 时间复杂度 : O(n)

  • bgsave (异步)

    bgsave命令:Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一段时间很短

文件策略 :如存在老的 RDB文件 ,新老替换 时间复杂度 : O(n)

  • 自动触发 (Redis默认RDB持久化方式)

保存:RDB文件保存在dir配置指定的目录下,文件名通过dbfilename配置指定。可以通过执行config set dir {newDir} 和 config set dbfilename {newFileName}运行期动态执行,当下次运行时RDB文件会保存到新目录。

压缩:Redis默认采用LZF算法对生成的RDB文件做压缩处理,压缩后的文件远远小于内存大小,默认开启,可以通过参数config set rdbcompression {yes|no}动态修改。

校验:如果Redis加载损坏的RDB文件时拒绝启动,并打印如下日志:


Short read or OOM loading DB. Unrecoverable error , aborting now. 这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告

127.0.0.1:6379> bgsave
Background saving started

RDB总结

  1. RDB是Redis内存到硬盘的快照,用于持久化。
  2. save 通常会阻Redis
  3. bgsave 不会阻塞Redis,但会fork新经常
  4. save 自动配置满足任意条件就会执行
优点
  1. Redis加载RDB恢复数据远远快于AOF方式。
  2. RDB是一个紧凑压缩的二进制文件,代表Redis在某一个时间点上的数据快照。非常适合用于备份,全量复制等场景。比如每6小时执行bgsave备份,并把RDB文件拷贝到远程机器或者文件系统中(如hdfs),用于灾难恢复。

缺点

  1. 耗时、耗性能,RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。
  2. RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB笨笨,存在老版本Redis服务无法兼容新版RDB格式的问题。

如何恢复

自动恢复:自动读取dump.rdb文件恢复 将备份文件移动到redis安装目录并启动服务即可。 CONFIG GET dir获取目录 注意:对dump.rdb文件进行备份 执行cp命令 cp dump.rdb dumo_new.rdb

AOF

在这里插入图片描述

什么是AOF

AOF(append only file)持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式。

AOF 三种策略

  1. always 在这里插入图片描述

  2. everysec 在这里插入图片描述

  3. no

操作系统决定的 在这里插入图片描述

3者对比

在这里插入图片描述

重写机制

随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制压缩文件体积。AOF文件重写是吧Redis进程内的数据转化为写命令同步到新AOF文件的过程。

作用
  • 减少硬盘占用量
  • 加快恢复速度
重写的2种方式
  • bgrewriteaof
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

在这里插入图片描述

  • aof 重写配置

根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积,默认为64MB

auto-aof-rewrite-percentage:代表当前AOF文件空间(aof_current_size)和上一次重写后AOF文件空间(aof_base_size)的值

自动触发时机=aof_current_size>auto-aof-rewrite-min-size && (aof_current_size-aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage 其中aof_current_size和aof_base_size可以再info Persistence统计信息中查看。

AOF重写流程

在这里插入图片描述

配置

//开启aof
appendonly yes

//aof日志
appendfilename  "appendonly-${port}.aof"

//aof 持久化策略
appendsync eneeyec

//目录
dir /bigdiskpath

//重写的内容配置   
//增长率
auto-aof-rewrite-percentage 100

//尺寸
auto-aof-rewrite-min-size  64mb

恢复数据

1. 设置appendonly yes;
2. 将appendonly.aof放到dir参数指定的目录;
3. 启动Redis,Redis会自动加载appendonly.aof文件。

优缺点

AOF 的优点
  1. 使用 AOF 持久化会让 Redis 变得非常耐久(much more durable):你可以设置不同的 fsync 策略,比如无 fsync ,每秒钟一次 fsync ,或者每次执行写入命令时 fsync 。AOF 的默认策略为每秒钟 fsync 一次,在这种配置下,Redis 仍然可以保持良好的性能,并且就算发生故障停机,也最多只会丢失一秒钟的数据( fsync 会在后台线程执行,所以主线程可以继续努力地处理命令请求)
  2. Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写
缺点
  1. 对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积

RDB和AOF的选择

RDB 和 AOF比较

在这里插入图片描述

RDB 和 AOF ,我应该用哪一个?

一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性, 你应该同时使用两种持久化功能,RDB 当作备份来处理,AOF主要用来恢复数据

个人博客:http://blog.yanxiaolong.cn/

end
  • 作者:yxl(联系作者)
  • 发表时间:2020-10-05 16:54
  • 版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证)
  • 转载声明:如果是转载栈主转载的文章,请附上原文链接
  • 公众号转载:请在文末添加作者公众号二维码(公众号二维码见右边,欢迎关注)
  • 评论