2. 深入解读 Redis 的两种持久化方式

博客地址：blog.zysicyj.top

Redis 为什么要引入持久化机制

Redis 引入持久化机制是为了解决内存数据库的数据安全性和可靠性问题。虽然内存数据库具有高速读写的优势，但由于数据存储在内存中，一旦服务器停止或崩溃，所有数据将会丢失。持久化机制的引入旨在将内存中的数据持久化到磁盘上，从而在服务器重启后能够恢复数据，提供更好的数据保护和可靠性。

以下是持久化机制的几个主要原因：

1. 数据安全和可靠性：
通过将数据持久化到磁盘上，即使在服务器崩溃或异常停止的情况下，也可以保证数据不会丢失。持久化机制可以防止重要的数据在突发情况下遭受损失。

2. 数据恢复：
持久化机制允许在服务器重启后将数据重新加载到内存中，从而实现数据的恢复。这对于业务的连续性和可用性非常重要。

3. 数据灾难恢复：
持久化机制对于灾难恢复也很有帮助。在不幸发生硬件故障、电力中断等情况下，持久化机制可以帮助恢复数据。

4. 数据迁移：
持久化机制也有助于将数据从一个服务器迁移到另一个服务器。你可以通过备份持久化文件并在另一台服务器上进行恢复来完成数据迁移。

虽然持久化机制带来了磁盘 IO 和性能开销，但它为 Redis 提供了更强大的数据保护能力。根据应用的需求，可以根据数据的重要性和数据丢失的容忍度来选择适当的持久化方式，或者结合两种方式以提供更高的数据保护级别。

Redis 提供了哪些持久化机制

Redis 提供了两种主要的持久化机制，分别是 RDB 快照（Snapshotting）和 AOF 日志（Append-Only File）。这两种机制可以根据不同的需求和场景来选择使用。

1. RDB 快照（Snapshotting）：
RDB 快照是一种全量持久化方式，它会周期性地将内存中的数据以二进制格式保存到磁盘上的 RDB 文件。RDB 文件是一个经过压缩的二进制文件，包含了数据库在某个时间点的数据快照。RDB 快照有助于实现紧凑的数据存储，适合用于备份和恢复。

优点：

  • RDB 快照在恢复大数据集时速度较快，因为它是全量的数据快照。
  • 由于 RDB 文件是压缩的二进制文件，它在磁盘上的存储空间相对较小。
  • 适用于数据备份和灾难恢复。

缺点：

  • RDB 快照是周期性的全量持久化，可能导致某个时间点之后的数据丢失。
  • 在保存快照时，Redis 服务器会阻塞，可能对系统性能造成影响。

2. AOF 日志（Append-Only File）：
AOF 日志是一种追加式持久化方式，它记录了每个写操作命令，以追加的方式将命令写入 AOF 文件。通过重新执行 AOF 文件中的命令，可以重建出数据在内存中的状态。AOF 日志提供了更精确的持久化，适用于需要更高数据安全性和实时性的场景。

优点：

  • AOF 日志可以实现更精确的数据持久化，每个写操作都会被记录。
  • 在 AOF 文件中，数据可以更好地恢复，因为它保存了所有的写操作历史。
  • AOF 日志适用于需要实时恢复数据的场景，如秒级数据恢复要求。

缺点：

  • AOF 日志相对于 RDB 快照来说，可能会占用更多的磁盘空间，因为它是记录每个写操作的文本文件。
  • AOF 日志在恢复大数据集时可能会比 RDB 快照慢，因为需要逐条执行写操作。

根据不同的需求，可以选择 RDB 快照、AOF 日志或两者结合使用。你可以根据数据的重要性、恢复速度要求以及磁盘空间限制来选择合适的持久化方式。有时候，也可以通过同时使用两种方式来提供更高的数据保护级别。

AOF 日志是如何实现的

首先，大家要知道，AOF 是写后日志，“写后”的意思是 Redis 先执行命令，把数据写入内存，然后才记录日志，如下图所示：
Redis AOF 操作过程

AOF 为什么要先执行命令再记日志呢

AOF（Append-Only File）持久化机制中，为什么要先执行命令再记录日志，而不是相反，这涉及到数据的一致性和持久性。

AOF 的设计目标之一是保证数据的持久性，即在服务器重启后能够恢复出与重启前一致的数据状态。为了实现这个目标，AOF 的操作顺序非常重要。

先执行命令再记录日志的原因：

  1. 数据一致性： 如果先记录日志再执行命令，假设记录日志成功而执行命令失败（例如服务器崩溃），那么日志中记录的操作实际上没有被应用，会导致数据在重启后与预期不一致。

  2. 可恢复性： 先执行命令再记录日志可以保证在服务器重启后，即使在崩溃前未能将操作记录到日志中，也可以通过重新执行 AOF 日志中的命令，将数据恢复到正确的状态。

  3. 避免日志丢失： 如果先记录日志再执行命令，如果在记录日志之前发生了服务器崩溃，会导致操作丢失，而这些操作可能已经影响了数据的一致性。

当然，这里面还有一个非常重要的原因，它是在命令执行后才记录日志，所以不会阻塞当前的写操作。

因此，为了确保数据的持久性和一致性，Redis 选择了先执行命令再记录日志的方式。这样可以保证只有在操作真正成功执行后，才会将操作记录到 AOF 日志中，从而在服务器重启后能够准确地重放这些操作，保持数据的正确性。

AOF 日志里面记录了什么内容呢

AOF（Append-Only File）日志记录了每个写操作命令，以追加的方式将命令写入 AOF 文件。这些写操作命令被以一种协议格式（通常是 RESP 协议）写入 AOF 文件，以文本形式保存。下面是 AOF 日志中记录的内容示例：

假设执行了以下操作：

1
2
3
SET key1 value1
INCR key2
LPUSH list1 item1

对应的 AOF 日志内容可能是：

1
2
3
*3\r\n$3\r\nSET\r\n$4\r\nkey1\r\n$6\r\nvalue1\r\n
*2\r\n$4\r\nINCR\r\n$4\r\nkey2\r\n
*3\r\n$5\r\nLPUSH\r\n$5\r\nlist1\r\n$5\r\nitem1\r\n

在这个示例中，每个写操作都以 RESP 协议格式记录在 AOF 文件中，以一系列字节数组来表示命令和参数。每个写操作的记录由多行组成，以 \r\n 分隔。

  • *3：表示命令参数的个数为 3。
  • $3\r\nSET\r\n：表示第一个参数为长度为 3 的字符串 “SET”。
  • $4\r\nkey1\r\n：表示第二个参数为长度为 4 的字符串 “key1”。
  • $6\r\nvalue1\r\n：表示第三个参数为长度为 6 的字符串 “value1”。

这样的记录方式允许在 AOF 文件中按照操作的顺序逐条重放写操作命令，从而实现数据在服务器重启后的恢复。由于 AOF 记录的是写操作命令本身，所以在执行 AOF 文件中的命令时，可以完全还原数据的状态。

AOF 日志潜在的问题

AOF（Append-Only File）写日志是 Redis 的持久化机制之一，它记录了每个写操作命令，以追加的方式将命令写入 AOF 文件。尽管 AOF 具有许多优点，但也存在一些风险和潜在的问题，需要注意和管理：

1. 磁盘 IO 开销：
AOF 日志以追加写入方式工作，每次写入操作都会直接追加到 AOF 文件末尾。这意味着频繁的写入操作可能会导致磁盘 IO 开销增加，可能会影响系统的性能和响应时间。

2. 磁盘空间占用：
AOF 日志记录的是每个写操作命令本身，相比于 RDB 快照，AOF 文件可能会更大。如果写入操作频繁，AOF 文件可能会不断增大，占用过多的磁盘空间。

3. 数据一致性：
尽管 AOF 的先执行命令再记录日志的机制保证了数据一致性，但如果在记录日志前发生服务器崩溃，尚未记录的操作可能会丢失，可能导致数据一致性问题。

4. AOF 文件损坏：
由于 AOF 文件是以文本格式记录的命令，如果 AOF 文件在写入或存储过程中受到损坏，可能导致数据恢复时出现问题，甚至无法正确恢复数据。

5. AOF 重写耗时：
AOF 重写是为了减小 AOF 文件的大小，但它是一个耗时的操作，可能会对系统性能产生影响，尤其是在大数据集的情况下。

6. AOF 重写可能引发的问题：
AOF 重写过程中可能会因为各种原因导致数据丢失，例如中断的重写过程、文件系统问题等。在执行 AOF 重写时，需要谨慎对待，确保数据的完整性。

7. AOF 文件合并：
在一些场景下，可能需要将多个 AOF 文件合并成一个，这样的操作需要小心处理，以避免数据丢失或错误。

8. 硬件故障：
虽然 AOF 可以提供持久性保证，但硬件故障（例如磁盘故障）可能会导致 AOF 文件丢失或损坏，需要适当的备份和恢复策略。

为了减轻 AOF 写日志带来的风险，可以采取一些措施，如选择适当的 AOF 同步策略、定期备份 AOF 文件、监控 AOF 文件的大小和状态、定期执行 AOF 重写、备份数据等。这些策略可以帮助减少潜在的问题，并提高系统的可靠性。

AOF 日志三种写回策略

AOF（Append-Only
File）持久化机制在 Redis 中有三种不同的写回（sync）策略，用于控制何时将 AOF 缓冲区中的写入操作刷新到磁盘上的 AOF 文件。这些策略决定了 AOF 日志的同步频率，影响了数据的持久性和性能。以下是这三种写回策略：

1. always（始终同步）：
在这个策略下，每次执行写入操作之后，Redis 都会立即将写入操作刷新到磁盘，确保写入操作已经持久化。虽然这种方式能够提供最高的数据保证，但也是性能开销最大的一种方式，因为每次写入操作都会引起磁盘 IO。

优点：

  • 最高的数据保证，即使系统崩溃，也只会丢失上一个写入操作。

缺点：

  • 性能开销较大，频繁的磁盘 IO 可能影响系统的性能和响应时间。

2. everysec（每秒同步）：
在这个策略下，Redis 会每秒一次将 AOF 缓冲区中的写入操作批量刷新到磁盘上的 AOF 文件。这样可以在一定程度上平衡数据保证和性能。

优点：

  • 较高的数据保证，每秒一次的同步保证了不会丢失过多的写入操作。
  • 性能开销相对较低，因为是每秒一次的批量刷新。

缺点：

  • 在一秒内的操作可能会丢失。

3. no（不同步）：
这个策略下，Redis 不会主动将 AOF 缓冲区中的写入操作刷新到磁盘，而是由操作系统来决定何时将数据写入磁盘。这是性能开销最小的方式，但数据持久性相对较低。

优点：

  • 最小的性能开销，几乎不会影响系统的响应时间。
  • 最高的性能表现，写入操作不会导致频繁的磁盘 IO。

缺点：

  • 数据持久性较低，如果系统崩溃，可能会丢失多个写入操作。

选择合适的 AOF 写回策略取决于数据的重要性和性能需求。如果数据安全性最为重要，可以选择 always
策略。如果在数据一致性和性能之间需要平衡，可以选择 everysec
策略。如果对性能要求较高，而可以接受一定程度的数据丢失，可以选择 no 策略。根据实际情况，可以根据需求来配置 AOF 的写回策略。

这里呢给大家总结一下各种配置的优缺点

日志文件太大了怎么办

AOF（Append-Only
File）重写是为了减小 AOF 文件的大小，避免 AOF 文件不断增大导致的磁盘空间占用问题。AOF 重写是一种以全量的方式生成新的 AOF 文件，其中记录的是一个数据集的写入操作，这个数据集的大小通常比原始 AOF 文件小很多。

AOF 重写的工作原理如下：

  1. 触发重写：
    AOF 重写可以手动触发，也可以根据配置自动触发。当满足一定条件（例如 AOF 文件大小超过指定百分比或最小大小）时，Redis 会启动 AOF 重写过程。

  2. 后台进程启动：
    当 AOF 重写触发时，Redis 会启动一个子进程，这个子进程会负责执行 AOF 重写操作。

  3. 创建数据集快照：
    在子进程中，Redis 会创建一个数据集的内存快照，即内存中数据在某个时间点的快照。

  4. 遍历数据集：
    子进程开始遍历数据集中的键，并将写操作转换成命令序列。

  5. 生成新 AOF 文件：
    子进程会将遍历期间生成的命令序列追加到新的 AOF 文件中，这个新文件是紧凑的，只包含了数据集在某个时间点的写入操作。

  6. 替换原 AOF 文件：
    当新的 AOF 文件生成完成后，子进程会将原始的 AOF 文件替换为新的 AOF 文件。这一步通常很快，因为新的 AOF 文件相对较小。

  7. 主线程继续服务：
    在 AOF 重写过程中，主线程仍然可以继续处理客户端请求，响应读取操作等，不会被阻塞。

AOF 重写的优势在于它可以生成一个更小、更紧凑的 AOF 文件，避免了不断增大的 AOF 文件所带来的磁盘空间和读写开销。此外，新的 AOF 文件只包含了写入操作，没有之前的读操作，因此它在恢复数据时不需要考虑之前的读操作。

AOF 重写可以通过多种方式触发：

  • 手动触发：可以使用 BGREWRITEAOF 命令手动触发 AOF 重写。
  • 自动触发：可以通过设置 auto-aof-rewrite-percentage 和auto-aof-rewrite-min-size
    来自动触发 AOF 重写。当 AOF 文件大小达到指定的百分比或最小大小时，Redis 会自动启动 AOF 重写。

需要注意的是，AOF 重写是一个资源密集型操作，可能会影响系统的性能，特别是在大数据集的情况下。因此，在进行 AOF 重写时，应该考虑其对系统性能的影响，并确保系统具备足够的资源来执行重写操作。
下面举例说明一下：
AOF 重写减少文件大小
这里大家能看到，经过优化后，AOF 日志文件会缩小很多，但是，要把整个数据库的最新数据的操作日志都写回磁盘，仍然是一个非常耗时的过程。这时，我们就要继续关注另一个问题了。

重写会不会阻塞主线程？

AOF 重写不会阻塞 Redis 的主线程。Redis 的 AOF 重写是作为一个后台进程（子进程）来执行的，不会影响主要的服务线程。

AOF 重写过程中，Redis 会创建一个子进程来遍历数据集，将写操作转换为命令序列，并生成新的 AOF 文件。主线程仍然可以继续处理客户端请求，响应读取操作等。

这种设计使得 Redis 能够在不中断服务的情况下执行 AOF 重写，从而减少对系统的影响。但需要注意的是，虽然 AOF 重写不会阻塞主线程，但它仍然是一个资源密集型操作，可能会占用较多的 CPU 和内存资源，因此在进行 AOF 重写时，需要考虑系统的资源情况，避免影响其他业务操作。

RDB 快照是如何实现的？

RDB（Redis
DataBase）是 Redis 的一种持久化机制，用于将数据从内存中保存到磁盘上，以便在服务器重启时恢复数据。RDB 通过创建一个快照（Snapshot）来保存数据库在某个时间点的数据状态，然后将这个快照保存到磁盘上的一个二进制文件中。

RDB 的实现过程：

  1. 创建快照：
    当 RDB 持久化被触发时（可以手动触发或根据配置自动触发），Redis 会生成一个数据集的内存快照。这个快照包含了数据库在某个时间点的所有键值对以及相关的数据结构信息。

  2. 快照数据序列化：
    在创建快照后，Redis 会将快照中的数据进行序列化，将键、值、过期时间等信息按照一定的格式编码成二进制数据。

  3. 保存到文件：
    将序列化后的数据保存到磁盘上的 RDB 文件中。RDB 文件的扩展名通常为.rdb。

  4. 持久化完成：
    一旦 RDB 文件保存完成，持久化过程结束。这个 RDB 文件包含了数据库在快照时间点的完整数据状态。

RDB 的优缺点：

优点：

  • 紧凑的数据格式： RDB 文件是一个二进制文件，采用了紧凑的编码格式，因此在磁盘上占用的空间相对较小。
  • 快速恢复： 在恢复数据时，通过加载 RDB 文件，可以快速地将数据恢复到指定时间点的状态。
  • 适用于备份和恢复： RDB 文件适用于进行数据备份、迁移和灾难恢复，可以方便地复制到其他服务器上。

缺点：

  • 数据丢失： 由于 RDB 是周期性的全量持久化，可能会导致某个时间点之后的数据丢失。
  • IO 开销： RDB 持久化时，需要将整个数据集写入磁盘，可能在大数据集上引起 IO 开销，影响性能。
  • 耗时： 在生成 RDB 快照的过程中，如果数据集很大，可能会占用较多的 CPU 资源，导致短时间内的性能下降。

总的来说，RDB 持久化适用于需要紧凑的备份和数据迁移，以及在服务器重启时需要快速恢复数据的场景。但需要注意的是，RDB 的全量持久化可能会导致某些数据的丢失，因此在选择持久化方式时需要权衡数据的重要性和性能需求。

给哪些内存数据做快照？

在 RDB 持久化中，Redis 会对内存中的各种数据进行快照，将数据保存到 RDB 文件中。这些内存数据包括：

  1. 字符串类型数据： 包括使用 SET 命令设置的字符串键值对。

  2. 哈希表（Hash）： 包括使用 HSET、HMSET 等命令设置的哈希键值对。

  3. 列表（List）： 包括使用 LPUSH、RPUSH 等命令添加的列表元素。

  4. 集合（Set）： 包括使用 SADD 等命令添加的集合元素。

  5. 有序集合（Sorted Set）： 包括使用 ZADD 等命令添加的有序集合元素。

  6. Bitmaps、HyperLogLogs、Streams： 包括这些特殊数据类型的内容。

  7. 过期时间： 快照会记录每个键的过期时间，以便在恢复数据时进行过期判断。

  8. 数据库配置： 包括数据库的配置信息，如数据库编号、键空间的选项等。

  9. 服务器信息： 包括服务器的信息，如版本号、运行模式等。

  10. 客户端连接信息： 包括客户端连接的信息。

需要注意的是，RDB 持久化是一种全量持久化机制，它会在某个时间点生成一个数据库的快照，将所有内存中的数据保存到 RDB 文件中。这种方式有一些优点，如紧凑的数据格式和快速恢复，但也有缺点，如可能造成数据丢失和 IO 开销。在选择使用 RDB 持久化时，需要权衡这些优缺点，根据业务需求来确定是否适合使用。

哪些命令能生成 RDB 文件？

RDB 文件是通过执行持久化操作来生成的，而不是通过特定的命令来生成。在 Redis 中，可以手动触发 RDB 持久化操作，也可以根据配置自动触发。以下是生成 RDB 文件的方式：

  1. 手动触发：
    使用 SAVE 命令可以手动触发 RDB 持久化操作，该命令会 阻塞服务器 的主线程，直到 RDB 文件生成完成为止。这个命令适合用于测试或紧急情况下的数据备份。

    示例：

    1
    SAVE

  2. 后台触发：
    使用 BGSAVE 命令可以在后台触发 RDB 持久化操作，这个命令会派生一个子进程来执行 RDB 持久化，不会阻塞服务器
    的主线程。这是比较常用的生成 RDB 文件的方式。

    示例：

    1
    BGSAVE

  3. 自动触发：
    可以通过配置文件中的参数来自动触发 RDB 持久化操作。在配置文件（redis.conf）中可以设置 save 参数，用于指定在何时执行 RDB 持久化操作，例如：

    1
    2
    3
    save 900 1
    save 300 10
    save 60 10000

    这表示当 900 秒内至少发生 1 次写操作、300 秒内至少发生 10 次写操作、60 秒内至少发生 10000 次写操作时，自动触发 BGSAVE 命令。

无论是手动触发还是后台触发，RDB 持久化操作都会生成一个 RDB 文件，其中包含了内存中的数据快照。需要注意的是，RDB 持久化是一个资源密集型操作，可能会影响服务器的性能，特别是在数据集较大的情况下。因此，在选择何时执行 RDB 持久化时，需要根据业务需求和性能要求做出权衡。

快照时数据能修改吗？

这里大家可能会想到 bgsave 命令避免阻塞。这里大家可能会有误区，避免阻塞和正常处理读写请求并不是一回事
。此时，主线程确实没有阻塞，可以正常接收请求，但是，为了保证快照完整性，它只能处理读操作，因为不能修改正在执行快照的数据。
那么 Redis 是如何解决这个问题的呢？
实际上，Redis 6.0 版本引入了 写时复制（Copy-On-Write，COW）技术 来保证在执行快照（RDB）时数据是可修改的。这个特性被称为 “
RDB 快照时复制”（RDB Snapshotting）。

在 Redis 6.0 中，当进行 RDB 快照持久化时，Redis 会执行以下步骤来确保数据可修改：

  1. Redis 创建一个子进程。
  2. 在子进程中，将内存中的数据进行写时复制，创建出一个副本，而不会影响主进程的数据。
  3. 子进程将副本数据写入 RDB 文件，这个过程是在子进程的上下文中执行的，不会影响主进程。

这个操作在实际执行过程中，是子进程复制了主线程的页表，所以通过页表映射，能读到主线程的原始数据，而当有新数据写入或数据修改时，主线程会把新数据或修改后的数据写到一个新的物理内存地址上，并修改主线程自己的页表映射。所以，子进程读到的类似于原始数据的一个副本，而主线程也可以正常进行修改。

因此，RDB 快照时，主进程仍然可以继续处理写操作，而子进程则负责将数据写入 RDB 文件。这样，写时复制技术确保了在生成 RDB
快照期间，数据是可修改的，同时保持了数据的一致性。

需要注意的是，这种特性仅适用于 Redis 6.0 及以上版本，并且在 RDB 快照时起作用。在生成 AOF 文件时，Redis 仍然会阻塞主线程以确保数据一致性。
写时复制机制保证快照期间数据可修改

可以每秒做一次快照吗

虽然理论上可以每秒钟做一次快照（RDB 持久化），但实际上这样做可能会对 Redis 服务器的性能产生显著的影响，特别是在负载较重的情况下。

每秒钟生成快照会引起以下一些问题：

  1. 性能开销： 快照操作需要遍历内存中的所有数据，并将数据序列化到磁盘中。频繁的快照操作会占用大量的 CPU 和内存资源，影响服务器的性能，导致响应时间变长。

  2. IO 压力： 每秒钟生成的快照会导致频繁的磁盘写入，增加了磁盘 IO 的负担，可能影响其他应用程序和操作系统的正常运行。

  3. 数据丢失： 每秒钟生成的快照可能会导致数据丢失，因为生成快照的操作需要一定的时间，如果在两次快照之间发生了写操作，那么这段时间内的数据会丢失。

通常情况下，每秒钟生成快照并 不是一个推荐的做法
。更合理的做法是根据业务需求和系统资源来选择合适的持久化频率。如果数据的一致性要求很高，可以考虑使用 AOF 持久化机制，它可以在不同程度上提供数据的保护和持久性，而且可以通过设置不同的写回策略来平衡性能和数据保护。如果数据的一致性要求相对较低，可以选择适当的 RDB 持久化频率，避免频繁的 IO 和性能开销。

为什么推荐 AOF 和 RDB 混合使用

推荐在 Redis 中同时使用 AOF（Append-Only File）持久化和 RDB（Redis DataBase）持久化的原因是，这两种持久化机制可以相互补充，提供更好的数据保护、恢复能力和性能优化。

以下是推荐同时使用 AOF 和快照的主要原因：

  1. 数据恢复能力：
    AOF 持久化记录了所有写操作的日志，这使得在发生意外情况时（如服务器崩溃）可以精确地恢复数据到崩溃前的状态。而 RDB 持久化通过全量快照提供了快速的数据恢复能力。结合使用两者，可以在 AOF 日志的基础上，通过加载最近的 RDB 快照来加速恢复。

  2. 数据安全性： AOF 持久化记录了每个写操作，可以确保每个写操作都被持久化到日志中。RDB 持久化则提供了一个点对点的数据备份。同时使用这两种持久化机制可以提供更高的数据安全性。

  3. 性能优化： AOF 持久化对于读操作的性能影响较小，因为读操作不涉及 AOF 文件的写入。而 RDB 持久化对于快速的全量数据恢复很有帮助。通过结合使用 AOF 和 RDB，可以在一定程度上平衡数据保护和性能要求。

  4. 多层次的备份： 使用 AOF 和 RDB，您可以获得多层次的数据备份。AOF 日志可以提供精确的操作日志，RDB 快照可以提供全量备份。这样，即使其中一个持久化机制出现问题，另一个仍然可以提供数据保护。

综上所述，使用 AOF 和 RDB 两种持久化机制的组合，能够提供更全面的数据保护、灾难恢复和性能优化。在配置 Redis 持久化时，根据业务需求和性能要求，结合使用这两种机制，可以实现更好的数据管理和保护。

如何配置呢

在 Redis 中，同时使用 AOF 持久化和 RDB 持久化的配置是很常见的，这样可以兼顾数据的持久性和恢复性能。以下是一个将 AOF 持久化和
RDB 持久化混合使用的示例配置：

  1. 打开 Redis 配置文件，通常是 redis.conf。

  2. 启用 AOF 持久化：
    找到以下行并确保其被设置为以下值，以启用 AOF 持久化：

    1
    appendonly yes

  3. 设置 AOF 重写策略（可选）：
    可以设置 AOF 重写的触发条件，以便控制 AOF 文件的大小和写入频率。例如：

    1
    2
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb

  4. 启用 RDB 持久化：
    默认情况下，Redis 会使用 RDB 持久化，但要确保以下行没有被注释掉：

    1
    2
    3
    save 900 1
    save 300 10
    save 60 10000

  5. 设置 RDB 快照文件名（可选）：
    如果希望为 RDB 快照指定特定的文件名，可以添加以下行：

    1
    dbfilename dump.rdb

    这会将 RDB 快照文件命名为 dump.rdb。

  6. 设置 RDB 快照保存路径（可选）：
    如果希望将 RDB 快照保存到特定的路径，可以添加以下行：

    1
    dir /path/to/rdb/directory

    这会将 RDB 快照保存到指定的目录。

  7. 重启 Redis 服务器：
    在对配置文件进行更改后，需要重新启动 Redis 服务器，以使配置生效。

使用以上配置，Redis 将同时使用 AOF 持久化和 RDB 持久化，提供了多层次的数据保护和恢复机制。AOF 持久化记录写操作，提供操作日志用于数据恢复。RDB
持久化提供了全量备份，用于快速恢复整个数据集。混合使用这两种机制可以充分利用它们各自的优点，提供更全面的数据持久性和保护。

关于 AOF 和 RDB 的选择，三点建议

  • 数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；
  • 如果允许分钟级别的数据丢失，可以只使用 RDB；
  • 如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个平衡。��能之间取了一个平衡。