Redis持久化

Redis持久化

什么是持久化

众所周知Redis是跑在内存中的,当程序重启或者服务器崩溃时,数据就会丢失。如果业务需要重启后数据还在,那就需要持久化,把数据保存到磁盘中。

持久化方式

Redis有两种持久化方式:RDB和AOF

RDB

RDB(Redis Database Backup),记录Redis某个时刻的全部数据,本质就是数据快照,直接保存到磁盘中,后序通过加载RDB文件恢复数据。

image-20240821152154204

AOF

AOF(Append Only File),记录执行的每条写操作命令,重启之后通过重放命令来恢复数据,AOF本质是记录操作日志,后序通过日志重放恢复数据。

image-20240821152325301

RDB和AOF区别

RDB是快照恢复,AOF是日志恢复

  • 相同数据量下,RDB体积小,因为它记录的是二进制紧凑型数据
  • RDB是快照恢复,可以直接加载,恢复速度快;AOF是日志重放,恢复速度慢
  • AOF记录的是每条日志,RDB是间隔一段时间记录一次,所以AOF数据更完整

使用RDB还是使用AOF

还是根据使用场景:

1.如果本身只是作为一个缓存并且不是一个海量访问,就可以不使用持久化。

2.如果对数据很重视,可以同时开启RDB和AOF,但是这种情况RDB只是一个备份,实际恢复还是使用AOF(目的是开启AOF表明对数据的一致性要求高)。

image-20240821153530623

3.如果可以接受几分钟级别的数据丢失,建议只开启RDB。

保存镜像是数据库领域最有效的方法,所以RDB是Redis默认打开的。

image-20240821153741823

RDB为什么是几分钟持久化一次

因为是Redis主线程fork出一个子进程来做全量快照,如果一秒一次,会导致巨大的性能开销,可能上一秒的快照还没完成,下一秒又fork出一个子进程做快照。综上,RDB触发时间间隔一般是几分钟以上。

RDB详解

Redis默认配置:

save 900 1
save 300 10
save 60 10000

这里的语法是 save interval num,表示每隔interval秒,至少num条数据写操作,就会激活RDB持久化。(写操作指增加、删除、更新)

这三种条件是一个并集,满足其一就会进行持久化。这里的save当然是bgsave命令,如果是save命令,会时不时阻塞主线程。

RDB时机

1.主动执行save

2.主动执行bgsave

3.满足默认三个条件之一

4.程序正常关闭时:在关闭时,Redis会启动一次阻塞式持久化,以记录更全的数据

RDB的流程

1.Fork出一个子进程专门做持久化

2.子进程写到临时的RDB文件

3.新的RDB文件替代旧的RDB文件

image-20240821154843110

RDB的写时拷贝

其实RDB过程中,Redis是继续处理操作命令的,也就是数据是能被修改的。

fork创建出子进程之后,会复制父进程的页表,此时两个页表指向的是同一块物理内存。

当父进程出现新的数据后,物理内存才会被复制一份。

主进程和子进程

Redis使用bgsave对内存的数据做快照,这个操作是由bgsave子进程在后台完成的,执行时不会阻塞父进程的主线程,使的主线程还可以继续修改数据。这目的就是减少创建子进程时的消耗,加快创建子进程的速度,毕竟子进程创建时是可能阻塞主线程的。

由于写时拷贝,只有发生写操作,主进程才会复制一份内存,在这个内存上进行修改数据,子进程一直持久化的是之前的数据。

AOF详解

打开AOF

redis.conf文件中:

appendonly no

appendfilename "appendonly.aof"

将appendonly设置为yes,即可打开AOF。

AOF的流程

核心流程分为:1.请求到来 2.处理请求 3.写入AOF文件

由于每条操作都会记录进AOF,所以有可能会影响Redis的执行性能。

于是,Redis通过提供3种刷盘策略减小影响:

1.appendfsync always:每次请求都刷入AOF,非常慢,但是数据非常安全

2.appendfsync everysec:每秒刷盘一次,速度足够快,在崩溃场景下会损失1秒的数据

3.appendfsync no:从不主动刷盘,让操作系统刷盘,一般Linux30秒刷盘一次,在崩溃场景下损失30秒的数据

三种方案选择也是根据业务场景:一般都是2和3,比如简单的缓存,使用方案3,追求高性能;大部分场景都可以使用方案2

AOF写入示意图

image-20240821160818759

AOF重写

AOF一直写下去会造成aof文件体积庞大的问题。

Redis针对AOF文件体积过大时,会自动在后台fork一个子进程,对AOF进行重写。也就是针对相同的key,进行合并,比如相同key的set操作,后面的set操作覆盖前面的set操作。

但是重写过程中,新插入的数据呢?

所以在重写的过程中,Redis把新的操作记录在原来的AOF缓冲区,还记录在AOF重写缓冲区。等新的AOF文件创建完毕,Redis把重写缓冲区中的数据,追加到新的AOF文件中,再用新的AOF文件替换旧的AOF文件。

image-20240821161412866

一般这个体积过大,体积指的是配置文件中的:

#比上次重写时数据增长100%
auto-aof-rewrite-percent 100
#超过
auto-aof-rewrite-min-size 64mb

超过64M时,比上次重写的数据大一倍,则进行重写。

AOF优化-混合持久化

混合持久化并不是同时开启RDB和AOF,是实际发生AOF重写时,将当前的状态存为RDB二进制内容,写入新的AOF文件,再把重写缓冲区中的AOF文件,替代原有的AOF文件。

其实混合持久化的本质还是AOF,是一种对AOF的优化。

开启混合持久化

redis.conf:

aof-use-preamble

Redis5.0版本之后是默认开启的,只有5.0版本后打开AOF,默认就是混合持久化。

如何区别是否开启混合持久化:在AOF文件中找以“REDIS”为文件名开头的文件即可。

  • 7
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值