首页 > 数据库 >Redis7(二)Redis持久化双雄

Redis7(二)Redis持久化双雄

时间:2024-07-20 20:27:37浏览次数:15  
标签:AOF 快照 文件 redis Redis7 Redis 化双雄 RDB 重写

持久化之RDB

RDB的持久化方式是在指定时间间隔,执行数据集的时间点快照。也就是在指定的时间间隔将内存中的数据集快照写入磁盘,也就是Snapshot内存快照,它恢复时再将硬盘快照文件直接读回到内存里面。

RDB保存的是dump.rdb文件。

自动触发

默认redis是有三种自动触发的规则,在配置文件中也有注释:

分别是一个小时内有一次变化,五分钟内有100次变化,一分钟内有10000次变化。如果要配置自己的规则,可以在配置文件中写一下语法:

save (time) (changes)

time指的是在多少时间内,单位是秒。

changes指的是变化次数,单位是次。

也可以在一行配置多个规则:

save (time) (changes) (time) (changes) (time) (changes)……

只要redis数据库中存在一定的变化满足了规则,就会进行一次快照

手动触发

手动触发分为两个指令:SAVEBGSAVE

只要执行了这两个指令,就会进行一次快照。

至于这两指令有和区别呢:

SAVE:使用SAVE的时候,在保存快照文件期间,当前redis服务器会被阻塞,将不能正常进行缓存,因为会影响redis的功能的使用,所以通常这个指令不被推荐使用。

BGSAVE:使用BGSAVE的时候,redis会fork出一个子进程来进行持久化,原来的主线程不会被影响,通常推荐使用这个指令

如果要想查看上一次快照的时间,可以使用LASTSAVE指令,步骤按如下:

RDB的优点和缺点

优点:

  1. 适合大规模的数据恢复
  2. 按时业务定时备份
  3. 对数据完整性和一致性要求不高
  4. RDB文件在内存中的加载速度要比AOF快得多

缺点:

  1. 如果Redis意外地down了,就会丢失从当前到最近一次的快照期间的数据,会导致快照文件的丢失
  2. 内存数据的全量同步,如果数据量太大,会导致IO严重影响服务器性能
  3. RDB依赖于主进程的fork,在更大的数据集中,可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份,导致两倍的膨胀率

检查修复RDB文件的命令:redis-check-rdb (rdb文件的路径)

快照执行的情况:

  1. 配置文件中默认的快照规则
  2. 手动执行SAVE和BGSAVE命令
  3. 执行了flushall和flushdb命令,但是产生的快照文件是空的
  4. 执行shutdown且没有开启使用AOF
  5. 主从复制时,主节点自动触发

如何禁用快照:动态停止所有RDB保存规则的方法:redis-cli config set save “”

或者在配置文件中写一个 save “”

RDB优化配置项

在配置文件中:

  1. stop-write-on-bgsave-error:默认是yes,如果配置成no,表示不在乎数据不一致或者有其他的手段发现和控制这种不一致,那么在快照写入失败时,也能确保redis继续接收新的写请求。建议使用yes
  2. rdbcompression:默认yes,对于存储到磁盘中的快照,可以设置是否进行压缩存储,如果是的话,redis会采用LZF算法进行压缩。如果不想消耗CPU来进行压缩的话,可以设置关闭次功能。建议使用yes
  3. rdbchecksum:在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增大约10%的性能消耗,如果希望获取到最大的性能提示,可以关闭此功能。建议使用yes
  4. rdb-del-sync-files:在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下是no,此选项是禁用的

持久化之AOF

AOF(append only file)是以日志的形式来记录每个写操作,将Redis执行过的所有写的指令记录下来(读操作不记录),只许追加文件但是不可以更改文件,redis启动后会读取改文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

默认情况下,redis并没有开启AOF的开启AOF的功能需要设置配置文件中的appendonly为yes

AOF保存的是appendonly.aof文件

AOF工作流程

  1. Client作为命令的来源,会有多个源头以及源源不断的请求命令
  2. 在这些命令到达Redis Server后并不是直接写入AOF文件,会将这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域,存在的目的是当这些命令达到一定量以后再写入磁盘,避免频繁地磁盘IO操作
  3. AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件
  4. 随着写入AOF的内容的增加,为避免文件膨胀,会根据对着进行命令的合并(又称AOF的重写),从而起到AOF文件压缩的目的
  5. 当Redis Server服务器重启的时候会从AOF文件中载入数据

写回策略,可在配置文件中进行配置appendfsync,有以下三种:

  1. everysec:redis默认为这种方式,每秒写回,每个写命令执行完后,只是把日志写到AOF的内存缓冲区,没隔一秒把缓冲区中的内容写入磁盘
  2. always:同步写回,每个命令执行完后立即同步地将日志写回磁盘(性能影响大)
  3. no:由操作系统控制的写回,每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区写回磁盘(容易丢失数据)

在Redis6中,AOF文件分为三种类型:

base:标识基础AOF,一般由子进程通过重写产生,该文件最多只有一个

incr:表示增量AOF,一般会在AOFRW开始执行是被创建,该文件可能存在多个。

history:表示历史AOF,由BASE和INCR变化而来,每次AOFRW成功完成时,本次AOFRW之前对应的base和incr都将变成history,history类型的AOF会被Redis自动删除

为了管理这些AOF文件,引入了一个manifest文件来跟踪、管理这些AOF。同时,为了便于AOF备份和拷贝,我们将所有的AOF文件和mainfest文件放入一个单据的文件目录,目录名由appenddirname配置决定

AOF文件修复命令:redis-check-aof --fix (文件名)

AOF优缺点

优点:

  1. 使用AOF后Redis更加持久,使用每秒读入的方式是当出现异常时,只会出现一秒的数据丢失
  2. AOF日志是一个仅附加日志,不会出现寻道问题,不会因为断电出现损坏,如果因为一些原因出现写到一半结尾了,可以使用redis-check-aof工具来修复文件
  3. 当AOF变得太大时,可以在后台自动重写AOF。
  4. 格式易于理解和解析,易于恢复数据。

缺点:

  1. AOF文件通常比相同数据集的等效RDB文件大
  2. AOF运行效率要慢于rdb(everysec时)

AOF重写机制

由于AOF持久化是Redis不断将写命令记录到AOF文件中,随着Redis不断地进行,AOF文件会越来越大。文件越大,占用服务器内存越大以及AOF恢复要求时间越长。

为了解决这个问题,Redis新增了重写机制,当AOF文件的大小超过所设定的峰值时,Redis就会自动启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集

自动触发是默认为根据上次重写的AOF大小增长了一倍并且文件大小有64mb时自动进行重写

或者可以手动使用命令bgrewriteaof来重写

最小指令集的案例:

set k1 v2

set k1 v3

set k1 v4

最终只保留set k1 v4

重写原理

  1. 在重写开始前,redis会创建一个”重写子进程“,这个子进程会读取现有的AOF文件,并将其包含的指令进行分析压缩并写入到一个临时文件中。
  2. 与此同时,主进程会将新接收到的指令一边累积到内存缓冲区中,一边继续写入到原有的AOF文件中,这样做是保证原有的AOF文件的可用性,避免在重写过程中出现意外。
  3. 当”重写子进程“完成重写工作后,会给父进程发一个信号,父进程收到信号后就会将内存中的缓存的写指令追加到新的AOF中
  4. 当追加结束后,redis就会用新的AOF文件来代替旧的AOF文件,之后再有新的写指令,就都会追加到新的AOF文件中
  5. 重写AOF文件的操作,并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件,和快照有点类似

RDB+AOF混合持久化

如果同时开启RDB和AOF,重启时只会加载AOF文件,不会加载RDB文件,如果没有AOF就会加载RDB文件

当redis重启时,会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整

RDB的数据不实时,同时使用两者时服务器重启只会找AOF,但是也建议不要只使用AOF,因为AOF在不断变化不好备份,RDB更适合用于备份数据库,留着RDB作为一个万一的手段

开启混合方式设置:设置aof-use-rdb-preamble的值为yes

混合持久化之后,RDB镜像做全量持久化,AOF做增量持久化

先使用RDB进行快照存储,然后使用AOF持久化所有的写操作,当重写策略满足或者手写触发重写的时候,将最新的数据存储为新的RDB记录。这样的话,重启服务的时候会从RDB和AOF两个部分恢复数据,又提高了恢复数据的性能。简单来说:混合持久化方式产生的文件一部分是RDB格式,一部分是AOF格式

纯缓存模式

同时关闭RDB和AOF,Redis只做缓存功能。

在这种情况下,依然可以使用手动触发的方式使用AOF和RDB

标签:AOF,快照,文件,redis,Redis7,Redis,化双雄,RDB,重写
From: https://blog.csdn.net/2302_79468488/article/details/140576629

相关文章

  • Redis主从配置
    转载请注明出处:Redis主从配置的特点数据同步:主库(Master)负责处理写请求,并将数据更改同步到从库(Slave)。从库主要用于读请求和数据备份。读写分离:通过配置从库为只读,可以有效分散读请求,提升系统性能。高可用性和容错:即使主库出现故障,从库也能继续提供读服务,并在主库恢复后重新同......
  • 实现分布式锁,Zookeeper 与 Redis 哪个更好一点?
    1.为什么使用分布式锁?分布式锁有什么用途?(1)使用分布式锁的目的使用分布式锁的目的很简单,就是为了保证在同一时间里面,只有一个JVM进程可以实现对于共享资源的操作。确保数据的一致性在分布式环境中,多个节点可能会同时访问和修改同一数据或资源。分布式锁可以确保在任......
  • redis缓存雪崩,击穿,穿透,到底是什么?
    Redis缓存雪崩、击穿、穿透是缓存机制中常见的问题,这些问题都可能对系统的性能和稳定性产生严重影响。缓存雪崩是指当缓存层承载大量请求并有效保护存储层时,如果缓存层由于某些原因无法提供服务(如缓存数据大面积失效),导致所有请求都直接到达存储层,进而造成存储层请求量急剧增加......
  • 宝塔面板下,如果redis服务意外停止,如何定时检测并恢复服务
    redis突然停止的原因有多种:1、内存不足,如果Redis使用的内存超过了服务器可用内存,操作系统会自动杀死Redis进程。2、服务器的资源限制(ulimit)比较低,Redis可能会因为无法打开足够的文件描述符而停止。3、其他一些要根据redis日志排查如果停止后,还可以手工正常启用redis,那可以考虑把sh......
  • Redis在CentoOS上安装
    一、下载https://download.redis.io/releases/ (版本为6.2.6)二、解压mkdir/usr/local/redistar-zxvfredis-6.2.6.tar.gz-C/usr/local/redis三、编译1、检查是否安装了gcc依赖(若已经安装,无需再次安装)gcc-v2、若没有安装gcc依赖,需要安装gcc依赖yuminstall-......
  • 深入Redis集群部署:从安装配置到测试验证的完整指南
      ......
  • 使用Java和Redis实现分布式缓存系统
    使用Java和Redis实现分布式缓存系统大家好,我是微赚淘客系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿!今天我们来探讨如何使用Java和Redis实现一个高效的分布式缓存系统。Redis是一个开源的内存数据结构存储系统,广泛用于缓存和分布式数据库中。在本文中,我们将展示如何使用Ja......
  • Redis
    首先我们先了解nosql是什么nosql[notonlysql]不仅仅是sql。所有非关系型数据库的统称。除去关系型数据库之外的都是非关系数据库。(之前我们所了解的MySql ”RDBMS“ 是关系型数据库  )然后我们再区分一下NOSQL和RDBMS的区别RDBMS--关系型数据库得到通称-高度组织......
  • Redis系列命令更新--Redis字符串命令
    1、RedisSET命令 (1)说明:用于设置给定key的值;如果key已经存储其他值,SET就覆写旧值,且无视类型;(2)语法:redis127.0.0.1:6379>SETKEY_NAMEVALUE(3)实例:#对不存在的键进行设置redis127.0.0.1:6379>SETkey"value"OKredis127.0.0.1:6379>GETkey"value"#对已存在的键......
  • Redis设计思路总结
    本文从网络模型、数据结构和内存管理、持久化和多机协作四个角度对redis的设计思路进行分析。一.网络模型Redis是典型的基于Reactor的事件驱动模型,单进程单线程,高效的框架总是类似的。网络模型与spp的异步模型几乎一致。Redis流程上整体分为接受请求处理器、响应处理器和应答处......