MeAlert的笔记网站

Appearance

redis ​

redis数据数据持久化 ​

image-20250412134834950

为什么要用数据持久化？

数据持久化可以在内存丢失或其他灾难性故障的情况下实现恢复。

数据持久化的两种方式

  1. AOF：以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写入指令从前到后执行一次以完成数据的恢复工作。
  2. RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照。

rdb（redis database） ​

能干嘛？

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里。Redis的数据都在内存中，保存备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，一锅端。

Rdb保存的是dump.rdb文件

image-20250412135541703

Redis6.0.16以下

image-20250412135626311

Redis6.2以及Redis-7.0.0

image-20250412135716317

自动触发 ​

  1. redis7版本，按照redis.conf里配置的save<seconds><changes>

image-20250412135904456

  1. 本案例5秒内2次修改

image-20250412140300483

  1. 修改dump文件保存路径

image-20250412140334001

image-20250412140539111

image-20250412143040215

image-20250412143204897

修改dump的默认文件名称

image-20250412143515348

触发备份情况

  1. image-20250412143957147
  2. image-20250412144015323

如何恢复？

  1. 将备份文件（dump6379.rdb）移动到redis安装目录并启动服务即可

  2. 备份成功后故意用flushdb清空redis，看看是否可以恢复数据

    image-20250412144353554

    1. 结论

      执行flushdb/flushall命令也会产生dump.rdb文件，但是里面是空的，无意义

  3. 物理恢复，一定服务和备份分级隔离

    image-20250412144525191不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了。

注意：

image-20250412145620989

执行quit命令就会写入dump文件，建议保存好数据，修改文件名或后缀名，或者备份文件，以免文件被覆盖

手动触发 ​

redis提供了两个命令来生成RDB文件，分别是save和bgsave

save（不推荐使用）：

在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，redis不能处理其他命令，线上禁止使用。

image-20250412160029456

image-20250412160456020

bgsave（默认）：

redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程

redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。

fork是什么？

在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，尽量避免膨胀。

image-20250412160045041

image-20250412160715667

lastsave：可以通过lastsave命令获取最后一次成功执行快照的时间

image-20250412160833207

优势 ​

image-20250412162222408

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

劣势 ​

image-20250412162355639

  1. 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
  2. 内存数据的全量同步，如果数据量太大会导致 I/O 严重影响服务器性能
  3. RDB 依赖于主进程的 fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑

数据丢失案例：

正常录入数据

image-20250412163907395

使用kill -9杀死进程

image-20250412163947557

重启服务后，查看数据是否丢失

image-20250412164019685

如何检测并修复dump.rdb文件 ​

image-20250412164706643

哪些情况会触发RDB快照 ​

  1. 配置文件中默认的快照配置
  2. 手动 save/bgsave 命令
  3. 执行 flushall/flushdb 命令也会产生 dump.rdb 文件，但这里面是空的，无意义
  4. 执行 shutdown 且没有设置开启 AOF 持久化
  5. 主从复制时，主节点自动触发

如何禁用快照 ​

  1. 动态所有停止 RDB 保存规则的方法：redis-cli config set save ""

  2. 快照禁用

    image-20250412165053214

RDB 优化配置项 ​

配置文件SNAPSHOTTING模块

save <seconds><changes>

dbfilename

dir

stop-writes-on-bgsave-error

image-20250412170306543

默认yes

如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，

也能确保redis继续接受新的写请求

rdbcompression

image-20250412170338012

默认yes

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。 如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

rdbchecksum

image-20250412170442335

默认yes

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

rdb-del-sync-files

image-20250412170506875

rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。

关闭RDB持久化 ​

image-20250413151754846

总结 ​

image-20250412170541034

AOF（Append Only File） ​

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

默认情况下，redis是没有开启AOF（append only file）的。开启AOF 功能需要设置配置：appendonly yes

AOF 保存的是appendonly.aof文件

AOF 持久化工作流程： ​

image-20250413140942560

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

AOF缓冲区三种写回策略 ​

  1. always

    同步写回，每个写命令执行完成立刻同步地将日志写回磁盘

  2. everysec

    每秒写回，每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘

  3. no：操作系统控制的写回，每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

三种写回策略总结：

配置项写回时机优点缺点
Always同步写回可靠性高，数据基本不丢失每个写命令都要落盘，性能影响较大
Everysec每秒写回性能适中宕机时丢失1秒内的数据
No操作系统控制的写回性能好宕机时丢失数据较多

AOF配置/启动/修复/恢复（redis6 vs redis7中的区别） ​

配置文件说明（6 vs 7）

  1. 如何开启 aof

    image-20250413142055377

  2. 使用默认写回方式，每秒钟

    image-20250413142350177

  3. aof文件-保存路径

    1. redis6

      aof 保存文件的位置和RDB保存文件的位置一样，都是通过 redis.conf 配置文件的dir配置

      image-20250413142506831

    2. redis7之后最新

      image-20250413143145004

      去除dumpfiles

      image-20250413143241436

    3. aof文件-保存名称

      1. redis6：有且仅有一个

      2. redis7：Multi Part AOF 的设计

        image-20250413143617617

        image-20250413143420437

        1. base 基本文件
        2. incr 增量文件
        3. manifest 清单文件

      3. redis7.0config 中对应的配置项

        image-20250413143519513

    正常恢复

    1. 启动：设置yes

      修改默认的appendonly no ，改为 yes

    2. 写操作继续，生成 aof 文件到指定的目录

    3. 恢复1：重启redis 然后重新加载，结果 ok

    4. 恢复2：

      1. 写入数据进redis，然后flushdb+shutdown服务器
      2. 新生成 dump和aof
      3. 备份新生成的 aof.bak，然后删除 dump/aof 再恢复
      4. 重启redis然后重新加载试试
      5. 停止服务器，拿出我们的备份修改后再重新启动服务器看看
正常恢复： ​

可以看到我们的rdb和aof都已经写入成功

image-20250413150409480

image-20250413152812181

当我们在添加一个数据，看看这个数据被记录到那个文件里面了！

我们先复制一份

image-20250413150618569

我们关闭redis服务器

image-20250413150853690

删除appendonlydir，因为我们模拟恢复，因为进行flushdb清空，然后shutdown关闭服务器的时候也会写入appendonlydir，所以我们要删除appendonlydir，因为这是个空文件

image-20250413151115020

修改appendonlydir.bak文件，改为apppendonlydir

image-20250413151219297

在启动redis服务器试试，看看有没有恢复

image-20250413151341369

异常恢复

  1. 故意乱写正常的 AOF 文件
  2. 模拟网络闪断写 error
  3. 重启 redis 之后就会进行 AOF 文件的载入，发现启动都不行
  4. 异常修复命令：redis-check-aof --fix进行修复
  5. 重启 ok
异常修复 ​

从上述可以看出我们的写入的数据会保存在，appendonly.aof.1.incr.aof中，如果我们在appendonly.aof.1.incr.aof里面乱加入一些东西，看看可以恢复吗？

image-20250413161250807

image-20250413161351896

我们把数据清空，在shutdown，然后重启redis-server

image-20250413161744835

我们使用redis-check-aof --fix 文件名进行修复

image-20250413161939967

我们启动redis-server看看， 有没有

image-20250413162918039

可以看到我们的redis修复成功了！

优势 ​

image-20250413164812270

更好的保护数据不丢失、性能高、可做紧急恢复

劣势 ​

image-20250413164920992

  1. 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
  2. aof运行效率要，慢于rdb，每秒同步策略效率较好，不同于效率和rdb相同

AOF重写机制 ​

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

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

一句话：启动 AOF文件的内容压缩，只保留可以恢复数据的最小指令集

**举个例子：**比如有个key

一开始你 set k1 v1

然后改成 set k1 v2

最后改成 set k1 v3

如果不重写，那么这3条语句都在aof文件中，内容占空间不说启动的时候都要执行一遍，共计3条命令；

但是，我们实际效果只需要set k1 v3这一条，所以，开启重写后，只需要保存set k1 v3就可以了只需要保留最后一次修改值，相当于给aof文件瘦身减肥，性能更好。AOF重写不仅降低了文件的占用空间，同时更小的AOF也可以更快地被Redis加载。

触发机制 ​

image-20250413165313170

注意 ，同时满足，且的关系才会触发

  1. 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
  2. 重写时满足的文件大小
自动触发 ​

满足配置文件中的选项后，redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64m时

示例：

  1. 修改最小重写大小，因为做实例，所以改的少一点

    image-20250413172308803

  2. 关闭 rdb和aof的混合模式

    image-20250413172712408

  3. 删除以前的aof和rdb，排除干扰项

    image-20250413172848044

  4. 数据压缩进行测试

    image-20250413173333430

  5. appendonly.aof.3.base.rdb文件，就是存放着我们最后一次对key写入的数据

手动触发 ​

客户端向服务器发送bgrewriteao命令

示例：

image-20250413173744340

结论 ​

image-20250413173835423

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

配置文件 append only mode 模块

image-20250413173933121

总结 ​

image-20250413173954069

RDB-AOF 混合持久化 ​

RDB和AOF可以同时共存，但是AOF的优先级高于RDB的优先级

image-20250413175315000

如何选？

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾

同时开启两种持久化方式

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

RDB的数据不实时，同时使用两者服务器重启也只会找 AOF 文件。那要不要只是用 AOF 呢？ 官网建议不要，因为 RDB 更适合用于备份数据（AOF在不断变化不好备份），留着 rdb 作为一个以防万一的手段。

推荐方式：

结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

  1. 开启混合方式设置

    设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用

  2. RDB+AOF的混合方式---------> 结论：RDB镜像做全量持久化，AOF做增量持久化

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

    image-20250413175941896

    纯缓存模式 ​

    同时关闭 RDB+AOF

    1. save ""
      1. 禁用 rdb
      2. 禁用 rdb 持久化模式下，我们仍然可以使用命令 save、bgsave 生成 rdb 文件
    2. appendonly no
      1. 禁用 aof
      2. 禁用 aof 持久化模式下，我们仍然可以使用命令 bgrewriteaof 生成 aof文件

Copyright © Albert MeAlert 2024