Redis 7持久化RDB和AOF的原理机制讲解（图文教程）

1.概述

Redis是一个基于内存的数据库，这意味着其主要数据存储和操作均在内存中进行。这种设计使得Redis能够提供极快的读写速度(通常达到微秒级别)，适用于高性能场景，如缓存

• 然而，由于内存的易失性(断电后数据会丢失)，Redis提供了持久化机制：将内存中的数据保存到磁盘中，确保数据在Redis服务重启或崩溃后能够恢复。通过持久化，可以避免数据丢失，提高数据的可靠性
• Redis提供两种持久化方式
  • RDB(Redis Database)：生成数据集的快照实现持久化
  • AOF(Append Only File)：记录所有写操作命令，以追加方式写入文件

2.RDB

RDB指的是Redis的一种持久化机制，其核心是生成Redis数据在某个时间点的快照

2.1 快照原理

由于Redis是单线程应用程序，在线上环境时，不仅要处理来自客户端的请求，还要执行内存快照操作(进行文件IO)。单线程同时处理客户端请求和文件IO时会严重降低服务器性能，甚至阻塞客户端请求。因此，Redis使用 fork 和 写实拷贝(Copy On Write) 机制来实现快照持久化

fork

        Redis在进行RDB持久化时会调用fork函数来创建一个子进程负责完成，父进程则继续处理客户端请求。子进程在创建之初和父进程共享同一数据段

        Linux操作系统的内存空间被分为很多种片段，每个片段又被分为很多个页面，每个页面4KB

写实拷贝

        当父进程对数据段中的某一数据页面进行修改操作时，Linux操作系统会将该数据页面复制一份分离出来，然后对该页面进行修改，最后父进程指向指向修改后的页面。随着被修改的页面越来越多，内存空间不断膨胀，最多达到原来的两倍
        从子进程被创建出来的那一刻起，直至拷贝结束，子进程始终指向原始的数据段且所有原数据段不会被修改。所以，在整个拷贝过程中 RDB快照 = 子进程看到的所有数据页面的瞬间状态集合

        拷贝完成后，子进程会被销毁，同时没有指针指向的数据页面也会被销毁

2.2 触发机制

Redis RDB的触发机制分为自动触发和手动触发两种方式

• 自动触发
  • 在redis.conf中通过save指令配置阈值。当在指定时间内发生足够数量的键修改时自动触发bgsave
  • 正常关闭Redis

    # 默认执行save(阻塞式)
    > shutdown
    # 或
    > shutdown save
    
    # 触发流程：
    1. 停止接受新连接
    2. 执行save(不是bgsave)
    3. 保存完成后退出
    

• 手动触发
  • save命令：同步阻塞式触发，执行期间Redis服务器不处理任何请求，直到RDB文件创建完成(不推荐)
  • bgsave命令：异步非阻塞式触发，Redis会fork一个子进程执行持久化操作，主进程继续处理请求

2.3 文件处理

        RDB文件保存在dir配置指定的目录下(默认/var/lib/redis)，文件名通过dbfilename配置指定(默认dump.sql)
        在RDB备份过程中，fork出的子进程会将内存数据写入临时文件，临时文件默认命名规则为temp-< pid >.rdb，其中< pid >是子进程的进程ID。当子进程完成RDB文件写入后，Redis会用原子性的rename操作将临时文件重命名为正式RDB文件并删除原文件

2.4 优缺点

优点

• 恢复速度快：RDB是数据的二进制快照，恢复时直接加载到内存
• 备份时对服务影响小：使用bgsave命令时，Redis通过fork子进程在后台保存数据，主进程可以继续处理客户端请求，几乎无阻塞
• 存储高效：RDB 文件使用二进制格式并支持LZF压缩

缺点

• 非实时一致性：RDB保存的是某个瞬间的快照，如果保存过程中有大量写入，快照可能不反映完全一致的业务状态
• 可能丢失更多数据：如果Redis意外宕机，从上一次RDB保存到宕机之间的所有数据修改都会丢失

3.AOF

AOF持久化通过将Redis服务器接收到的每个写命令追加到文件末尾来实现

# 开启AOF
appendonly yes

3.1 工作流程

• 命令追加：当Redis执行写命令时，该命令会以Redis协议格式追加到内存中的AOF缓冲区(aof_buf)。缓冲区会根据配置策略决定何时将内容同步到磁盘
• 文件写入与同步：AOF缓冲区内容会被写入到AOF文件，具体同步到磁盘的时机由appendfsync参数控制：
  • always：每次写命令后同步，数据安全性最高但性能影响较大
  • everysec：每秒同步一次，平衡性能与安全性(默认配置)
  • no：由操作系统决定同步时机，性能最好但可能丢失较多数据

3.2 重写机制

作用：解决AOF文件不断增长导致的存储空间占用和恢复效率问题。通过重写，可以生成一个更紧凑的AOF文件，仅包含重建当前数据集所需的最小命令集合(例如，对同一个键多次修改会记录多条命令，而重写机制会合并这些操作，仅保留最终状态的命令)

        父进程通过fork创建一个子进程来完成AOF文件的重写，确保主进程继续处理客户端请求。子进程会读取当前数据库的快照数据，并将其转换为一系列Redis命令写入新的临时AOF文件

        在重写过程中，主进程会将新接收到的写命令同时写入现有的AOF 缓冲区aof_buf(保证原有 AOF 文件正常更新)和AOF重写缓冲区aof_rewrite_buf(保证新命令不会丢失)

        当子进程完成重写后，会通知主进程。主进程会将 AOF 重写缓冲区中的命令追加到新生成的临时 AOF 文件中，最后原子性地替换旧文件

        在Redis7.0.15版本，AOF文件保存在dir + appenddirname配置指定的目录下(默认/var/lib/redis/appendonlydir)。文件前缀名通过appendfilename配置指定(默认appendonly)

• appendonly.aof.1.base.rdb：作为Redis AOF(Append-Only File)持久化机制的基准文件，存储某一时刻数据库的完整快照。格式为RDB，体积较小且加载速度快，用于重建数据的基础状态
• appendonly.aof.1.incr.aof和appendonly.aof.2.incr.aof：记录基准文件生成后的增量写操作命令，以文本形式追加存储。多个增量文件按操作顺序编号(如.1.incr.aof、.2.incr.aof)，Redis 重启时会按顺序重放这些命令以恢复最新数据
• appendonly.aof.manifest：描述AOF文件的组成和顺序的清单文件

4.混合持久化

        Redis 混合持久化结合了 RDB(快照)和 AOF(日志)两种持久化方式的优势，在保证数据安全性的同时兼顾性能

# 开启混合持久化
aof-use-rdb-preamble yes

• 基础RDB文件优先加载：appendonly.aof.1.base.rdb作为全量快照数据文件，会优先被加载。该文件包含某一时间点的完整数据快照，恢复时作为基准数据集
• 增量AOF文件后续应用：appendonly.aof.1.incr.aof作为增量操作日志，在基础RDB加载完成后被重放。该文件记录自 RDB 快照生成后的所有写操作，用于恢复最新数据状态

到此这篇关于Redis 7持久化RDB和AOF的原理机制讲解（图文教程）的文章就介绍到这了,更多相关Redis持久化RDB和AOF内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！