#作者：朱雷
文章目录
- 1、Redis 如何将数据写入磁盘
- 1.1.RDB 优势
- 1.2.RDB 的缺点
- 1.3.AOF 优点
- 1.4.AOF 缺点
- 2、持久化原理
- 2.1. RDB快照
- 2.2. AOF仅追加文件
- 3、那么我们应该使用什么？
1、Redis 如何将数据写入磁盘
持久化是指将数据写入持久化存储。Redis 提供了一系列持久化选项，包括：
- RDB（Redis 数据库）：RDB 持久性以指定的时间间隔对数据集执行时间点快照。
- AOF（仅追加文件）：AOF 持久化机制会记录服务器收到的每个写入操作。这些操作可以在服务器启动时重放，从而重建原始数据集。命令的记录格式与 Redis 协议本身的格式相同。
- 无持久性：您可以完全禁用持久性。这仅在使用redis作为纯缓存时使用。
- RDB + AOF：您还可以在同一个实例中结合使用 AOF 和 RDB。
1.1.RDB 优势
- RDB 是 Redis 数据的一个非常紧凑的单文件时间点表示。RDB 文件非常适合备份。例如，您可能希望每小时存档最近 24 小时内的 RDB 文件，并每天保存一个 RDB 快照，持续 30 天。这样，您可以在发生灾难时轻松恢复数据集的不同版本。
- RDB 非常适合灾难恢复，它是一个可以传输到远处数据中心的单个紧凑文件。
- RDB 最大化了 Redis 的性能，因为 Redis 父进程为了持久化唯一需要做的就是 fork 一个子进程，然后由子进程完成剩下的所有工作。父进程永远不会执行磁盘 I/O 或类似的操作。
- 与 AOF 相比，RDB 允许使用大数据集更快地重启。
- 在副本上，RDB 支持重启和故障转移后的部分重新同步。
1.2.RDB 的缺点
- 如果您需要最大程度地降低 Redis 停止工作（例如断电后）时数据丢失的风险，那么 RDB 并不理想。您可以配置不同的保存点来生成 RDB，例如，在五分钟后对数据集进行 100 次写入后，生成保存点快照。如果 Redis 因任何原因未正确关闭而停止工作，您应该做好丢失最新几分钟数据的准备。
- RDB 需要频繁地 fork() 才能使用子进程将数据持久化到磁盘。如果数据集很大，fork() 可能会非常耗时，如果数据集很大且 CPU 性能不佳，可能会导致 Redis 停止服务客户端几毫秒甚至一秒钟。AOF 也需要 fork()，但频率较低，您可以调整重写日志的频率，而不会影响持久性。
1.3.AOF 优点
- 使用 AOF Redis 的持久性更强：你可以设置不同的 fsync 策略：完全不 fsync、每秒 fsync 或每次执行时 fsync。使用默认的每秒 fsync 策略，写入性能仍然非常出色。fsync 由后台线程执行，当没有 fsync 正在进行时，主线程会尽力执行写入操作，因此你只会损失一秒钟的写入数据。
- AOF 日志是仅追加日志
- 当 AOF 文件过大时，Redis 能够在后台自动重写。重写过程非常安全，因为 Redis 在继续向旧文件追加数据的同时，会使用创建当前数据集所需的最少操作生成一个全新的 AOF 文件。一旦第二个文件准备就绪，Redis 就会切换两个 AOF 文件，并开始向新文件追加数据。
- AOF 以易于理解和解析的格式逐一记录所有操作的日志。
1.4.AOF 缺点
- 对于同一数据集，AOF 文件通常比等效的 RDB 文件更大。
- AOF 的速度可能比 RDB 慢，具体取决于具体的 fsync 策略。通常，将 fsync 设置为每秒一次时，性能仍然非常高；而禁用 fsync 后，即使在高负载下，AOF 的速度也应该与 RDB 一样快。
2、持久化原理
以下部分将详细说明这两种持久性模型。
2.1. RDB快照
工作原理：
每当 Redis 需要将数据集转储到磁盘时，就会发生以下情况：
- Redis fork。我们现在有一个子进程和一个父进程。
- 子进程开始将数据集写入临时 RDB 文件。
- 当子进程完成写入新的 RDB 文件时，它将替换旧的 RDB 文件。
2.2. AOF仅追加文件
快照的持久性并不理想。如果运行 Redis 的计算机停止运行、线路故障或您意外关闭了kill -9实例，写入 Redis 的最新数据就会丢失。虽然对于某些应用程序来说，这可能不是什么大问题，但在某些情况下需要完全持久性，而在这些情况下，仅使用 Redis 快照并不可行。
工作原理：
仅追加文件是Redis 的另一种完全持久化策略，每次 Redis 收到更改数据集的命令（例如SET），它都会将其附加到 AOF 文件中。
可以配置 Redis 将数据写入磁盘的次数 fsync。共有三个选项：
- appendfsync always：fsync每次新命令都会被追加到 AOF 文件。速度非常慢，但非常安全。
- appendfsync everysec：fsync每秒一次。速度足够快（自 2.4 版本以来可能与快照一样快），如果发生灾难，您可能会丢失 1 秒的数据。
- appendfsync no：永远不要fsync，直接把你的数据交给操作系统。这种方法更快，但更不安全。通常情况下，Linux 会在此配置下每 30 秒刷新一次数据，但具体情况取决于内核的具体调整。
建议（也是默认）的策略是fsync每秒执行一次。它既快速又相对安全。该always策略在实际应用中速度很慢，但它支持组提交，因此如果有多个并行写入，Redis 会尝试执行单个fsync操作。
3、那么我们应该使用什么？
- 一般情况下，如果您想要获得与 PostgreSQL 所能提供的相当的数据安全程度，那么您应该同时使用这两种持久性方法。
- 如果您非常关心您的数据，但在发生灾难时仍然可以忍受几分钟的数据丢失，那么您可以单独使用 RDB+备份策略。
- 有很多用户单独使用 AOF，但我们不鼓励这样做，因为不时地进行 RDB 快照对于进行数据库备份、更快地重启以及在 AOF 引擎出现错误时是一个好主意。
- 使用redis作为纯缓存场景：
- 建议关闭RDB / AOF持久化功能。
- 使用脚本定期执行RDB备份命令，以实现数据备份冗余。
- 存储介质的选择建议：
- 优先使用本地SSD磁盘存放RDB和AOF文件，充分利用本地I/O的高性能与低延迟特性规避网络延迟风险。
- 在高并发或写多读少场景下，避免使用NFS / Ceph等依赖网络性能作为持久化存储介质。下图是官方警告说明。
