一、数据结构
二、持久化方式
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三、常用指令
-
全表查询：keys
-
分页查询：
-
游标查询：
