前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >一文深度揭秘Redis的磁盘持久化机制

一文深度揭秘Redis的磁盘持久化机制

作者头像
macrozheng
发布于 2024-06-13 05:54:21
发布于 2024-06-13 05:54:21
61000
代码可运行
举报
文章被收录于专栏:mall学习教程mall学习教程
运行总次数:0
代码可运行

前言

Redis 是内存数据库,数据都是存储在内存中,为了避免进程退出导致数据的永久丢失,需要定期将 Redis 中的数据以数据或命令的形式从内存保存到本地磁盘。当下次 Redis 重启时,利用持久化文件进行数据恢复。Redis 提供了 RDB 和 AOF 两种持久化机制,前者将当前的数据保存到磁盘,后者则是将每次执行的写命令保存到磁盘(类似于 MySQL 的 Binlog)。本文将详细介绍 RDB 和 AOF 两种持久化方案,包括操作方法和持久化的实现原理。

正文

Redis 是一个基于键值对(K-V)存储的数据库服务器,下面先介绍 Redis 数据库的内部构造以及 K-V 的存储形式,有助于我们更容易理解 Redis 的持久化机制。

1. Redis 数据库结构

一个单机的 Redis 服务器默认情况下有 16 个数据库(0-15 号),数据库的个数是可配置的。Redis 默认使用的是 0 号数据库,可以使用 SELECT 命令切换数据库。

Redis 中的每个数据库都由一个 redis.h/redisDb 结构表示,它记录了单个 Redis 数据库的键空间、所有键的过期时间、处于阻塞状态和就绪状态的键、数据库编号等等。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
typedef struct redisDb {
    // 数据库键空间,保存着数据库中的所有键值对
    dict *dict;
    // 键的过期时间,字典的键为键,字典的值为过期事件 UNIX 时间戳
    dict *expires;
    // 正处于阻塞状态的键
    dict *blocking_keys;
    // 可以解除阻塞的键
    dict *ready_keys;
    // 正在被 WATCH 命令监视的键
    dict *watched_keys;
    struct evictionPoolEntry *eviction_pool;
    // 数据库编号
    int id;
    // 数据库的键的平均 TTL,统计信息
    long long avg_ttl;
} redisDb;

由于 Redis 是一个键值对数据库(key-value pairs database), 所以它的数据库本身也是一个字典,对应的结构正是 redisDb。其中,dict 指向的是一个记录键值对数据的字典,它的键是一个字符串对象,它的值则可以是字符串、列表、哈希表、集合和有序集合在内的任意一种 Redis 类型对象。expires 指向的是一个用于记录键的过期时间的字典,它的键为 dict 中的数据库键,它的值为这个数据库键的过期时间戳,这个值以 long long 类型表示。

2. RDB 持久化

RDB 持久化(也称作快照持久化)是指将内存中的数据生成快照保存到磁盘里面,保存的文件后缀是 .rdb。rdb 文件是一个经过压缩的二进制文件,当 Redis 重新启动时,可以读取 rdb 快照文件恢复数据。RDB 功能最核心的是 rdbSave 和 rdbLoad 两个函数, 前者用于生成 RDB 文件并保存到磁盘,而后者则用于将 RDB 文件中的数据重新载入到内存中:

RDB 文件是一个单文件的全量数据,很适合数据的容灾备份与恢复,通过 RDB 文件恢复数据库耗时较短,通常 1G 的快照文件载入内存只需 20s 左右。Redis 提供了手动触发保存、自动保存间隔两种 RDB 文件的生成方式,下面先介绍 RDB 的创建和载入过程。

2.1. RDB 的创建和载入

Redis 服务器默认是通过 RDB 方式完成持久化的,对应 redis.conf 文件的配置项如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
# RDB文件的名称
dbfilename dump.rdb
# 备份RDBAOF文件存放路径
dir /usr/local/var/db/redis/
2.1.1. 手动触发保存

Redis 提供了两个用于生成 RDB 文件的命令,一个是 SAVE,另一个是 BGSAVE。而触发 Redis 进行 RDB 备份的方式有两种,一种是通过 SAVE 命令、BGSAVE 命令手动触发快照生成的方式,另一种是配置保存时间和写入次数,由 Redis 根据条件自动触发保存操作。

1. SAVE 命令

SAVE 是一个同步式的命令,它会阻塞 Redis 服务器进程,直到 RDB 文件创建完成为止。在服务器进程阻塞期间,服务器不能处理任何其他命令请求。

  • 客户端命令
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
127.0.0.1:6379> SAVE
OK
  • 服务端日志
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
6266:M 15 Sep 2019 08:31:01.258 * DB saved on disk

执行 SAVE 命令后,Redis 在服务端进程(PID 为 6266)执行了 SAVE 操作,这个操作发生期间会一直阻塞 Redis 客户端的请求处理。

2. BGSAVE 命令

BGSAVE 是一个异步式的命令,和 SAVE 命令直接阻塞服务器进程的做法不同,BGSAVE 命令会派生出一个子进程,由子进程负责创建 RDB 文件,服务器进程(父进程)继续处理客户的命令。

  • 客户端命令
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
127.0.0.1:6379> BGSAVE
Background saving started
  • 服务端日志
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
6266:M 15 Sep 2019 08:31:22.914 * Background saving started by pid 6283
6283:C 15 Sep 2019 08:31:22.915 * DB saved on disk
6266:M 15 Sep 2019 08:31:22.934 * Background saving terminated with success

通过服务端输出的日志,可以发现 Redis 在服务端进程(PID 为 6266)会为 BGSAVE 命令单独创建(fork)一个子进程(PID 为 6283),并由子进程在后台完成 RDB 的保存过程,在操作完成之后通知父进程然后退出。在整个过程中,服务器进程只会消耗少量时间在创建子进程和处理子进程信号量上面,其余时间都是待命状态。

BGSAVE 是触发 RDB 持久化的主流方式,下面给出 BGSAVE 命令生成快照的流程:

  1. 客户端发起 BGSAVE 命令,Redis 主进程判断当前是否存在正在执行备份的子进程,如果存在则直接返回
  2. 父进程 fork 一个子进程 (fork 的过程中会造成阻塞的情况),这个过程可以使用 info stats 命令查看 latest_fork_usec 选项,查看最近一次 fork 操作消耗的时间,单位是微秒
  3. 父进程 fork 完成之后,则会返回 Background saving started 的信息提示,此时 fork 阻塞解除
  4. fork 创建的子进程开始根据父进程的内存数据生成临时的快照文件,然后替换原文件
  5. 子进程备份完毕后向父进程发送完成信息,父进程更新统计信息
3. SAVE 和 BGSAVE 的比较

命令

SAVE

BGSAVE

IO 类型

同步

异步

是否阻塞

全程阻塞

fork 时发生阻塞

复杂度

O(n)

O(n)

优点

不会消耗额外的内存

不阻塞客户端

缺点

阻塞客户端

fork 子进程消耗内存

2.1.2. 自动触发保存

因为 BGSAVE 命令可以在不阻塞服务器进程的情况下执行,所以 Redis 的配置文件 redis.conf 提供了一个 save 选项,让服务器每隔一段时间自动执行一次 BGSAVE 命令。用户可以通过 save 选项设置多个保存条件,只要其中任意一个条件被满足,服务器就会执行 BGSAVE 命令。Redis 配置文件 redis.conf 默认配置了以下 3 个保存条件:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
save 900 1
save 300 10
save 60 10000

那么只要满足以下 3 个条件中的任意一个,BGSAVE 命令就会被自动执行:

  • 服务器在 900 秒之内,对数据库进行了至少 1 次修改。
  • 服务器在 300 秒之内,对数据库进行了至少 10 次修改。
  • 服务器在 60 秒之内,对数据库进行了至少 10000 次修改。

比如通过命令 SET msg "hello" 插入一条键值对,等待 900 秒后 Reids 服务器进程自动触发保存,输出如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
6266:M 15 Sep 2019 08:46:22.981 * 1 changes in 900 seconds. Saving...
6266:M 15 Sep 2019 08:46:22.986 * Background saving started by pid 6266
6476:C 15 Sep 2019 08:46:23.015 * DB saved on disk
6266:M 15 Sep 2019 08:46:23.096 * Background saving terminated with success

Redis 服务器会周期性地操作 serverCron 函数,这个函数每隔 100 毫秒就会执行一次,它的一项任务就是检查 save 选项所设置的保存条件是否满足,如果满足的话,就自动执行 BGSAVE 命令。

2.1.3. 启动自动载入

和使用 SAVE 和 BGSAVE 命令创建 RDB 文件不同,Redis 没有专门提供用于载入 RDB 文件的命令,RDB 文件的载入过程是在 Redis 服务器启动时自动完成的。启动时只要在指定目录检测到 RDB 文件的存在,Redis 就会通过 rdbLoad 函数自动载入 RDB 文件。

下面是 Redis 服务器启动时打印的日志,倒数第 2 条日志是在成功载入 RDB 文件后打印的。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ redis-server /usr/local/etc/redis.conf
6266:M 15 Sep 2019 08:30:41.832 # Server initialized
6266:M 15 Sep 2019 08:30:41.833 * DB loaded from disk: 0.001 seconds
6266:M 15 Sep 2019 08:30:41.833 * Ready to accept connections

由于 AOF 文件属于增量的写入命令备份,RDB 文件属于全量的数据备份,所以更新频率比 RDB 文件的更新频率高。所以如果 Redis 服务器开启了 AOF 持久化功能,那么服务器会优先使用 AOF 文件来还原数据库状态;只有在 AOF 的持久化功能处于关闭状态时,服务器才会使用使用 RDB 文件还原数据库状态。

2.2. RDB 的文件结构

RDB 文件是经过压缩的二进制文件,下面介绍关于 RDB 文件内部构造的一些细节。

2.2.1. 存储路径

SAVE 命令和 BGSAVE 命令都只会备份当前数据库,备份文件名默认为 dump.rdb,可通过配置文件修改备份文件名 dbfilename xxx.rdb。可以通过以下命令查看备份文件目录和 RDB 文件名称:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/usr/local/var/db/redis"
127.0.0.1:6379> CONFIG GET dbfilename
1) "dbfilename"
2) "dump.rdb"

RDB 文件的存储路径既可以在启动前配置,也可以通过命令动态设定。

  • 配置项:通过 dir 配置指定目录,dbfilename 指定文件名
  • 动态指定:Redis 启动后也可以动态修改 RDB 存储路径,在磁盘损害或空间不足时非常有用,执行命令为:
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
CONFIG SET dir $newdir
CONFIG SET dbfilename $newFileName
2.2.2. 文件格式

RDB 文件有固定的格式要求,它保存的是二进制数据,大体可以分为以下 5 部分:

  • REDIS:文件头保存的是长为 5 个字节的 REDIS 字符,用于标识当前文件为 RDB 类型
  • db_version:一个 4 个字节长的整数字符串,用于记录 RDB 文件的版本号
  • aux:记录着 RDB 文件中元数据信息,包含 8 个附加
    • redis-ver:Redis 实例的版本号
    • redis-bits:运行 Redis 实例的主机架构,64 位或 32 位
    • ctime:RDB 创建时的 Unix 时间戳
    • used_mem:存储快照时使用的内存大小
    • repl-stream-db:Redis 服务器的 db 的索引
    • repl-id:Redis 主实例的 ID(replication id)
    • repl-offset:Redis 主实例的偏称量(replication offset)
    • aof-preamble:是否在 AOF 文件头部放置 RDB 快照(即开启混合持久化)
  • databases:部分包含着零个或者任意多个数据库,以及各个数据库的键值对数据
  • EOF:是 1 个字节的常量,用于标志 RDB 文件的正文内容结束
  • check_sum:一个 8 字节长的整数,保存着由前面四个部分计算得到的校验和,用于检测 RDB 文件的完整性
1. database

一个 RDB 文件的 databases 部分包含着零个或者任意多个数据库(database),而每个非空的 database 都包含 SELECTDB、db_number 以及 key_value_pairs 三个部分:

  • SELECTDB:长度为一个字节的常量,告诉用户程序接下来要读取的是一个 db_number
  • db_number:保存着一个数据库编号。当程序读到 db_number 时,服务器会立即调用 SELECT 命令切换到对应编号的数据库
  • key_value_pairs:保存了数据库中的所有键值对数据,包括带过期时间和不带过期时间两种类型的键值对
2. key_value_pairs

RDB 的 key_value_pairs 部分保存了一个或者多个键值对,如果键值对有过期时间,过期时间会被保存在键值对的前面。下面是这两种键值对的内部结构:

  • EXPIREMENT_MS:长度为一个字节的常量,告诉用户程序接下来要读取的是一个以毫秒为单位的过期时间
  • ms:一个长度为 8 个字节的整数,记录着键值对的过期时间,是一个以毫秒为单位的时间戳
  • TYPE:记录了 value 的类型,长度为 1 个字节。每个 TYPE 常量都代表了一种对象类型或者底层编码, 当服务器读入 RDB 文件中的键值对数据时, 程序会根据 TYPE 的值来决定如何读入和解释 value 的数据。它的值定义通常为以下常量之一:
    • REDIS_RDB_TYPE_STRING:字符串
    • REDIS_RDB_TYPE_LIST:列表类型
    • REDIS_RDB_TYPE_SET:集合类型
    • REDIS_RDB_TYPE_ZSET:有序集合
    • REDIS_RDB_TYPE_HASH:哈希类型
    • REDIS_RDB_TYPE_LIST_ZIPLIST:列表类型
    • REDIS_RDB_TYPE_SET_INT_SET:集合类型
    • REDIS_RDB_TYPE_ZSET_ZIPLIST:有序集合
    • REDIS_RDB_TYPE_HASH_ZIPLIST:哈希类型
  • key:一个字符串对象,编码格式和 REDIS_RDB_TYPE_STRING 类型的 value 一样
  • value:取决于 TYPE 的类型,对象类型可以是 string、list、set、zset 和 hash

为了查看 RDB 文件内部的结构,执行以下命令往 Redis 服务器插入 3 条键值对数据:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
127.0.0.1:6379> SADD fruits "apple" "banana" "orange"
(integer) 3
127.0.0.1:6379> LPUSH numbers 128 256 512
(integer) 3
127.0.0.1:6379> SET msg "hello"
OK

执行 SAVE 操作,将 Redis 进程中的数据强制持久化到 dump.rdb 文件中

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
127.0.0.1:6379> SAVE
OK

通过 Linux 的 od 命令将二进制文件 dump.rdb 中的数据转换为 ASCII 格式输出,跟前面提到的存储格式大致是一样的:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ od -c dump.rdb
0000000    R   E   D   I   S   0   0   0   9 372  \t   r   e   d   i   s
0000020    -   v   e   r 005   5   .   0   .   5 372  \n   r   e   d   i
0000040    s   -   b   i   t   s 300   @ 372 005   c   t   i   m   e 200
0000060  200 200 231   ] 372  \b   u   s   e   d   -   m   e   m 302 200
0000100   \v 020  \0 372  \f   a   o   f   -   p   r   e   a   m   b   l
0000120    e 300  \0 376  \0 373 003  \0  \0 003   m   s   g 005   h   e
0000140    l   l   o 016  \a   n   u   m   b   e   r   s 001 027 027  \0
0000160   \0  \0 022  \0  \0  \0 003  \0  \0 300  \0 002 004 300  \0 001
0000200  004 300 200  \0 377 002 006   f   r   u   i   t   s 003 006   o
0000220    r   a   n   g   e 005   a   p   p   l   e 006   b   a   n   a
0000240    n   a 377 214   ک  **   3 366   <   r   X
0000253
2.3. RDB 常用的配置项

下面是 redis.conf 文件中和 RDB 文件相关的常用配置项(以及默认值):

  • save m n:bgsave 自动触发的条件;如果没有 save m n 配置,相当于自动的 RDB 持久化关闭,不过此时仍可以通过其他方式触发。
  • stop-writes-on-bgsave-error yes:当 bgsave 出现错误时,Redis 是否停止执行写命令。如果设置为 yes,则当硬盘出现问题时,可以及时发现,避免数据的大量丢失;如果设置为 no,则 Redis 忽略 bgsave 的错误继续执行写命令,当对 Redis 服务器的系统(尤其是硬盘)使用了监控时,该选项考虑设置为 no。
  • rdbcompression yes:是否开启 RDB 文件压缩。
  • rdbchecksum yes:是否开启 RDB 文件的校验,在写入文件和读取文件时都起作用。关闭 checksum 在写入文件和启动文件时大约能带来 10% 的性能提升,但是数据损坏时无法发现。
  • dbfilename dump.rdb:设置 RDB 的文件名。
  • dir ./:设置 RDB 文件和 AOF 文件所在目录。

3. AOF 持久化

RDB 持久化是定期把内存中的数据全量写入到文件中,除此之外,RDB 还提供了基于 AOF(Append Only File)的持久化功能。AOF 会把 Redis 服务器每次执行的写命令记录到一个日志文件中,当服务器重启时再次执行 AOF 文件中的命令来恢复数据。

AOF 的主要作用是解决了数据持久化的实时性,目前已经成为了 Redis 持久化的主流方式。

3.1. AOF 的创建和载入

默认情况下 AOF 功能是关闭的,Redis 只会通过 RDB 完成数据持久化的。开启 AOF 功能需要 redis.conf 文件中将 appendonly 配置项修改为 yes,这样在开启 AOF 持久化功能的同时,将基于 RDB 的快照持久化置于低优先级。修改 redis.conf 如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
# 此选项为AOF功能的开关,默认为no,通过yes来开启aof功能
appendonly yes
# 指定AOF文件名称
appendfilename appendonly.aof
# 备份RDBAOF文件存放路径
dir /usr/local/var/db/redis/
3.1.1. AOF 的创建

重启 Redis 服务器进程以后,dir 目录下会生成一个 appendonly.aof 文件,由于此时服务器未执行任何写指令,因此 AOF 文件是空的。执行以下命令写入几条测试数据:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
127.0.0.1:6379> SADD fruits "apple" "banana" "orange"
(integer) 3
127.0.0.1:6379> LPUSH numbers 128 256 512
(integer) 3
127.0.0.1:6379> SET msg "hello"
OK

AOF 文件是纯文本格式的,上述写命令按顺序被写入了 appendonly.aof 文件(省掉换行符 '\r\n'):

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
/usr/local/var/db/redis$ cat appendonly.aof
*2 $6 SELECT $1 0
*5 $4 SADD $6 fruits $5 apple $6 banana $6 orange
*5 $5 LPUSH $7 numbers $3 128 $3 256 $3 512
*3 $3 SET $3 msg $5 hello

RDB 持久化的方式是将 apple、banana、orange 的键值对数据保存为 RDB 的二进制文件,而 AOF 是通过把 Redis 服务器执行的 SADD、LPUSH、SET 等命令保存到 AOF 的文本文件中。下图是 AOF 文件内部的构造图:

3.1.2. AOF 的载入

再次重启 Redis 服务器进程,观察启动日志会发现 Redis 会通过 AOF 文件加载数据:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
52580:M 15 Sep 2019 16:09:47.015 # Server initialized
52580:M 15 Sep 2019 16:09:47.015 * DB loaded from append only file: 0.001 seconds
52580:M 15 Sep 2019 16:09:47.015 * Ready to accept connections

通过命令读取 AOF 文件还原的键值对数据:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
127.0.0.1:6379> SMEMBERS fruits
1) "apple"
2) "orange"
3) "banana"
127.0.0.1:6379> LRANGE numbers 0 -1
1) "512"
2) "256"
3) "128"
127.0.0.1:6379> GET msg
"hello"
3.2. AOF 的执行流程

AOF 不需要设置任何触发条件,对 Redis 服务器的所有写命令都会自动记录到 AOF 文件中,下面介绍 AOF 持久化的执行流程。

AOF 文件的写入流程可以分为以下 3 个步骤:

  1. 命令追加(append):将 Redis 执行的写命令追加到 AOF 的缓冲区 aof_buf
  2. 文件写入(write)和文件同步(fsync):AOF 根据对应的策略将 aof_buf 的数据同步到硬盘
  3. 文件重写(rewrite):定期对 AOF 进行重写,从而实现对写命令的压缩。
3.2.1. 命令追加

Redis 使用单线程处理客户端命令,为了避免每次有写命令就直接写入磁盘,导致磁盘 IO 成为 Redis 的性能瓶颈,Redis 会先把执行的写命令追加(append)到一个 aof_buf 缓冲区,而不是直接写入文件。

命令追加的格式是 Redis 命令请求的协议格式,它是一种纯文本格式,具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点。在 AOF 文件中,除了用于指定数据库的 select 命令(比如:select 0 为选中 0 号数据库)是由 Redis 添加的,其他都是客户端发送来的写命令。

3.2.2. 文件写入和文件同步

Redis 提供了多种 AOF 缓存区的文件同步策略,相关策略涉及到操作系统的 write() 函数和 fsync() 函数,说明如下:

1. write()

为了提高文件的写入效率,当用户调用 write 函数将数据写入文件时,操作系统会先把数据写入到一个内存缓冲区里,当缓冲区被填满或超过了指定时限后,才真正将缓冲区的数据写入到磁盘里。

2. fsync()

虽然操作系统底层对 write() 函数进行了优化 ,但也带来了安全问题。如果宕机内存缓冲区中的数据会丢失,因此系统同时提供了同步函数 fsync() ,强制操作系统立刻将缓冲区中的数据写入到磁盘中,从而保证了数据持久化。

Redis 提供了 appendfsync 配置项来控制 AOF 缓存区的文件同步策略,appendfsync 可配置以下三种策略:

  • appendfsync always:每执行一次命令保存一次

命令写入 aof_buf 缓冲区后立即调用系统 fsync 函数同步到 AOF 文件,fsync 操作完成后线程返回,整个过程是阻塞的。这种情况下,每次有写命令都要同步到 AOF 文件,硬盘 IO 成为性能瓶颈,Redis 只能支持大约几百 TPS 写入,严重降低了 Redis 的性能。

  • appendfsync no:不保存

命令写入 aof_buf 缓冲区后调用系统 write 操作,不对 AOF 文件做 fsync 同步;同步由操作系统负责,通常同步周期为 30 秒。这种情况下,文件同步的时间不可控,且缓冲区中堆积的数据会很多,数据安全性无法保证。

  • appendfsync everysec:每秒钟保存一次

命令写入 aof_buf 缓冲区后调用系统 write 操作,write 完成后线程立刻返回,fsync 同步文件操作由单独的进程每秒调用一次。everysec 是前述两种策略的折中,是性能和数据安全性的平衡,因此也是 Redis 的默认配置,也是比较推崇的配置选项。

文件同步策略

write 阻塞

fsync 阻塞

宕机时的数据丢失量

always

阻塞

阻塞

最多只丢失一个命令的数据

no

阻塞

不阻塞

操作系统最后一次对 AOF 文件 fsync 后的数据

everysec

阻塞

不阻塞

一般不超过 1 秒钟的数据

3.2.3. 文件重写

随着命令不断写入 AOF,文件会越来越大,导致文件占用空间变大,数据恢复时间变长。为了解决这个问题,Redis 引入了重写机制来对 AOF 文件中的写命令进行合并,进一步压缩文件体积。

AOF 文件重写指的是把 Redis 进程内的数据转化为写命令,同步到新的 AOF 文件中,然后使用新的 AOF 文件覆盖旧的 AOF 文件,这个过程不对旧的 AOF 文件的进行任何读写操作。

1. 触发机制

AOF 重写过程提供了手动触发和自动触发两种机制:

  • 手动触发:直接调用 bgrewriteaof 命令,该命令的执行与 bgsave 有些类似,都是 fork 子进程进行具体的工作,且都只有在 fork 时会阻塞
  • 自动触发:根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 配置项,以及 aof_current_size 和 aof_base_size 的状态确定触发时机
    • auto-aof-rewrite-min-size:执行 AOF 重写时,文件的最小体积,默认值为 64MB
    • auto-aof-rewrite-percentage:执行 AOF 重写时,当前 AOF 大小(aof_current_size)和上一次重写时 AOF 大小(aof_base_size)的比值
2. 重写流程

下面以手动触发 AOF 重写为例,当 bgrewriteaof 命令被执行时,AOF 文件重写的流程如下:

  1. 客户端通过 bgrewriteaof 命令对 Redis 主进程发起 AOF 重写请求
  2. 当前不存在正在执行 bgsave/bgrewriteaof 的子进程时,Redis 主进程通过 fork 操作创建子进程,这个过程主进程是阻塞的。如果发现 bgrewriteaof 子进程直接返回;如果发现 bgsave 子进程则等 bgsave 执行完成后再执行 fork 操作
  3. 主进程的 fork 操作完成后,继续处理其他命令,把新的写命令同时追加到 aof_buf 和 aof_rewrite_buf 缓冲区中
    • 在文件重写完成之前,主进程会继续把写命令追加到 aof_buf 缓冲区,根据 appendfsync 策略同步到旧的 AOF 文件,这样可以避免 AOF 重写失败造成数据丢失,保证原有的 AOF 文件的正确性
    • 由于 fork 操作运用写时复制技术,子进程只能共享 fork 操作时的内存数据,主进程会把新命令追加到一个 aof_rewrite_buf 缓冲区中,避免 AOF 重写时丢失这部分数据
  4. 子进程读取 Redis 进程中的数据快照,生成写入命令并按照命令合并规则批量写入到新的 AOF 文件
  5. 子进程写完新的 AOF 文件后,向主进程发信号,主进程更新统计信息,具体可以通过 info persistence 查看
  6. 主进程接受到子进程的信号以后,将 aof_rewrite_buf 缓冲区中的写命令追加到新的 AOF 文件
  7. 主进程使用新的 AOF 文件替换旧的 AOF 文件,AOF 重写过程完成
3. 压缩机制

文件重写之所以能够压缩 AOF 文件的大小,原因在于以下几方面:

  • 过期的数据不再写入 AOF 文件
  • 无效的命令不再写入 AOF 文件。比如:重复为数据设值(set mykey v1, set mykey v2)、删除键值对数据(sadd myset v1, del myset)等等
  • 多条命令可以合并为单个。比如:sadd myset v1, sadd myset v2, sadd myset v3 可以合并为 sadd myset v1 v2 v3。不过为了防止单条命令过大造成客户端缓冲区溢出,对于 list、set、hash、zset 类型的 key,并不一定只使用单条命令,而是以某个 Redis 定义的一个常量为界,将命令拆分为多条
3.3. AOF 常用的配置项

下面是 redis.conf 文件中和 AOF 文件相关的常用配置项(以及默认值):

  • appendonly no:是否开启 AOF 持久化功能
  • appendfilename "appendonly.aof":AOF 文件的名称
  • dir ./:RDB 文件和 AOF 文件所在目录
  • appendfsync everysec:fsync 持久化策略
  • no-appendfsync-on-rewrite no:重写 AOF 文件期间是否禁止 fsync 操作。如果开启该选项,可以减轻文件重写时 CPU 和磁盘的负载(尤其是磁盘),但是可能会丢失 AOF 重写期间的数据,需要在负载和安全性之间进行平衡
  • auto-aof-rewrite-percentage 100:AOF 文件重写触发条件之一
  • auto-aof-rewrite-min-size 64mb:AOF 文件重写触发条件之一
  • aof-load-truncated yes:如果 AOF 文件结尾损坏,Redis 服务器在启动时是否仍载入 AOF 文件

4. 数据恢复机制

前面提到当 AOF 持久化功能开启时,Redis 服务器启动时优先执行 AOF 文件的命令恢复数据,只有当 AOF 功能关闭时,才会优先载入 RDB 快照的文件数据。

  • 当 AOF 功能关闭,且 RDB 持久化开启时,Redis 服务器启动日志:
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
6266:M 15 Sep 2019 08:30:41.832 # Server initialized
6266:M 15 Sep 2019 08:30:41.833 * DB loaded from disk: 0.001 seconds
6266:M 15 Sep 2019 08:30:41.833 * Ready to accept connections
  • 当 AOF 功能开启,且 AOF 文件存在时,Redis 服务器启动日志:
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
9447:M 15 Sep 2019 23:01:46.601 # Server initialized
9447:M 15 Sep 2019 23:01:46.602 * DB loaded from append only file: 0.001 seconds
9447:M 15 Sep 2019 23:01:46.602 * Ready to accept connections
  • 当 AOF 功能开启,且 AOF 文件不存在时,即使 RDB 文件存在也不会加载,Redis 服务器启动日志:
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
9326:M 15 Sep 2019 22:49:24.203 # Server initialized
9326:M 15 Sep 2019 22:49:24.203 * Ready to accept connections

5. RDB 和 AOF 对比

持久化机制

RDB

AOF

启动优先级

磁盘文件体积

数据还原速度

数据安全性

容易丢失数据

根据策略决定

操作轻重级别

5.1. RDB 的优缺点
5.1.1. 优点
  • RDB 是一个压缩过的非常紧凑的文件,保存着某个时间点的数据集,适合做数据的备份、灾难恢复
  • 可以最大化 Redis 的性能,在保存 RDB 文件,服务器进程只需 fork 一个子进程来完成 RDB 文件的创建,父进程不需要做 IO 操作
  • 与 AOF 持久化方式相比,恢复大数据集的时候会更快
5.1.2. 缺点
  • RDB 的数据安全性是不如 AOF 的,保存整个数据集是个重量级的过程,根据配置可能要几分钟才进行一次持久化,如果服务器宕机,那么就可能丢失几分钟的数据
  • Redis 数据集较大时,fork 的子进程要完成快照会比较耗费 CPU 和时间
5.2. AOF 的优缺点
5.2.1. 优点
  • 数据更完整,安全性更高,秒级数据丢失(取决于 fsync 策略,如果是 everysec,最多丢失 1 秒的数据)
  • AOF 文件是一个只进行追加的命令文件,且写入操作是以 Redis 协议的格式保存的,内容是可读的,适合误删紧急恢复
5.2.2. 缺点
  • 对于相同的数据集,AOF 文件的体积要远远大于 RDB 文件,数据恢复也会比较慢
  • 根据所使用的 fsync 策略,AOF 的速度可能会慢于 RDB。不过在一般情况下, 每秒 fsync 的性能依然非常高

6. RDB-AOF 混合持久化

在重启 Redis 服务器时,一般很少使用 RDB 快照文件来恢复内存状态,因为会丢失大量数据。更多的是使用 AOF 文件进行命令重放,但是执行 AOF 命令性能相对 RDB 来说要慢很多。这样在 Redis 数据很大的情况下,启动需要消耗大量的时间。

鉴于 RDB 快照可能会造成数据丢失,AOF 指令恢复数据慢,Redis 4.0 版本提供了一套基于 AOF-RDB 的混合持久化机制,保留了两种持久化机制的优点。这样重写的 AOF 文件由两部份组成,一部分是 RDB 格式的头部数据,另一部分是 AOF 格式的尾部指令。

Redis 4.0 版本的混合持久化功能默认是关闭的,通过配置 aof-use-rdb-preamble 为 yes 开启此功能:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
# 开启AOF-RDB混合持久化机制
aof-use-rdb-preamble yes

查看 Redis 服务器是否开启混合持久化功能:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
127.0.0.1:6379> CONFIG GET aof-use-rdb-preamble
1) "aof-use-rdb-preamble"
2) "yes"

如图所示,将 RDB 数据文件的内容和增量的 AOF 命令文件存在一起。这里的 AOF 命令不再是全量的命令,而是自持久化开始到持久化结束的这段时间服务器进程执行的增量 AOF 命令,通常这部分 AOF 命令很小。

在 Redis 服务器重启的时候,可以预先加载 AOF 文件头部全量的 RDB 数据,然后再重放 AOF 文件尾部增量的 AOF 命令,从而大大减少了重启过程中数据还原的时间。

7. 持久化策略选择

7.1. RDB 和 AOF 性能开销

在介绍持久化策略之前,首先要明白无论是 RDB 还是 AOF 方式,开启持久化都是会造成性能开销的。

  • RDB 持久化:
    • BGSAVE 命令在进行 fork 操作时,Redis 服务器主进程会发生阻塞
    • Redis 子进程向磁盘写入数据也会带来 IO 压力
  • AOF 持久化:
    • 向磁盘写入数据的频率大大提高,IO 压力更大,甚至可能造成 AOF 追加阻塞问题
    • AOF 文件重写与 RDB 的 BGSAVE 过程类似,存在父进程 fork 时的阻塞和子进程的 IO 压力问题

相对来说,由于 AOF 向磁盘中写入数据的频率更高,因此对 Redis 服务器主进程性能的影响会更大。

7.2. 持久化策略

在实际生产环境中,根据数据量、应用对数据的安全要求、预算限制等不同情况,会有各种各样的持久化策略。

  1. 完全不使用任何持久化功能
  2. 使用 RDB 或 AOF 其中一种
  3. 同时开启 RDB 和 AOF 持久化

对于分布式环境,持久化的选择必须与 Redis 的主从策略一起考虑,因为主从复制与持久化同样具有数据备份的功能,而且主节点(Master Node)和从节点(Slave Node)可以独立选择持久化方案。

下面分场景来讨论持久化策略的选择,下面的讨论也只是作为参考,实际方案可能更复杂更具多样性。

7.2.1. 数据库缓存

如果 Redis 中的数据完全丢弃也没有关系(如 Redis 完全用作 DB 层数据的缓存),那么无论是单机,还是主从架构,都可以不进行任何持久化。

7.2.2. 单机环境

在单机环境下,如果可以接受十几分钟或更多的数据丢失,RDB 方案对 Redis 的性能更加有利;如果只能接受秒级别的数据丢失,选择 AOF 方案更合适。

7.2.3. 主从部署

在多数情况下,Redis 都会配置主从部署机制。从节点(slave)既可以实现数据的热备,也可以进行读写分担 Redis 读请求,以及在主节点(master)宕机后的顶替作用。

在这种情况下,一种可行的做法如下:

  • master:完全关闭持久化(包括 RDB 和 AOF 功能),这样可以让主节点的性能达到最好
  • slave:关闭 RDB 功能,开启 AOF 功能(如果对数据安全要求不高,开启 RDB 关闭 AOF 也可以)。定时对持久化文件进行备份(如备份到其他文件夹,并标记好备份的时间)。然后关闭 AOF 的自动重写功能,然后添加定时任务,在每天 Redis 服务器闲时(如凌晨 12 点)调用 bgrewriteaof 手动重写。

为什么开启了主从复制,可以实现数据的热备份,还需要设置持久化呢?因为在一些特殊情况下,主从复制仍然不足以保证数据的安全,例如:

  • master 和 slave 同时停止:如果 master 节点和 slave 节点位于同一个机房,则一次停电事故就可能导致 master 和 slave 机器同时关机,Redis 服务器进程停止。如果没有持久化,则面临的是数据的完全丢失。
  • master 重启:如果 master 节点因为故障宕机,并且系统中有自动拉起机制(即检测到服务停止后重启该服务)将 master 节点自动重启。
    • 由于没有持久化文件,那么 master 重启后数据是空的,slave 同步数据也变成了空的
    • 如果 master 和 slave 节点都没有开启持久化,同样会引发数据的完全丢失
7.2.4. 异地备灾

前面的几种持久化策略,针对的都是一般的系统故障,如进程异常退出、宕机、断电等,这些故障不会损坏硬盘。但是对于一些可能导致硬盘损坏的灾难情况,如火灾地震,就需要进行异地灾备

  • 单机环境:可以定时将 RDB 文件或重写后的 AOF 文件,通过 scp 命令拷贝到远程机器,如阿里云、AWS 等
  • 主从部署,可以定时在 master 节点上执行 BGSAVE 操作,然后将 RDB 文件拷贝到远程机器,或者在 slave 节点上执行 bgrewriteaof 命令重写 AOF 文件后,将 AOF 文件拷贝到远程机器上。

由于 RDB 文件文件小、恢复速度快,灾难恢复一般采用 RDB 方式;异地备份的频率根据数据安全性的需要及其它条件来确定,但最好不要低于一天一次。

小结

本文主要开篇介绍了 Redis 服务器的数据库结构,进一步介绍了 Redis 提供的几种持久化机制,包括基于数据快照的 RDB 全量持久化、基于命令追加的 AOF 增量持久化以及 Redis 4.0 支持的混合持久化。对于 RDB 的持久化方式,给出了 RDB 快照的创建和还原过程,RDB 的文件结构以及相关配置项。对于 AOF 的持久化方式,给出了 AOF 日志的创建和还原过程,AOF 的执行流程,AOF 文件内部的格式以及相关配置项。在文章结尾分析了 RDB 和 AOF 方式各自的优缺点,性能开销,以及在单机环境、主从部署、异地备灾场景下的持久化策略。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-10-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 macrozheng 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
​新加坡 & 纽约大学 & 字节 提出 PLLaVA | 简单高效视频语言模型适应方法,超越GPT4V,突破资源限制 !
多模态大型语言模型(MLLMs)在训练大规模图像-文本对时已显示出在图像理解方面的卓越能力。与图像领域类似,最近的视频理解模型也探索了类似的流程,在大规模视频-文本数据上对LLMs进行微调。然而,这种方法需要高昂的计算资源和视频数据标注成本。一种更为实用的方法是调整预先训练好的图像领域MLLMs以适应视频数据。
AIGC 先锋科技
2024/07/08
5270
​新加坡 & 纽约大学 & 字节 提出 PLLaVA | 简单高效视频语言模型适应方法,超越GPT4V,突破资源限制 !
斯坦福大学 & 亚马逊 AI 探索视觉-语言模型的前沿,当前方法与未来方向的调查!
大型语言模型(LLM)的出现标志着人工智能一个转型时代的开始, Reshape 了整个领域。跨越学术界和工业界的研究实验室正积极参与一场竞争,以推进LLM的能力。然而,一个值得注意的限制已经显现出来——这些模型仅限于处理单一类型的数据,特别是文本。这一限制凸显了在追求完善LLM以跨多个模态无缝运行的过程中一个关键挑战,这标志着在AI领域进一步创新的一个重要方向。
AIGC 先锋科技
2024/07/08
3810
斯坦福大学 & 亚马逊  AI 探索视觉-语言模型的前沿,当前方法与未来方向的调查!
中科大提出 ShareGPT4Video ,突破视频标注挑战,推动 LVLMs和 T2VMs 的发展!
多模态学习近期在大型语言模型的推动下,已经在图像文本对话和文本到图像生成任务上取得了进展。这激发了向视频理解和生成任务的转向,允许用户在视频和语言模态间进行交互。因此,桥接前述模态的详细且高保真的视频标题对于推进该领域的发展至关重要。
AIGC 先锋科技
2024/07/08
4950
中科大提出 ShareGPT4Video ,突破视频标注挑战,推动 LVLMs和 T2VMs 的发展!
轻量级视频压缩(LVC):以最小成本迁移长视频理解能力,解决VLMs采样问题并提升多模型性能 !
大语言模型(LLMs)的快速发展推动了视频理解研究范式的转变,从传统的以视觉为中心的方法转向利用跨模态对齐能力的基于LLM的框架。这种由LLM驱动的革命体现在两种主要架构中:在视频-文本对齐数据上预训练的视频LLMs[3, 16, 23]和以图像-文本对齐[19, 25]为核心的视觉语言模型(VLMs)。
AIGC 先锋科技
2025/05/14
1070
轻量级视频压缩(LVC):以最小成本迁移长视频理解能力,解决VLMs采样问题并提升多模型性能 !
多榜单登顶!华为 &amp; 哈工深团队提出 AdaReTaKe,突破长视频理解极限
随着视频内容的重要性日益提升,如何处理理解长视频成为多模态大模型面临的关键挑战。长视频理解能力,对于智慧安防、智能体的长期记忆以及多模态深度思考能力有着重要价值。
机器之心
2025/04/05
2500
多榜单登顶!华为 &amp; 哈工深团队提出 AdaReTaKe,突破长视频理解极限
每周AI论文速递(240722-240726)
大语言模型 (LLMs) 本应提供准确答案,但往往出现推理不足或生成虚构内容的问题。为此,一系列以“自-”为前缀的研究,如自一致性 (Self-Consistency)、自改进 (Self-Improve) 和自精炼 (Self-Refine) 应运而生。这些研究共同点在于:利用 LLMs 自身的评估和更新机制来解决上述问题。然而,当前的调查研究多侧重于分类,而未深入探讨这些研究背后的动机,因此缺乏一个统一的总结视角。本文中,我们提出一个名为内部一致性 (Internal Consistency) 的理论框架,该框架为诸如推理缺失和幻觉生成等现象提供了统一的解释。内部一致性通过采样方法,评估 LLMs 的潜在层、解码层和响应层之间的一致性。基于内部一致性框架,我们进一步提出一个简洁而有效的理论框架——自反馈 (Self-Feedback),该框架能够深入挖掘内部一致性。自反馈框架包含两个核心模块:自我评估 (Self-Evaluation) 和自我更新 (Self-Update),并已在多项研究中得到应用。我们系统地根据任务类型和工作领域对这些研究进行分类;总结了相关的评估方法和基准;并深入探讨了“自反馈是否真的有效?”这一核心问题。我们提出了几个关键观点,包括“内部一致性的沙漏进化”、“一致性即(几乎)正确性”假设和“潜在与显式推理的悖论”。此外,我们还概述了未来研究的可能方向。相关实验代码、参考文献和统计数据已开源,可访问 https://github.com/IAAR-Shanghai/ICSFSurvey 获取。
叶子的技术碎碎念
2025/04/08
1450
每周AI论文速递(240722-240726)
字节提出 LLaVA-OneVision :首个突破多模态模型性能瓶颈的开源大型模型 !
人工智能的核心愿望之一就是构建具有大规模视觉语言模型的通用助手[67]。LLaVA-OneVision是一个开源模型,致力于推进构建具有大规模视觉语言助手的(LLaVA)[83]研究,该助手可以适应各种指令,在野外完成各种计算机视觉任务。作为一种既省钱又高效的做法,它通常通过连接视觉编码器与大规模语言模型(LLM)来实现。
AIGC 先锋科技
2024/08/14
1.5K0
字节提出 LLaVA-OneVision :首个突破多模态模型性能瓶颈的开源大型模型 !
字节提出 MammothModa | 超越 LLaVA,集成视觉能力的多模态大型语言模型 !
近期,多模态大型语言模型(MLLMs)因其能够理解和生成受视觉输入影响的语言而受到了广泛关注。这些模型融合了视觉和文本数据,使得应用范围涵盖了图像字幕生成、视觉问答和视频分析等众多领域。尽管取得了进展,但许多MLLM在有效结合高分辨率和长时程视觉输入与复杂的语言理解方面,同时保持简洁和高效性方面仍面临挑战。
AIGC 先锋科技
2024/07/11
3080
字节提出 MammothModa | 超越 LLaVA,集成视觉能力的多模态大型语言模型 !
普林斯顿 & AWS & Apple 提出 RAVEN | 多任务检索增强视觉-语言模型框架,突破资源密集型预训练的限制 !
NLP模型规模快速增长,正如OpenAI的LLM发展所示,从GPT-2的15亿参数到GPT-3的1750亿(Brown et al., 2020),再到GPT-4的超一万亿,这引起了越来越多的关注。这一趋势需要更多的数据和计算能力,导致更高的碳排放,并为资源较少的研究行人带来重大障碍。作为回应,该领域正在转向如检索增强生成等方法,该方法将外部非参数的世界知识融入到预训练的语言模型中,无需将所有信息直接编码到模型的参数中。然而,这种策略在视觉-语言模型(VLMs)中尚未广泛应用,这些模型处理图像和文本数据,通常更加资源密集型。此外,VLMs通常依赖如LAION-5B 这样的大规模数据集,通过检索增强提供了显著提升性能的机会。
AIGC 先锋科技
2024/07/08
3640
普林斯顿 &  AWS & Apple 提出  RAVEN | 多任务检索增强视觉-语言模型框架,突破资源密集型预训练的限制 !
中山大学 & 华为诺亚实验室提出 HiRes-LLaVA 框架,解决切片的高分辨率LVLM引起的输入碎片化问题 !
近期在大型视觉-语言模型(LVLMs)方面的进展显著提高了视觉-语言任务的能力,促进了理解、推理和交互的改进。早期的LVLMs[34; 82; 44]以低分辨率处理图像,通常是,这限制了它们捕捉详细视觉信息的能力。这种局限性常常导致对图像中物体及其上下文关系的识别不准确[17; 41]。
AIGC 先锋科技
2024/07/31
3620
中山大学 & 华为诺亚实验室提出 HiRes-LLaVA 框架,解决切片的高分辨率LVLM引起的输入碎片化问题 !
英伟达 & MIT 提出 LongVILA ,从 8 帧到 1024 帧 如何实现长视频理解的飞跃 ?
将多个模态理解的集成与长序列能力的集成非常重要。支持更多模态的基础模型可以接受更灵活的输入信号,使人们可以以更多样化的方式与模型进行交互,例如类似 GPT-40 式的多模态聊天机器人,多模态网页代理(Koh 等人,2024年)和现实世界机器人基础模型(Brohan 等人,2022年、2023年;Padalkar 等人,2023年)。更长的上下文允许模型处理更多信息,例如更长的文档,仓库 Level 的代码库和小时的视频,这同样提供了现实世界应用所要求的功能。
AIGC 先锋科技
2024/08/27
5320
英伟达 & MIT 提出 LongVILA ,从 8 帧到 1024 帧 如何实现长视频理解的飞跃 ?
MiniGPT-Med | 多模态模型在医疗报告生成与疾病检测中取得突破性进展 !
图像文本数据在各个领域的数量激增以及视觉语言建模的进步为生成式预训练领域的研究开辟了道路。这个创新时代以GPT-4(Achiam等人,2023)和Gemini(团队等人,2023)等多模态模型的涌现为标志。这些进步意味着作者在处理和理解复杂数据方面的能力向前跃进了一步。尽管取得了这些进展,但在医疗领域采用多模态大型语言模型(LLM)仍然有限。医疗领域对数据复杂性、敏感性和特定性的独特要求凸显了需要量身定制的办法来发挥LLM在转变医疗研究和实践中的潜力。已经推出了许多为医疗应用设计的模型,但它们通常针对特定任务表现出高度的专门化。这种专业化限制了它们的适应性,尤其是在执行多样化的医疗应用时。例如,像Med-Flamingo 和 XrayGPT(Thawkar等人,2023)这样的模型主要是为医疗报告生成和医疗视觉问题回答等任务而定制的。然而,它们在需要视觉定位技能的关键领域(医疗领域的至关重要组成部分)如疾病检测方面缺乏能力。为了弥补这一不足,作者推出了MiniGPT-Med,一个能够熟练处理定位和非定位任务的统一模型。作者推出了MiniGPT-Med,这是一个为医疗领域的各种任务而设计的多功能模型,包括但不限于医疗报告生成、医疗视觉问题回答和疾病识别。MiniGPT-Med建立在大型语言模型(LLM)的架构之上,这些模型已经展示了出色的生成能力和广泛的语文学,包括医学知识。借鉴LLM在广泛的视觉语言应用中的成功,如最近的Zhu等人(2023年);Chen等人(2023年);Li等人(2024年)的研究所示,作者的模型采用了类似于 MiniGPT-v2 的设计,使用LLaMA-2语言模型作为通用接口。此外,作者融入了不同的任务标识符,以提高模型准确执行各种医疗视觉语言技能的能力。通过广泛的实验,作者证明了作者的模型在医疗视觉语言任务范围内表现出强大的性能,包括医疗报告生成、医疗视觉问题回答和疾病检测。作者将作者的模型与专业化和通用化 Baseline 模型进行了基准测试,结果显示作者的方法在所有评估任务中取得了强大的成果。值得注意的是,在医疗报告生成领域,作者的模型达到了最先进的表现,BERT-Sim上超过最佳 Baseline 模型19%,CheXbert-Sim上超过5.2%。这表明作者的模型在多样化的医疗视觉语言任务上具有强大的生成能力。
AIGC 先锋科技
2024/07/20
8840
MiniGPT-Med | 多模态模型在医疗报告生成与疾病检测中取得突破性进展 !
Cosmos-Reason1模型:借助层次化与二维本体实现物理AI推理,经四阶段训练及评估展现显著性能提升 !
物理AI系统需要在物理世界中感知、理解和执行复杂的动作。本文介绍了Cosmos-Reason1模型,该模型能够通过长期推理过程理解物理世界,并以自然语言生成适当的具身决策(例如,下一步行动)。
未来先知
2025/04/18
1410
Cosmos-Reason1模型:借助层次化与二维本体实现物理AI推理,经四阶段训练及评估展现显著性能提升 !
每周AI论文速递(241202-241206)
尽管视觉-语言-动作 (VLA) 模型在多种机器人任务中取得了进展,但其泛化能力受限,主要因完全依赖成功轨迹的行为克隆。此外,这些模型常针对不同设置下的专家演示进行微调,导致分布偏差,限制了其对多样化操作目标(如效率、安全性和任务完成度)的适应性。为此,我们提出 GRAPE: 通过偏好对齐泛化机器人策略。具体来说,GRAPE 在轨迹层面对齐 VLA,并从成功与失败试验中隐式建模奖励,以提升对多样化任务的泛化能力。同时,GRAPE 将复杂任务分解为独立阶段,并通过大型视觉-语言模型提出的关键点,利用定制时空约束自动引导偏好建模。这些约束灵活,可根据不同目标(如安全性、效率或任务成功)进行定制。我们在真实与模拟环境中广泛评估 GRAPE。实验显示,GRAPE 显著提升最先进 VLA 模型的性能,领域内与未见任务的成功率分别提高 51.79% 和 60.36%。此外,GRAPE 可与多种目标对齐,如安全性与效率,分别降低碰撞率 44.31% 和轨迹步长 11.15%。所有代码、模型及数据均可在 https://grape-vla.github.io/ 获取。
叶子的技术碎碎念
2025/04/08
760
每周AI论文速递(241202-241206)
最强全模态模型Ola-7B横扫图像、视频、音频主流榜单,腾讯混元Research&清华&NTU联手打造
Ola 是腾讯混元 Research、清华大学智能视觉实验室(i-Vision Group)和南洋理工大学 S-Lab 的合作项目。本文的共同第一作者为清华大学自动化系博士生刘祖炎和南洋理工大学博士生董宇昊,本文的通讯作者为腾讯高级研究员饶永铭和清华大学自动化系鲁继文教授。
机器之心
2025/02/19
1200
最强全模态模型Ola-7B横扫图像、视频、音频主流榜单,腾讯混元Research&清华&NTU联手打造
清华 & 港中文 & 香港科技 深入探究 LLM, 利用大型语言模型理解视频和动作序列的多模态人类行为!
理解人类行为,如细粒度标注和分析,在以人为中心的多模态智能领域[21, 25, 93]至关重要,并且可以从人机交互和机器人技术到医疗保健和安保的具身智能中受益。
AIGC 先锋科技
2024/07/08
5850
清华 &  港中文 & 香港科技 深入探究 LLM, 利用大型语言模型理解视频和动作序列的多模态人类行为!
清华提出 VoCo-LLaMA | 使用LLMs 进行视觉压缩,FLOPs 减少 94.8%,推理时间加快 69.6% !
视觉语言模型的出现导致了视觉理解的显著进步。特别是,高分辨率图像编码[7; 8]和更多视频帧的融合[9; 10]分别提高了大型视觉语言模型和大型视频语言模型的能力。然而,大量的视觉标记占据了大型语言模型宝贵的上下文窗口的大部分,导致了高昂的计算成本,如图1(a)所示。例如,在使用LLaVA-1.6[7]中的高分辨率图像输入时,一个分辨率为672×672的单个图像被划分为四个较小的块,每个块以336×336的分辨率进行编码。这个过程产生了包含2304个视觉标记的图像表示,占据了超过一半的上下文长度。此外,随着输入图像数量的增加,文本的上下文窗口将进一步受限。例如,Vicuna-1.5[11]在其4k上下文长度内只能处理大约7帧(7×576=4032个标记),考虑到文本输入。[9, 10]研究了将上下文长度扩展到百万级以缓解这个问题的影响,但这需要昂贵的计算资源(例如,[9]需要超过1000个v4 TPU)以及数据准备和框架开发方面的工程努力。
AIGC 先锋科技
2024/07/08
4000
清华提出 VoCo-LLaMA | 使用LLMs 进行视觉压缩,FLOPs 减少 94.8%,推理时间加快 69.6% !
仅缩小视觉Token位置编码间隔,轻松让多模态大模型理解百万Token!清华大学,香港大学,上海AI Lab新突破
本文共同一作为葛俊岐 (清华大学本科生),陈子熠 (清华大学本科生),林锦涛 (香港大学博士生),祝金国 (上海 AI Lab 青年研究员)。本文的通讯作者是朱锡洲,他的研究方向是视觉基础模型和多模态基础模型,代表作有 Deformable DETR、DCN v2 等。
机器之心
2025/02/03
990
仅缩小视觉Token位置编码间隔,轻松让多模态大模型理解百万Token!清华大学,香港大学,上海AI Lab新突破
李飞飞谢赛宁:多模态LLM「空间大脑」觉醒,惊现世界模型雏形!
更震撼的是,MLLM的空间推理能力虽然仍是瓶颈,但这些模型中,已经出现了局部世界模型和空间意识的迹象!
新智元
2025/02/15
1860
李飞飞谢赛宁:多模态LLM「空间大脑」觉醒,惊现世界模型雏形!
中科大 & 腾讯微信提出 EE-MLLM,一种数据高效和计算高效的多模大型语言模型!
近年来,由于在各种自然语言任务上的惊人表现,大型语言模型(LLM)受到了广泛关注。然而,实际场景往往涉及不仅仅是语言模态,因此将LLM扩展到多模态LLM至关重要。拓展的关键在于进行模态对齐,即学习将剩余模态以相同语义映射到预训练LLM特征空间的对应语言模态。
AIGC 先锋科技
2024/08/30
2910
中科大 & 腾讯微信提出 EE-MLLM,一种数据高效和计算高效的多模大型语言模型!
推荐阅读
​新加坡 & 纽约大学 & 字节 提出 PLLaVA | 简单高效视频语言模型适应方法,超越GPT4V,突破资源限制 !
5270
斯坦福大学 & 亚马逊 AI 探索视觉-语言模型的前沿,当前方法与未来方向的调查!
3810
中科大提出 ShareGPT4Video ,突破视频标注挑战,推动 LVLMs和 T2VMs 的发展!
4950
轻量级视频压缩(LVC):以最小成本迁移长视频理解能力,解决VLMs采样问题并提升多模型性能 !
1070
多榜单登顶!华为 &amp; 哈工深团队提出 AdaReTaKe,突破长视频理解极限
2500
每周AI论文速递(240722-240726)
1450
字节提出 LLaVA-OneVision :首个突破多模态模型性能瓶颈的开源大型模型 !
1.5K0
字节提出 MammothModa | 超越 LLaVA,集成视觉能力的多模态大型语言模型 !
3080
普林斯顿 & AWS & Apple 提出 RAVEN | 多任务检索增强视觉-语言模型框架,突破资源密集型预训练的限制 !
3640
中山大学 & 华为诺亚实验室提出 HiRes-LLaVA 框架,解决切片的高分辨率LVLM引起的输入碎片化问题 !
3620
英伟达 & MIT 提出 LongVILA ,从 8 帧到 1024 帧 如何实现长视频理解的飞跃 ?
5320
MiniGPT-Med | 多模态模型在医疗报告生成与疾病检测中取得突破性进展 !
8840
Cosmos-Reason1模型:借助层次化与二维本体实现物理AI推理,经四阶段训练及评估展现显著性能提升 !
1410
每周AI论文速递(241202-241206)
760
最强全模态模型Ola-7B横扫图像、视频、音频主流榜单,腾讯混元Research&清华&NTU联手打造
1200
清华 & 港中文 & 香港科技 深入探究 LLM, 利用大型语言模型理解视频和动作序列的多模态人类行为!
5850
清华提出 VoCo-LLaMA | 使用LLMs 进行视觉压缩,FLOPs 减少 94.8%,推理时间加快 69.6% !
4000
仅缩小视觉Token位置编码间隔,轻松让多模态大模型理解百万Token!清华大学,香港大学,上海AI Lab新突破
990
李飞飞谢赛宁:多模态LLM「空间大脑」觉醒,惊现世界模型雏形!
1860
中科大 & 腾讯微信提出 EE-MLLM,一种数据高效和计算高效的多模大型语言模型!
2910
相关推荐
​新加坡 & 纽约大学 & 字节 提出 PLLaVA | 简单高效视频语言模型适应方法,超越GPT4V,突破资源限制 !
更多 >
LV.1
这个人很懒,什么都没有留下~
目录
  • 前言
  • 正文
    • 1. Redis 数据库结构
    • 2. RDB 持久化
      • 2.1. RDB 的创建和载入
      • 2.1.1. 手动触发保存
      • 2.1.2. 自动触发保存
      • 2.1.3. 启动自动载入
      • 2.2. RDB 的文件结构
      • 2.2.1. 存储路径
      • 2.2.2. 文件格式
      • 2.3. RDB 常用的配置项
    • 3. AOF 持久化
      • 3.1. AOF 的创建和载入
      • 3.1.1. AOF 的创建
      • 3.1.2. AOF 的载入
      • 3.2. AOF 的执行流程
      • 3.2.1. 命令追加
      • 3.2.2. 文件写入和文件同步
      • 3.2.3. 文件重写
      • 3.3. AOF 常用的配置项
    • 4. 数据恢复机制
    • 5. RDB 和 AOF 对比
      • 5.1. RDB 的优缺点
      • 5.1.1. 优点
      • 5.1.2. 缺点
      • 5.2. AOF 的优缺点
      • 5.2.1. 优点
      • 5.2.2. 缺点
    • 6. RDB-AOF 混合持久化
    • 7. 持久化策略选择
      • 7.1. RDB 和 AOF 性能开销
      • 7.2. 持久化策略
      • 7.2.1. 数据库缓存
      • 7.2.2. 单机环境
      • 7.2.3. 主从部署
      • 7.2.4. 异地备灾
  • 小结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档