Redis持久化详解

持久化:

什么是持久化?

利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制称为持久化 。作用就是持久化用于防止数据的意外丢失,确保数据安全性

持久化过程保存的内容?

  • RDB:将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据
  • AOF:将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程

RDB:

save指令:

手动执行一次保存操作

#  要先设置dbfilename,然后设置一个名字set name itzhuzhu 然后执行save   就可以在dbfilename路径里看到保存的文件
save

设置本地数据库文件名,默认值为 dump.rdb,通常设置为dump-端口号.rdb
下面的操作都是:cd redis/conf/redis-6379.conf文件的

# dbfilename filename
dbfilename "dump-6379,rdb"

设置存储.rdb文件的路径,通常设置成存储空间较大的目录中,目录名称data

dir path

设置存储至本地数据库时是否压缩数据,默认yes,设置为no,节省 CPU 运行时间,但存储文件变大

rdbcompression yes|no

设置读写文件过程是否进行RDB格式校验,默认yes,设置为no,节约读写10%时间消耗,单存在数据损坏的风险

rdbchecksum yes|no

save指令工作原理

redis是个单线程的工作模式,它会创建一个任务队列,所有的命令都会进到这个队列里边,在这儿排队执行,执行完一个消失一个,当所有的命令都执行完了,多个客户端同时执行的话redis执行,如果数据量很大他会非常耗时,以至于影响到它在执行的时候,后面的指令都要等,所以说这种模式是不友好的,这是save指令对应的一个问题,当cpu执行的时候会阻塞redis服务器,直到他执行完毕,所以说我们不建议大家在线上环境用save指令,可以使用bgsave

bgsave指令:

bgsave指令,bg其实是background的意思,后台执行的意思

手动启动后台保存操作,但不是立即执行

bgsave

后台存储过程中如果出现错误现象,是否停止保存操作,默认yes

stop-writes-on-bgsave-error yes|no

其他

dbfilename filename  
dir path  
rdbcompression yes|no  
rdbchecksum yes|no

bgsave指令工作原理:

当执行bgsave的时候,客户端发出bgsave指令给到redis服务器。这个时候服务器马上回一个结果告诉客户端后台已经开始了,与此同时它会创建一个子进程,使用Linux的fork函数创建一个子进程,让这个子进程去执行save相关的操作,此时我们可以想一下,我们主进程一直在处理指令,而子进程在执行后台的保存,是不会干扰到主进程的执行的,子进程开始执行之后,它就会创建啊RDB文件把它存起来,操作完以后他会把这个结果返回,也就是说bgsave的过程分成两个过程,第一个是服务端拿到指令直接告诉客户端开始执行了;另外一个过程是一个子进程在完成后台的保存操作,操作完以后回一个消息。

save配置自动执行:

设置自动持久化的条件,满足限定时间范围内key的变化数量达到指定数量即进行持久化

save second changes

参数:

  • second:监控时间范围
  • changes:监控key的变化量

范例:

# 900秒内有1个key发生变化就会去保存
save 900 1
# 300秒内有10个key发生变化就会去保存
save 300 10
# 60秒内有10000个key发生变化就会去保存
save 60 10000

其他相关配置:

dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
stop-writes-on-bgsave-error yes|no

save配置工作原理

自动的save启动后还是执行的bgsave,只不过是手动挡换自动了,当执自动化save执行的时候,客户端发出指令给到redis服务器,然后返回结果给客户端,这里会产生一个判断

  1. 判断指令会不会对数据产生影响,比如get,你get了一下肯定不鸟你的,对数据本身不会造成影响的。
  2. 有没有没有真正产生了影响,比如set了一个不存在的name。
  3. 进行操作的时候不会进行数据比对,比如set name五次,不管有没有产生影响,只要执行成功就记录

以上三个条件都满足,才会记录影响的数量+1,而且save配置拼频度过高或低都会出现性能问题

RDB三种启动方式对比:
方式 save指令 bgsave指令
读写 同步 异步
阻塞客户端指令
额外内存消耗
启动新进程

对比结果:bgsave获胜,工作都要用它

RDB特殊启动形式

服务器运行过程中重启(热启动)

debug reload

关闭服务器时指定保存数据

shutdown save

RDB优点:

  • RDB是一个紧凑压缩的二进制文件,存储效率较高
  • RDB内部存储的是redis在某个时间点的数据快照,非常适合用于数据备份,全量复制等场景
  • RDB恢复数据的速度要比AOF快很多
  • 应用:服务器中每X小时执行bgsave备份,并将RDB文件拷贝到远程机器中,用于灾难恢复。

RDB缺点

  • RDB方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据
  • bgsave指令每次运行要执行fork操作创建子进程,要牺牲掉一些性能
  • Redis的众多版本中未进行RDB文件格式的版本统一,有可能出现各版本服务之间数据格式无法兼容现象

AOF:

为什么要有AOF,这得从RDB的存储的弊端说起:

  • 存储数据量较大,效率较低,基于快照思想,每次读写都是全部数据,当数据量巨大时,效率非常低
  • 大数据量下的IO性能较低
  • 基于fork创建子进程,内存产生额外消耗
  • 宕机带来的数据丢失风险

那解决的思路是什么呢?

  • 不写全数据,仅记录部分数据
  • 降低区分数据是否改变的难度,改记录数据为记录操作过程
  • 对所有操作均进行记录,排除丢失数据的风险
AOF概念:
  • AOF(append only file)持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
  • AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式

AOF写数据过程:

  • 操作一条指令以后,客户端发送给redis
  • redis会把这个指令放到刷新缓存区
  • 缓存区可以放很多指令,等到一定的规模,指令多了它才会把所有命令放到aof文件里,这样可以优化写的速度。
AOF执行策略:

AOF写数据三种策略(appendfsync)

  • alway(每次):每次写入操作均同步到AOF文件中数据零误差,性能较低,不建议使用。

  • everysec(每秒):每秒将缓冲区中的指令同步到AOF文件中,在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高,性能较高,建议使用,也是默认配置

  • no(系统控制):由操作系统控制每次同步到AOF文件的周期,整体过程不可控

启动AOF相关配置:

开启AOF持久化功能,默认no,即不开启状态

# appendonly yes|no
appendonly yes

AOF持久化文件名,默认文件名为appendonly.aof,建议配置为appendonly-端口号.aof

# appendfilename filename
appendfilename "appendonly-6379.aof"

AOF持久化文件保存路径,与RDB持久化文件保持一致即可

# dir 文件路径
dir /redis/data

AOF写数据策略,默认为everysec

# appendfsync always|everysec|no
appendfsync everysec

aof文件解析,对数据有影响的操作才会记录

一个*到下一个*之间是一条指令

[root@VM-0-9-centos data]# cat appendonly-6379.aof 
*2  
$6  
SELECT
$1
0
*3     一共分3段
$3    第一段有3个长度
set
$4   第二段4个长度
name
$8     第三段8个长度
itzhuzhu
AOF重写:

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

Redis持久化详解_第1张图片

AOF重写作用

  • 降低磁盘占用量,提高磁盘利用率
  • 提高持久化效率,降低持久化写时间,提高IO性能
  • 降低数据恢复用时,提高数据恢复效率

AOF重写规则

  • 进程内具有时效性的数据,并且数据已超时将不再写入文件

  • 非写入类的无效指令将被忽略,只保留最终数据的写入命令

    • 如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
    • 如select指令虽然不更改数据,但是更改了数据的存储位置,此类命令同样需要记录
  • 对同一数据的多条写命令合并为一条命令:

    • 如lpushlist1 a、lpush list1 b、lpush list1 c可以转化为:lpush list1 a b c
    • 为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令最多写入64个元素

手动重写

bgrewriteaof

执行bgrewriteaof前后对:

-rw-r--r-- 1 root root 0 323 12:19 appendonly-6379.aof
[root@VM-0-9-centos data]# cat appendonly-6379.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$8
itzhuzhu
*3
$3
set
$4
name
$9
itzhuzhu2
*3
$3
set
$4
name
$9
itzhuzhu3
*3
$3
set
$4
name
$9
itzhuzhu4
[root@VM-0-9-centos data]# cat appendonly-6379.aof 
REDIS0009�      redis-ver6.0.10�
�edis-bits�@�ctime��lY`used-mem¸4
 aof-preamble���name    itzhuzhu4�䫃'/��[root@VM-0-9-centos data]# 

自动重写

自动重写触发条件设置

# auto-aof-rewrite-min-size size
# auto-aof-rewrite-percentage percent

auto-aof-rewrite-min-size 4MB  这个写大小
auto-aof-rewrite-percentage 10%  这个写百分比

自动重写触发比对参数( 运行指令info Persistence获取具体信息 )

aof_current_size  
aof_base_size

自动重写触发条件公式:

Redis持久化详解_第2张图片

AOF工作流程及重写流程:

Redis持久化详解_第3张图片

RDB与AOF区别:

持久化方式 RDB AOF
占用存储空间 小(数据级:压缩) 大(指令级:重写)
存储速度
恢复速度
数据安全性 会丢失数据 依据策略决定
资源消耗 高/重量级 低/轻量级
启动优先级
RDB与AOF应用场景

对数据非常敏感,建议使用默认的AOF持久化方案

  • AOF持久化策略使用everysecond,每秒钟fsync一次。该策略redis仍可以保持很好的处理性能,当出现问题时,最多丢失0-1秒内的数据。
  • AOF文件存储体积较大,且恢复速度较慢

数据呈现阶段有效性,建议使用RDB持久化方案

  • 数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的),且恢复速度较快,阶段 点数据恢复通常采用RDB方案
  • 利用RDB实现紧凑的数据持久化会使Redis降的很低

综合比对

  • RDB与AOF的选择实际上是在做一种权衡,每种都有利有弊
  • 如不能承受数分钟以内的数据丢失,对业务数据非常敏感,选用AOF
  • 如能承受数分钟以内的数据丢失,且追求大数据集的恢复速度,选用RDB
  • 灾难恢复选用RDB
  • 双保险策略,同时开启 RDB和 AOF,重启后,Redis优先使用 AOF 来恢复数据,降低丢失数据的量

你可能感兴趣的:(Redis,redis,Redis持久化,RDB,AOF)