redis持久化

一、redis的持久化

redis是基于内存可持久化存储键值数据的非关系型数据库
数据在内存中的数据会丢失,所以我们要把内存中的数据写到磁盘中
这就是redis持久化要做的事情

Redis官方提供了两种不同的持久化方法来将内存的数据存储到硬盘里面分别是

  • RDB持久化,快照(Snapshot)【默认】
  • AOF (Append Only File) 只追加日志文件【默认不开启】

1、RDB持久化、快照

这种方式可以将某一时刻的所有数据都写入硬盘中,当然这也是redis的默认开启持久化方式,保存的文件是以.rdb形式结尾的文件因此这种方式也称之为RDB方式。

默认情况下,redis服务在哪个目录下启动,哪个目录就是工作目录,后面的rdb持久化或者AOF持久化,产生的文件都存在于redis的当前工作目录下。在哪里启动就会读取哪里的快照文件

客户端执行bgsave命令

bgsave

当接收到客户端的BGSAVE命令时,redis会调用fork¹来创建一个子进程,然后子进程负责将快照写入磁盘中,而父进程则继续处理命令请求

客户端执行save命令

SAVE命令并不常用,使用SAVE命令在快照创建完毕之前,redis处于阻塞状态,无法对外服务**

配置redis.conf文件实现自动触发

如果用户在redis.conf中设置了save配置选项,redis会在save选项条件满足之后自动触发一次BGSAVE命令,如果设置多个save配置选项,当任意一个save配置选项条件满足,redis也会触发一次BGSAVE命令

这种方式并不太好,再写快照的时候如果又来了大量的用户请求,这时候断电了会造成数据丢失

2、AOF只追加日志文件

1、特点

  • 这种方式可以将所有客户端执行的写命令记录到日志文件中AOF持久化会将被执行的写命令写到AOF的文件末尾,以此来记录数据发生的变化,因此只要redis从头到尾执行一次AOF文件所包含的所有写命令,就可以恢复AOF文件的记录的数据集

2、开启AOF持久化

  • 在redis的默认配置中AOF持久化机制是没有开启的,需要在配置文件中开启

3、日志追加频率
1.always 【谨慎使用】

  • 说明: 每个redis写命令都要同步写入硬盘,严重降低redis速度
  • 解释: 如果用户使用了always选项,那么每个redis写命令都会被写入硬盘,从而将发生系统崩溃时出现的数据丢失减到最少;遗憾的是,因为这种同步策略需要对硬盘进行大量的写入操作,所以redis处理命令的速度会受到硬盘性能的限制;
  • 注意: 转盘式硬盘在这种频率下200左右个命令/s ; 固态硬盘(SSD) 几百万个命令/s;
  • 警告: 使用SSD用户请谨慎使用always选项,这种模式不断写入少量数据的做法有可能会引发严重的写入放大问题,导致将固态硬盘的寿命从原来的几年降低为几个月。

2.everysec 【推荐默认】

  • 说明: 每秒执行一次同步显式的将多个写命令同步到磁盘
  • 解释: 为了兼顾数据安全和写入性能,用户可以考虑使用everysec选项,让redis每秒一次的频率对AOF文件进行同步;redis每秒同步一次AOF文件时性能和不使用任何持久化特性时的性能相差无几,而通过每秒同步一次AOF文件,redis可以保证,即使系统崩溃,用户最多丢失一秒之内产生的数据。

3.no 【不推荐】

  • 说明: 由操作系统决定何时同步
  • 解释:最后使用no选项,将完全由操作系统决定什么时候同步AOF日志文件,这个选项不会对redis性能带来影响但是系统崩溃时,会丢失不定数量的数据,甚至丢失全部数据,另外如果用户硬盘处理写入操作不够快的话,当缓冲区被等待写入硬盘数据填满时,redis会处于阻塞状态,并导致redis的处理命令请求的速度变慢。

4、修改同步频率

AOF文件的重写

使用AOF的也放也会带来问题,持久化文件会越来越大。例如,我们写了100条 set name wangliangliang其中99条是多余的,因为要恢复数据库中的文件只需要一条set name wangliangliang就可以了。为了压缩AOF持久化文件redis提供了AOF(ReWrite)机制

作用

一定程度上减小AOF文件的体积,加快启动速度,还能保证数据不丢失

触发方式

  • 客户端方式触发重写

BGREWRITEAOF

  • 服务器配置方式自动触发
  • 配置redis.conf中的auto-aof-rewrite-percentage选项
  • 如果设置auto-aof-rewrite-percentage值为100和auto-aof-rewrite-min-size 64mb,并且启用的AOF持久化时,那么当AOF文件体积大于64mb,并且AOF文件的体积比上一次重写之后体积大了至少一倍(100%)时,会自动触发,如果重写过于频繁,用户可以考虑将auto-aof-rewrite-percentage设置为更大

重写原理

从 Redis 7.0.0 开始,在调度 AOF 重写时,Redis 父进程会打开一个新的增量 AOF 文件继续写入。子进程执行重写逻辑并生成新的基础 AOF。Redis 将使用一个临时清单文件来跟踪新生成的基础文件和增量文件。当它们准备好后,Redis 会执行原子替换操作,使这个临时清单文件生效。为了避免在 AOF 重写重复失败和重试的情况下创建大量增量文件的问题,Redis 引入了 AOF 重写限制机制,以确保失败的 AOF 重写以越来越慢的速度重试。

重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,替换原有的文件这点和快照有点类似

重写流程

    1. redis调用fork ,现在有父子两个进程 子进程根据内存中的数据库快照,往临时文件中写入重建数据库状态的命令
    1. 父进程继续处理client请求,除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
    1. 当子进程把快照内容写入已命令方式写到临时文件中后,子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
    1. 现在父进程可以使用临时文件替换老的aof文件,并重命名,后面收到的写命令也开始往新的aof文件中追加。

redis7.0.0之前

redis7.0.0之后

posted @   w我自横刀向天笑  阅读(106)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· winform 绘制太阳,地球,月球 运作规律
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· AI与.NET技术实操系列(五):向量存储与相似性搜索在 .NET 中的实现
· 超详细:普通电脑也行Windows部署deepseek R1训练数据并当服务器共享给他人
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理
点击右上角即可分享
微信分享提示