目录
持久化
利用永久性存储介质将数据进行保存,在特定的时候将保存的数据进行恢复的工作机制称为持久化。
持久化过程中保存的什么
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 基础尺寸百分比