网站流量 次网络舆情监测中心

一、数据结构

二、持久化方式

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 中通过以下配置开启混合持久化：

aof-use-rdb-preamble yes

三、常用指令

1. 全表查询：keys

2. 分页查询：

3. 游标查询：

四、优化方式