自学内容网 自学内容网

Redis的三种持久化方法详解

Redis持久化机制详解 | JavaGuide

Redis 不同于 Memcached 的很重要一点就是,Redis 支持持久化,而且支持 3 种持久化方式:

  • 快照(snapshotting,RDB)
  • 只追加文件(append-only file, AOF)
  • RDB 和 AOF 的混合持久化(Redis 4.0 新增)

BRD持久化

快照持久化是 Redis 默认采用的持久化方式,在 redis.conf 配置文件中默认有此下配置:

save 900 1           #在900秒(15分钟)之后,如果至少有1个key发生变化,Redis就会自动触发bgsave命令创建快照。

save 300 10          #在300秒(5分钟)之后,如果至少有10个key发生变化,Redis就会自动触发bgsave命令创建快照。

save 60 10000        #在60秒(1分钟)之后,如果至少有10000个key发生变化,Redis就会自动触发bgsave命令创建快照。

RDB 创建快照时会阻塞主线程吗?

Redis 提供了两个命令来生成 RDB 快照文件:

  • save : 同步保存操作,会阻塞 Redis 主线程;
  • bgsave : fork 出一个子进程,子进程执行,不会阻塞 Redis 主线程,默认选项。

这里说 Redis 主线程而不是主进程的主要是因为 Redis 启动之后主要是通过单线程的方式完成主要的工作。如果你想将其描述为 Redis 主进程,也没毛病。

AOF持久化

aof的实时性更好, 开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令,Redis 就会将该命令写入到 AOF 缓冲区 server.aof_buf 中,然后再写入到 AOF 文件中(此时还在系统内核缓存区未同步到磁盘),最后再根据持久化方式( fsync策略)的配置来决定何时将系统内核缓存区的数据同步到硬盘中的。

只有同步到磁盘中才算持久化保存了,否则依然存在数据丢失的风险,比如说:系统内核缓存区的数据还未同步,磁盘机器就宕机了,那这部分数据就算丢失了。

AOF 文件的保存位置和 RDB 文件的位置相同,都是通过 dir 参数设置的,默认的文件名是 appendonly.aof

AOF的工作流程:

  • write:写入系统内核缓冲区之后直接返回(仅仅是写到缓冲区),不会立即同步到硬盘。虽然提高了效率,但也带来了数据丢失的风险。同步硬盘操作通常依赖于系统调度机制,Linux 内核通常为 30s 同步一次,具体值取决于写出的数据量和 I/O 缓冲区的状态。
  • fsyncfsync用于强制刷新系统内核缓冲区(同步到到磁盘),确保写磁盘操作结束才会返回。

AOF的三种同步策略:

  • 如果是 appendfsync always: 每个命令后立即写入
  • 如果是 appendfsync everysec: 每秒写入一次
  • 如果是 appendfsync no: 由操作系统决定何时写入

AOF 为什么是在执行完命令之后记录日志?

  • 避免额外的检查开销,AOF 记录日志不会对命令进行语法检查;
  • 在命令执行完之后再记录,不会阻塞当前的命令执行。

这样也带来了风险(我在前面介绍 AOF 持久化的时候也提到过):

  • 如果刚执行完命令 Redis 就宕机会导致对应的修改丢失;
  • 可能会阻塞后续其他命令的执行(AOF 记录日志是在 Redis 主线程中进行的)。

AOF 重写了解吗?

AOF重写流程: 流程图

  1. 触发重写:
  • Redis可以根据配置自动触发重写(例如,当AOF文件大小超过上一次重写后的一定百分比)
  • 或者通过手动执行BGREWRITEAOF命令触发
  1. 创建子进程:
  • Redis主进程创建一个子进程来执行重写操作
  • 这允许主进程继续服务客户端请求
  1. 创建数据快照:
  • 子进程创建当前数据集的内存快照
  1. 重写AOF文件:
  • 子进程遍历数据快照,生成重建当前数据集所需的最小命令集
  • 这些命令被写入一个新的AOF文件
  1. 累积新写入:
  • 在重写过程中,主进程继续处理写命令
  • 这些新命令被写入旧的AOF文件,同时被存储在一个重写缓冲区中
  1. 同步新写入:
  • 当子进程完成重写后,它通知主进程
  • 主进程将重写缓冲区中的内容追加到新AOF文件末尾
  1. 切换文件:
  • Redis执行一个原子性的替换操作,用新的AOF文件替换旧文件
  1. 完成重写:
  • 重写过程完成,Redis继续使用新的AOF文件进行持久化

AOF重写的好处:

  1. 减小文件大小: 通过合并冗余命令,大幅减少AOF文件的大小
  2. 提高恢复速度: 更小的文件意味着更快的数据恢复
  3. 优化内存使用: 较小的AOF文件减少了磁盘和内存的使用

注意事项:

  • 重写过程可能会暂时增加内存使用
  • 在高负载情况下,可能会影响Redis的性能

AOF 校验机制了解吗?

主要是通过校验和的数字来验证 AOF 文件

  1. 校验和计算:
    • Redis在每次AOF重写操作完成后,会对新的AOF文件内容进行CRC64算法计算,得出一个校验和。
  1. 校验和存储:
    • 计算得到的校验和会被存储在一个单独的文件中,通常命名为[aof-file-name].manifest。
  1. 启动时检查:
    • 当Redis启动时,它会读取AOF文件及其对应的manifest文件。
    • Redis会重新计算AOF文件的CRC64校验和,并与manifest文件中存储的校验和进行比较。
  1. 完整性验证:
    • 如果计算得到的校验和与存储的校验和匹配,Redis认为AOF文件是完整的。
    • 如果校验和不匹配,Redis会报告AOF文件可能已损坏,并可能拒绝启动(取决于配置)。

RDB 和 AOF 的混合持久化

混合持久化的优点:

  • 混合持久化结合了RDB的快速加载和AOF的数据安全性。
  • 在AOF重写时,会同时使用RDB和AOF两种格式。

混合持久化的工作流程流程图

a. 触发AOF重写时,Redis执行以下步骤:

  • 创建一个当前数据集的RDB快照。
  • 将这个RDB快照写入新的AOF文件的开头。
  • 从快照创建开始,之后的写操作以AOF格式追加到文件末尾。

b. 最终的AOF文件结构: [RDB数据][AOF增量数据]

优势:

  • 快速加载:重启时可以快速加载RDB部分。
  • 数据安全:最近的变更记录在AOF部分,提供了更好的数据安全性。
  • 文件大小:通常比单纯的AOF文件小,因为RDB格式更紧凑。

重启过程:

  • Redis重启时,先加载RDB部分恢复大部分数据。
  • 然后执行AOF部分的命令来恢复最新的数据变更。

配置方式:

  • 通过设置 aof-use-rdb-preamble yes 来启用混合持久化。
  • 这个选项在Redis 4.0及以上版本可用。

注意事项:

  • 混合持久化文件不向后兼容,旧版Redis可能无法解析。
  • 在进行AOF重写时可能会暂时增加内存使用。

应用场景:

  • 适合既需要快速恢复又要求高数据安全性的场景。
  • 对于大型数据集特别有效,可以显著减少恢复时间。

原文地址:https://blog.csdn.net/qq_62775328/article/details/142418585

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!