持久化

摘要：本文介绍了Redis的持久化机制，包括RDB和AOF两种方式。

1 概述

持久化是指将内存中的数据保存到磁盘上，以防止数据丢失。Redis是一个内存数据库，默认情况下，数据只存储在内存中，一旦Redis服务停止，数据就会丢失。因此，Redis提供了持久化机制，将数据保存到磁盘上，以便在服务重启后能够恢复数据。

Redis提供了两种持久化方式：

1. RDB（Redis Database）：将内存中的数据快照写入磁盘。
2. AOF（Append Only File）：将所有写操作命令追加到文件中。

2 方式

2.1 RDB

2.1.1 说明

RDB是Redis默认的持久化方式，它会在指定的时间间隔内生成内存数据的快照，并将其保存到磁盘上。

2.1.2 工作原理

工作原理：

1. Redis主进程会Fork一个子进程。
2. 操作系统利用写时复制技术，父子进程共享同一块物理内存页。
3. 主进程继续处理命令，不阻塞写入操作。
4. 子进程将Fork执行时的数据写入临时文件。
5. 写入完成后，子进程会用临时文件替换原有的RDB文件。
6. 子进程退出，释放资源。

2.1.3 优缺点

优点：

• 文件体积小：RDB文件是压缩的二进制文件，体积较小。
• 恢复速度快：RDB文件是快照，恢复时直接加载到内存，速度快。
• 适合备份：可以定期生成RDB文件，用于备份。

缺点：

• 数据丢失风险：如果Redis在两次快照之间崩溃，会丢失这段时间内的数据。
• Fork开销：生成快照时需要Fork子进程，会占用一定的内存和CPU资源。

2.1.4 相关配置

2.1.4.1 保存规则

语法：

1

save 秒数 变更次数 ... 秒数 变更次数

当经过指定的秒数且数据库的写操作次数达到指定变更次数时，将会触发保存数据库的操作。

默认情况将按以下规则保存数据库：

• 3600秒后，如果至少有1次变更
• 300秒后，如果至少有100次变更
• 60秒后，如果至少有10000次变更

默认配置：

1

save 3600 1 300 100 60 10000

2.1.4.2 错误处理

当RDB持久化出错时，是否停止写入操作，以确保数据不丢失。

默认配置，出错时停止写入操作：

1

stop-writes-on-bgsave-error yes

2.1.4.3 压缩文件

启用压缩可以减少RDB文件的体积，提高恢复速度。

默认配置，启用压缩：

1

rdbcompression yes

2.1.4.4 校验文件

启用校验可以确保RDB文件的完整性，防止数据损坏。

默认配置，启用校验：

1

rdbchecksum yes

2.1.4.5 文件名称

默认配置：

1

dbfilename dump.rdb

2.1.4.6 删除文件

在不需要持久化（既不使用RDB方式也不使用AOF方式）的服务器上，可以设置删除主从复制产生的RDB文件，防止磁盘残留数据。

默认配置，不删除RDB文件：

1

rdb-del-sync-files no

2.1.4.7 保存目录

默认配置：

1

dir ./

一般来说，为了数据安全，往往会将RDB文件保存到另一台服务器。

2.1.5 触发逻辑

支持多种触发条件：

• 达到配置文件中的配置条件后会自动触发，保存新的快照。
• 手动执行SAVE命令，主线程立即执行，同时阻塞所有客户端请求直到快照完成。
• 手动执行BGSAVE命令，会启用Fork子进程在后台异步生成快照，主进程继续处理命令。
• 手动执行FLUSH命令后也会保存新的快照，但此时快照是空的，没有数据。
• 手动执行SHUTDOWN命令，并且没有开启AOF持久化时，会保存当前数据集的快照。
• 主从复制时，主节点会自动触发保存快照，以确保数据同步。

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

2.1.6 数据恢复

将备份生成的RDB文件移动到指定文件目录，重新启动Redis服务时会自动加载文件进行恢复。

2.1.7 文件修复

使用redis-check-rdb工具检查RDB文件是否损坏，但是不支持修复损坏文件。

检查RDB文件：

1

redis-check-rdb dump.rdb

如果文件发生损坏，只能打开文件手动修复。

2.2 AOF

2.2.1 说明

AOF持久化是将所有写操作命令追加到AOF文件中，当Redis重启时，会重新执行AOF文件中的命令来恢复数据。

AOF持久化的优先级高于RDB持久化的优先级，同时开启的情况下，使用AOF文件恢复数据。

2.2.2 工作原理

工作原理：

1. 所有写操作命令都会被追加到AOF缓冲区。
2. 根据配置的同步策略，将缓冲区中的命令同步到AOF文件。
3. 当AOF文件过大时，会触发AOF重写，压缩AOF文件。

2.2.3 优缺点

优点：

• 数据安全性高：可以配置不同的同步策略，确保数据不丢失。
• 文件可读性强：AOF文件是文本文件，记录了所有写操作命令，可读性强。

缺点：

• 文件体积大：AOF文件记录了所有写操作命令，体积较大。
• 恢复速度慢：恢复时需要重新执行所有命令，速度较慢。
• 重写开销：AOF重写时需要Fork子进程，会占用一定的内存和CPU资源。

2.2.4 相关配置

2.2.4.1 开启配置

默认情况下是关闭的，需要手动开启。

开启AOF持久化：

1

appendonly yes

2.2.4.2 文件名称

默认配置：

1

appendfilename "appendonly.aof"

在7.0版本以后，文件名称仅作为基础名称，主要有两种基本类型：

• 基础文件，文件创建时数据集完整状态的快照，支持RDB格式和AOF格式。
• 增量文件，包含在前一个文件之后作用于数据集的额外命令，仅支持AOF格式。

此外，还会通过清单文件追踪这些文件及其创建顺序和应被应用的次序。

2.2.4.3 保存目录

默认配置：

1

appenddirname "appendonlydir"

2.2.4.4 同步策略

用于设置如何将缓冲区中的命令同步到磁盘文件中，支持三种策略：

• no：由操作系统决定何时同步，性能最高，但安全性最低。
• always：每次写操作都同步，安全性最高，但性能最低。
• everysec：每秒同步一次，性能和安全性平衡，默认策略。

默认配置，每秒同步一次：

1

appendfsync everysec

2.2.4.5 阻塞策略

当同步策略不是no时，为了保证数据安全，在同步过程中会阻塞写操作，直到同步完成。

为了平衡性能和安全，支持设置阻塞策略：

• 设置为no时表示安全至上，同步过程中会阻塞写操作，直到同步完成。
• 设置为yes时表示性能至上，同步过程中不会阻塞写操作，等到空闲时执行同步，极端情况下最多丢失30秒的写操作。

建议默认安全至上，只有当发现明显卡顿时才考虑设置为性能至上。

默认配置，安全至上：

1

no-appendfsync-on-rewrite no

2.2.4.6 重写策略

当文件过大时，会触发AOF重写，压缩AOF文件，需要同时满足的条件：

1. 文件大小需要超过上次重写文件大小的指定百分比。
2. 文件大小需要超过指定大小。

默认配置：

1
2

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

将百分比设置为0表示禁止重写功能。

2.2.4.7 损坏处理

当遇到极端情况导致文件不能正常记录，产生损坏文件时，支持设置处理损坏文件的方式：

• 设置为yes表示忽略错误，继续加载损坏文件，服务器会启动并记录一条日志以告知用户这一事件。
• 设置为no表示停止启动，服务器将报错中止并拒绝启动。

默认配置，忽略错误：

1

aof-load-truncated yes

2.2.4.8 初始格式

在创建文件时，支持设置基础文件的格式：

• 设置为yes表示使用RDB格式，基础文件后缀为.base.rdb格式。
• 设置为no表示使用AOF格式，基础文件后缀为.base.aof格式。

默认配置，使用RDB格式：

1

aof-use-rdb-preamble yes

2.2.4.9 记录时间

支持在文件中记录时间戳，会改变AOF格式，可能导致与现有AOF解析器不兼容。

默认配置，不记录时间戳：

1

aof-timestamp-enabled no

2.2.5 触发重写

支持多种触发条件：

• 达到配置文件中的配置条件后会自动触发。
• 手动执行BGREWRITEAOF命令，会启用Fork子进程重写并替换文件。

2.2.6 数据恢复

将备份生成的多个AOF文件移动到指定文件目录，重新启动Redis服务时会自动加载文件进行恢复。

2.2.7 文件修复

使用redis-check-aof工具检查AOF文件是否损坏，并且支持修复损坏文件。

检查AOF文件：

1

redis-check-aof 文件清单

修复AOF文件：

1

redis-check-aof --fix 文件清单

只能修复末尾损坏的文件，如果文件中间损坏，只能打开文件手动修复。

3 迁移

默认情况下，没有开启AOF持久化，需要修改配置文件并重启服务。

在没有数据的情况下可以这么操作，但是在已经有数据的情况下，这么做会导致数据丢失：

1. 重启服务时，优先加载AOF文件。
2. 如果AOF文件不存在，会创建空文件并加载，导致数据丢失。

在已有数据的情况下，建议按照以下步骤进行：

1. 手动执行CONFIG SET appendonly yes命令，动态开启AOF持久化。
2. 手动执行BGREWRITEAOF命令，触发AOF重写。
3. 修改配置文件，修改appendonly yes配置，永久开启AOF持久化。
4. 重新启动Redis服务。

4 最佳实践

根据业务需求选择持久化方式：

• 如果对数据安全性要求较高，建议使用AOF。
• 如果对恢复速度要求较高，建议使用RDB。

合理配置持久化参数：

• RDB：根据业务量调整保存条件，避免过于频繁的快照。
• AOF：选择合适的同步策略，平衡性能和安全性。

定期备份持久化文件，将RDB或AOF文件复制到其他服务器，以防止服务器故障导致数据丢失。

定期监控持久化状态，检查持久化是否正常，避免因持久化失败导致数据丢失。