本部分内容是关于博主在学习 Redis 时关于持久化部分的记录，介绍了 RDB 和 AOF 两种持久化方式，详细介绍了持久化的原理、配置、使用方式、优缺点和使用场景。并对两种持久化方式做了对比。文章最后介绍了 Redis 持久化的意义并与其他常见的缓存技术做了对比。本文来源有视频课程记录，有其他博主的博客，也有 AI 查询等等。
Redis 作为一个缓存组件，是否需要持久化功能？持久化的是什么？有什么意义？让我们根据这几个问题去了解 Redis 的持久化。
首先，Redis 是一个服务，是服务就会出现重启，崩溃和宕机的情况，持久化的方式可以确保数据在 Redis 服务器重启或崩溃后能够恢复。所以持久化的作用还是很重要的，是确保数据在服务重启后能够恢复的关键机制。
接着说第二个问题，持久化的数据是什么？在解释这个问题的时候就要涉及到 Redis 持久化的方式了，不同的方式持久化的数据有所不同，其意义和使用场景也不同。Redis 的两种主要持久化方式是 RDB（Redis Database） 和 AOF（Append Only File）。
一、RDB（Redis Database）
当选择使用 Redis 服务时，会默认选用一个方式进行持久化，这个方式一定是用于中小型项目体量，并且轻量化，易使用。RDB 就是 Redis 默认的持久化方式，它通过定期保存内存数据的快照到磁盘文件中，实现数据的持久化。
RDB 通过定期生成内存数据的快照（Snapshot）并将其保存到磁盘上的二进制文件中，实现数据的持久化。RDB 文件是一个压缩的二进制文件，默认命名为 dump.rdb，它记录了 Redis 在某一时刻的内存数据状态。即 RDB 文件是二进制格式，存储的是 Redis 当前数据集的快照。
工作原理：在 Redis 配置文件 redis.conf 中，可以通过 save 指令设置快照保存的触发条件。
- 手动触发：使用
SAVE（同步阻塞操作）或BGSAVE（通过 fork 创建子进程进行持久化，不阻塞主线程）命令。 - 自动触发：通过配置 save 参数（如
save 900 1，表示900秒内至少有1个键发生变化时自动保存快照）。
使用方式：在 Redis 配置文件中设置自动保存规则。
save 900 1 # 900秒内至少有1个键变化时保存快照
save 300 10 # 300秒内至少有10个键变化时保存快照
save 60 10000 # 60秒内至少有10000个键变化时保存快照
当触发条件满足时，Redis 会自动触发快照操作，会通过 fork 创建一个子进程，由子进程负责将当前内存中的数据写入到一个临时文件中。写入完成后，临时文件会替换之前的 RDB 文件。另外，RDB 文件以二进制格式存储，这种格式紧凑且加载速度快。
当 Redis 服务重启时，Redis 会加载 RDB 文件中的数据，将其恢复到内存中，从而恢复到上次快照时的状态。由于 RDB 文件是二进制格式且经过压缩，恢复速度较快，适合用于快速启动。
优点：
- 文件小：RDB 文件体积小，适合备份和全量复制。
- 恢复速度快：加载 RDB 文件恢复数据的速度非常快。
- 对性能影响小：通过子进程进行磁盘 I/O 操作，不会阻塞主线程。
缺点：
- 数据丢失风险：在两次快照之间，如果 Redis 服务器发生故障，可能会丢失部分数据。
- 快照操作可能阻塞：在数据量较大时，fork 子进程可能会导致短暂的阻塞。
适用场景：
- 数据备份：适合定期备份数据。
- 灾难恢复：快速恢复数据。
- 全量复制：用于 Redis 主从复制中的数据同步。
RDB 持久化通过定期生成内存数据的快照并保存到磁盘文件中，确保 Redis 服务重启后能够快速恢复数据。它适用于对数据丢失容忍度较高且需要快速恢复的场景。对于对数据安全性要求更高的场景，可以结合 AOF 持久化或使用混合持久化策略。
二、AOF（Append Only File）
如果该方式不是默认的话，说明该方式会应对大型项目，体量大。AOF 持久化通过记录每次写操作的命令到日志文件中，实现数据的持久化。AOF 文件是一个纯文本文件，记录了所有修改 Redis 数据的命令，格式与 Redis 的命令行协议一致。
使用方式：在 Redis 配置文件中启用 AOF 并设置同步策略。
appendonly yes
appendfsync everysec # 这表示启用 AOF 持久化，并每秒同步一次。
AOF 的工作原理可以分为以下几个步骤：
- 命令追加（Command Appending）：
- 每次执行写操作时，Redis 将命令追加到内存中的缓冲区 aof_buf。
- 缓冲区的内容会根据配置的同步策略写入到 AOF 文件中。
- 文件同步（File Syncing）：根据
appendfsync的配置，Redis 提供三种同步策略。- always：每次写操作后立即同步到磁盘，数据最安全，但性能开销最大。
- everysec：每秒同步一次，性能和数据安全性平衡。
- no：由操作系统决定同步时机，性能最高，但可能丢失更多数据。
- 文件重写（File Rewriting）：
- AOF 文件会随着操作的增加而变大，Redis 提供了 AOF 重写机制来压缩文件大小。
- 重写过程由
BGREWRITEAOF命令触发，Redis 会创建一个子进程，将当前内存中的数据以最小化的方式重写到一个新的 AOF 文件中。 - 自动重写可以通过配置
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size参数实现。
- 重启加载（Loading on Restart）：
- 当 Redis 重启时，会加载 AOF 文件中的命令并逐条执行，以恢复数据。
- 如果同时启用了 RDB 和 AOF，Redis 会优先加载 AOF 文件。
当 Redis 服务重启时，通过重放 AOF 文件中的命令，Redis 可以恢复到最近一次写操作的状态。即使在 Redis 服务崩溃时，AOF 也能保证数据的完整性，最多丢失最后一次同步前的数据，具有高数据安全性。
优点：
- 高数据安全性：AOF 提供了更高的数据安全性，尤其是在使用
everysec或always同步策略时。 - 可读性高：AOF 文件是文本格式，记录了实际的 Redis 命令，便于阅读和分析。
- 支持修复工具：如果 AOF 文件损坏，可以使用
redis-check-aof工具进行修复。 - 灵活的同步策略：用户可以根据需求选择不同的同步策略，平衡性能和数据安全性。
缺点：
- 文件较大：AOF 文件记录了所有写操作，文件体积通常比 RDB 文件大。
- 恢复速度慢：恢复数据时需要逐条重放命令，速度较慢。
- 性能开销：高频磁盘写入可能影响 Redis 的写入性能。
适用场景
- 高数据安全性：适用于对数据丢失容忍度低的场景，如金融系统、订单系统。
- 写操作频繁：适合写操作频繁且需要实时持久化的场景。
- 调试和审计：AOF 文件记录了详细的命令日志，便于开发和测试中的调试。
AOF 持久化通过记录每个写操作的命令，提供了高数据安全性和灵活性。它适用于对数据丢失敏感的场景，但可能会带来较大的文件体积和恢复速度较慢的问题。在实际应用中，AOF 可以与 RDB 混合使用，以兼顾数据安全性和恢复速度。
三、汇总
| 持久化方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| RDB | 文件小、恢复速度快、对性能影响小 | 数据丢失风险、快照操作可能阻塞 | 数据备份、灾难恢复、全量复制 |
| AOF | 数据安全性高、文件可读性强、支持修复 | 文件较大、恢复速度慢、性能开销 | 数据安全性要求高、误操作恢复 |
如果需要高数据安全性，建议使用 AOF；如果需要快速恢复和较小的磁盘占用，建议使用 RDB。
四、Redis 对比其他缓存技术
Redis 的持久化功能是其作为缓存系统的一个重要特性，相比其他缓存技术（如 Memcached、Guava Cache、Caffeine 等），Redis 的持久化功能在某些场景下具有显著优势。
Redis 的持久化功能具有以下优势。
- 数据持久化：Redis 提供了两种主要的持久化方式：RDB（快照）和 AOF（追加文件），以及混合持久化（RDB + AOF）。这些持久化方式确保了数据在 Redis 服务器重启或崩溃后能够恢复。相比之下，Memcached 和 Guava Cache 等缓存技术不支持持久化，数据在重启后会丢失。
- 高数据安全性：AOF 持久化通过记录每个写操作，确保即使在 Redis 崩溃时，也能恢复到非常接近崩溃时的状态。这种高数据安全性使得 Redis 在金融、交易系统等对数据完整性要求极高的场景中具有明显优势。
- 快速恢复：RDB 持久化通过快照文件快速恢复数据，适合需要快速启动的场景。混合持久化（RDB + AOF）结合了两者的优点，既保证了数据的完整性，又提高了恢复速度。
- 灵活的配置：Redis 允许用户根据需求选择不同的持久化策略。例如，AOF 的
appendfsync参数可以设置为always、everysec或no，以平衡数据安全性和性能。
Redis 的持久化功能存在一定的开销。
- 性能开销：AOF 持久化需要频繁写入磁盘，可能会影响 Redis 的写入性能。
- 文件大小：AOF 文件通常比 RDB 文件大，尤其是在写操作频繁的情况下。
- 恢复速度：AOF 恢复数据时需要重放所有命令，速度较慢。
Redis 与 Memcached 对比：
- 持久化：Redis 支持持久化，而 Memcached 不支持。
- 数据结构：Redis 支持多种数据结构（如字符串、哈希、列表、集合等），而 Memcached 仅支持简单的键值对。
- 适用场景：Redis 适合需要持久化和复杂数据结构的场景，而 Memcached 更适合简单的缓存需求。
Redis 与 Guava Cache/Caffeine 对比：
- 本地缓存 vs 分布式缓存：Guava Cache 和 Caffeine 是本地缓存，不支持分布式。Redis 是分布式缓存，支持多节点共享数据。
- 持久化：Guava Cache 和 Caffeine 不支持持久化。
- 适用场景：对于单机应用，Guava Cache 或 Caffeine 是高性能的选择；对于分布式系统，Redis 是更好的选择。
各种缓存技术的使用场景：
- Redis：适用于需要高可用性、数据持久化和复杂数据结构的场景，如分布式系统、电商系统、实时数据处理等。
- Memcached：适用于简单的缓存需求，如网页缓存。
- Guava Cache/Caffeine：适用于单机应用，尤其是需要高性能本地缓存的场景。
Redis 的持久化功能使其在需要数据安全性和高可用性的场景中具有显著优势，但这种优势也带来了性能开销和文件大小的增加。在选择缓存技术时，应根据具体需求权衡数据安全性、性能和成本。对于分布式系统和复杂数据结构的需求，Redis 是更优的选择。