20200409——Redis 持久化

持久化

利用永久性存储介质将数据进行保存,在特定的时候将保存的数据进行恢复的工作机制称为持久化。

持久化过程中保存的什么

RDB 第一种:二进制数据,快照形式
AOF 第二种:操作的过程,日志

RDB

save指令

save

在data目录下面
生成dump.rdb文件

save指令的相关配置

在这里插入图片描述

开启压缩,开启文件校验

启动的时候会加载数据

save的工作原理

多个客户端给redis发送指令
单线程任务执行序列
如果我们执行save指令,save指令会阻塞其他的指令。
降低服务器服务效率,造成灾难性服务器

bgsave指令

作用,是后台执行的操作。

工作原理

在这里插入图片描述
调用fork函数,生成子进程,子进程创建rdb文件
对save阻塞问题的优化,redis内部所有涉及到rdb操作都采用bgsave的方式,save可以放弃使用。

RDB启动方式

数据如何进行保存?

redis自动执行,根据设置条件。

save second changes

如果满足在second的时间内,key的变化的数量达到了changes,从而进行redis的持久化,在conf文件里面配置。

在这里插入图片描述

RDB的优势与劣势

优势

rdb是一个紧凑压缩的二进制文件,存储效率高
rdb存储的是redis在某一个时刻的快照,非常适用于数据备份,全量复制等场景,
rdb恢复数据的效率要比aof快很多

劣势

rdb方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能丢失数据

bgsave指令每次都需要创建子进程,需要牺牲一定性能

redis的rdb版本没有统一,可能出现多版本之间,不兼容方面。

AOF

aof解决rdb的缺陷

不写全数据,仅记录部分数据
该记录数据位记录操作过程
对所有操作进行记录,排除丢失数据的风险

AOF的概念

append only file 以独立日志的形式,每次只记录写命令,启动的时候,再重新执行rdb文件中命令,达到恢复数据的效果,与rdb相比可以简单描述成改记录数据为操作过程。

AOF主要解决了数据持久化的实时性。

aof写数据

aof写入缓存区,然后写入磁盘

aof写数据策略

always 每次 零数据误差,性能较低

everysec 每秒 每秒将缓冲区的指令同步到aof文件中,性能比较高,宕机会丢失1S的数据

no 系统控制 由操作系统每次同步到aof周期,整个过程不可控

AOF功能开启

配置

appendonly yes/no

appendsync always/everysec/no

aof写数据遇到的问题

随着命令不断写入aof,文件会越来越大,为了解决这个问题,redis引入了aof重写机制,压缩文件体积。aof重写是将redis进程内的数据转化为写命令同步到新aof文件的过程,简单来说,就是将对同一个数据的若干条命令执行结果,转换成最终结果数据对应的指令进行记录。

aof重写作用

降低磁盘占用率,提供磁盘利用率
提供持久化效率,降低持久化写时间,提供io性能
降低数据恢复时间,提供数据恢复效率

aof重写规则

忽略无效指令
进程已经超时的时候不再写入文件
对同一条的多条写的命令合并成为一条命令

AOF重写指令

bgrewriteaof 手动重写
auto-aof-rewrite-min-size size 64mb
auto-aof-rewrite-percentage percentage 基础尺寸百分比

AOF与RDB区别

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值