Redis持久化《Redis开发与运维读书笔记》

文章目录

  • Redis支持RDB和AOF两种持久化机制
    • RDB (Redis Dump Binary )
      • 触发机制
      • RDB文件处理
      • RDB优缺点
    • AOF (Append-Only File)
      • 执行流程
      • 命令写入
      • 文件同步
      • 重写机制
        • 重写会压缩AOF文件体积:
        • 触发机制:
        • 重新加载
        • 文件校验
    • 常见持久化问题
    • Redis 4.0 混合持久化

Redis支持RDB和AOF两种持久化机制

RDB (Redis Dump Binary )

RDB持久性以指定的时间间隔执行数据集的时间点 快照

触发机制

  • 手动触发
命令 说明
save 阻塞Redis直到RDB过程完成
bgsave Redis进程执行fork创建子进程来执行RDB。阻塞只发生在fork阶段。
Redis内部所有涉及RDB的操作都是采用bgsave
  • 自动触发
  1. 使用save m n 表示m秒内集存n次修改时自动触发bgsave
  2. 从节点执行全量复制操作,主节点自动执行bgsave生成RDB文件发送给从节点。
  3. 执行debug reload命令重新加载Redis时会自动触发save操作
  4. 默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave

RDB文件处理

  • 保存:RDB文件保存在dir配置的指定目录下
  • 压缩:Redis默认采用LZF算法对RDB文件做压缩处理,线上建议开启
  • 校验:如果Redis加载损坏的RDB文件时拒绝启动

RDB优缺点

  • 优点
  1. RDB是一个紧凑压缩的二进制文件,代表redis在某个时间节点上的数据快照。非常适合备份、全量复制等功能。
  2. Redis加载RDB恢复数据的速度远远告诉AOF
  • 缺点
  1. 无法实时/秒级持久化。因为bgsave操作需要fork新的进程属于重量级操作,频繁操作成本高。
  2. RDB文件使用特定的二进制格式保存,可能存在老版本Redis无法兼容新版RDB文件的问题。

AOF (Append-Only File)

以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到回复数据的目的。
AOF主要解决数据持久化的实时性问题。

执行流程

1)所有写入命令回追加到aof_buf缓冲区中
2)AOF缓冲区根据对应的策略向硬盘做同步操作
3)随着AOF文件越来越大需要定期对AOF文件重写达到压缩的目的
4) 当Redis重启时加载AOF文件进行数据恢复

命令写入

AOF命令写入的内容直接是文本协议格式,即Reids协议的文本。

文件同步

文件同步策略

可配置值 说明
always 命令写入aof_buf后调用系统的fsync同步AOF文件,并在完成后返回。会严重影响性能
everysec 命令写入aof_buf后调用系统的write命令后返回。fsync操作由专门的线程每秒钟执行一次。(默认配置:性能高,并且最多对视1秒钟的数据)
no 同步硬盘的操作由系统负责,通常同步周期为30秒

重写机制

重写会压缩AOF文件体积:

1)已超时的数据不再写入文件
2)多条命令合并:例如 lpush list a, lpush list b, lpush list c 合并为 lpush list a b c
3)就得AOF无效命令会在AOF文件种植保留最终的写入命令。例如:set a 111, set a 222 只保留 set a 222

触发机制:

  • 手动触发:直接调用bgrewriteaof命令
  • 自动触发:通过auto-aof-rewrite-min-sizeauto-aof-rewrite-percentage配置重写自动重写的时机。

重新加载

Redis持久化《Redis开发与运维读书笔记》_第1张图片

文件校验

加载损坏的AOF文件会拒绝启动。
AOF文件可能存在结尾不完整的情况,例如突然掉电了导致AOF文件不全。可以使用aof-load-truncated配置来兼容这种清空(默认是开启的)。

常见持久化问题

Redis持久化一直是影像Redis性能的高发地。
1)持久化阻塞主线程场景有:

  • fork阻塞: 阻塞时间跟内存量和系统有关
  • AOF追加阻塞:跟硬盘资源紧张有关

2)Redis单进程架构导致无法充分利用CPU多核特性。可以单机部署多实例。为了避免出现多个子进程进行重写操作建议做隔离控制,避免CPU和IO资源竞争。

Redis 4.0 混合持久化

重启 Redis 时,我们很少使用 rdb 来恢复内存状态,因为会丢失大量数据。我们通常使用 AOF 日志重放,但是重放 AOF 日志性能相对 rdb 来说要慢很多,这样在 Redis 实例很大的情况下,启动需要花费很长的时间。

Redis 4.0 为了解决这个问题,带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志,而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志,通常这部分 AOF 日志很小。

于是在 Redis 重启的时候,可以先加载 rdb 的内容,然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放,重启效率因此大幅得到提升。

你可能感兴趣的:(redis)