当前位置：首页 > article >正文

Redis 篇

article 2025/3/6 17:10:52

一、数据结构

二、持久化方式

Redis 提供了两种主要的持久化方式，分别是 RDB（Redis Database）和 AOF（Append Only File），此外，还可以同时使用这两种方式以增强数据安全性，以下为你详细介绍：

RDB（Redis Database）

原理

RDB 持久化是将 Redis 在某个时间点上的内存数据快照保存到磁盘上的一个二进制文件（.rdb 文件）。Redis 可以通过手动触发或者根据配置的规则自动触发 RDB 快照的生成。在 Redis 重启时，会读取这个 RDB 文件，将数据恢复到内存中。

触发方式

手动触发
- SAVE 命令：会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕，在此期间，服务器不能处理任何客户端请求。
- BGSAVE 命令：会派生出一个子进程来创建 RDB 文件，主进程可以继续处理客户端请求。子进程创建 RDB 文件完成后会向主进程发送信号。
自动触发
可以在 redis.conf 配置文件中设置自动触发的规则，例如：

save 900 1
save 300 10
save 60 10000

上述配置表示：在 900 秒内如果有 1 个 key 发生变化，或者 300 秒内有 10 个 key 发生变化，又或者 60 秒内有 10000 个 key 发生变化，就会自动触发 BGSAVE 操作。

优点

文件紧凑：RDB 文件是经过压缩的二进制文件，占用磁盘空间较小，便于备份和传输。
恢复速度快：加载 RDB 文件恢复数据时，只需将文件内容加载到内存，相比 AOF 方式恢复速度更快。
性能影响小：使用 BGSAVE 时，主进程可以继续处理客户端请求，对 Redis 性能影响较小。

缺点

数据丢失风险：由于是按一定时间间隔进行快照，两次快照之间若 Redis 发生故障，可能会丢失这段时间内的数据。
生成快照时的性能开销：fork 子进程会消耗系统资源，对于大型数据集，可能导致短暂性能下降。

AOF（Append Only File）

原理

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

配置方式

在 redis.conf 中通过 appendonly 参数开启 AOF 持久化：

appendonly yes

同时，可以通过 appendfsync 参数配置 AOF 文件的同步策略：

always：每次写操作都同步到磁盘，数据安全性最高，但会影响性能。
everysec：每秒同步一次，是一种兼顾性能和数据安全性的策略。
no：由操作系统决定何时同步，性能最好，但数据安全性最低。

优点

数据安全性高：可以最大程度保证数据完整性，即使 Redis 发生故障，最多丢失最近一次同步的数据。
可读性强：AOF 文件是文本文件，记录的是 Redis 执行的写命令，便于查看和分析。

缺点

文件体积大：随着写操作增加，AOF 文件会不断增大，占用较多磁盘空间。
恢复速度慢：重启时需要重新执行 AOF 文件中的所有命令，恢复时间可能较长。
性能影响：always 同步策略会对 Redis 性能产生一定影响。

混合持久化（RDB + AOF）

从 Redis 4.0 开始支持混合持久化方式。将 RDB 的文件格式和 AOF 的持久化策略结合起来。在 AOF 重写时，将内存中的数据以 RDB 的形式写入 AOF 文件的开头，之后的写操作再以 AOF 的方式追加到文件末尾。这样既保证了数据恢复速度（利用 RDB 部分），又提高了数据安全性（利用 AOF 部分记录后续操作）。

在 redis.conf 中通过以下配置开启混合持久化：