Redis系列（二）：深入解读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先执行命令，把数据写入内存，然后才记录日志，如下图所示：

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

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

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

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

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

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

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

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

假设执行了以下操作：

SET key1 value1
INCR key2
LPUSH list1 item1

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

*3rn$3rnSETrn$4rnkey1rn$6rnvalue1rn
*2rn$4rnINCRrn$4rnkey2rn
*3rn$5rnLPUSHrn$5rnlist1rn$5rnitem1rn

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

• *3：表示命令参数的个数为3。
• $3rnSETrn：表示第一个参数为长度为3的字符串 "SET"。
• $4rnkey1rn：表示第二个参数为长度为4的字符串 "key1"。
• $6rnvalue1rn：表示第三个参数为长度为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重写的工作原理如下：

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

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

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

需要注意的是，AOF重写是一个资源密集型操作，可能会影响系统的性能，特别是在大数据集的情况下。因此，在进行AOF重写时，应该考虑其对系统性能的影响，并确保系统具备足够的资源来执行重写操作。
下面举例说明一下：

这里大家能看到，经过优化后，AOF日志文件会缩小很多，但是，要把整个数据库的最新数据的操作日志都写回磁盘，仍然是一个非常耗时的过程。这时，我们就要继续关注另一个问题了。

重写会不会阻塞主线程？

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

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

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

RDB快照是如何实现的？

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

RDB的实现过程：

RDB的优缺点：

优点：

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

缺点：

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

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

给哪些内存数据做快照？

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

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

哪些命令能生成RDB文件？

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

SAVE

BGSAVE

save 900 1
save 300 10
save 60 10000

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

快照时数据能修改吗？

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

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

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

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

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

可以每秒做一次快照吗

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

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

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

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

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

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

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

如何配置呢

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

appendonly yes

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

save 900 1
save 300 10
save 60 10000

dbfilename dump.rdb

dir /path/to/rdb/directory

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

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

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

本文由mdnice多平台发布