Redis持久化

RDB

rdb是在指定的时间间隔内将内存中的数据集快写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。

备份是如何执行的

Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感。拿RDB方式要比AOF更加高效。RDB的缺点是最后一次持久化后的数据可能丢失。

优势:

1.适合大规模的数据恢复

2.对数据完整性和一致性要求不高更适合使用

3.节省磁盘空间

4.恢复速度快

劣势:

1.fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑

2.虽然Redis再fork时使用了写时拷贝技术,但是如果数据庞大时还是会比较消耗性能。

3.在备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改

RDB的备份

模拟数据丢失

先通过config get dir 查询 dump.rdb文件的目录,一般默认在/usr/local/bin下

将dump.rdb 文件复制一份  --- cp dump.rdb d.rdb

删掉dump.rdb  ---  rm -f dump.rd

RDB的恢复:

        1.关闭redis-server 

        2.将d.rdb 文件改为dump.rdb      ---    mv d.rdb dump.rdb

        3.启动redis-server

AOF(Append Only File)

aof是以日志 的形式记录每一个操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以修改文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF持久化流程

  1. 客户端的请求命令会被append追加到AOF缓冲区内;
  2. AOF缓冲区根据AOF持久化策略【always,everysec,no】将操作sync同步到磁盘的AOF文件中
  3. AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量
  4. Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的

AOF 默认不开启,可以在redis.conf配置文件中找到appendonly no改为yes

AOF 于RDB同时开启,系统默认取AOF的数据

AOF同步频率设置

appendfsync always:始终同步,每次Redis的写入都会立刻记入日志,性能较差但数据完整性比较好

appendfsync everysec :每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。

appendfsync no:redis不主动进行同步,把同步时机交给操作系统

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Maserati477

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值