【Redis】深入理解 Redis 长期化机制 —— RDB 和 AOF
一、Redis 的长期化固然 Redis 是一个内存数据库，但由于各种原因，如 Redis 服务器的重启、不测崩溃等，内存中的数据大概会丢失。为了确保数据的长期性和可靠性，Redis引入了长期化机制，答应将数据定期生存到磁盘中，以便在下次启动 Redis 时能够规复原来的数据到内存中。
Redis 的长期化机制是 Redis 数据库的一个告急构成部门，它答应将内存中的数据以不同的方式写入磁盘，以防止数据丢失。这对于很多应用场景非常关键，特别是需要恒久生存数据或具有高可用性要求的系统。
在本文中，将深入探究 Redis 的两种主要长期化机制，即 RDB（Redis DataBase）和 AOF（Append-Only File），以及它们的工作原理、优缺点和怎样设置它们。此外，还将介绍肴杂长期化的概念，这是一种团结了 RDB 和 AOF 的方式，以充分利用它们各自的优势。通过本文的阅读，希望可以资助读者更好地了解 Redis 长期化机制，以便根据实际的应用需求进行精确的设置和管理。
二、RDB 长期化机制
2.1 对 RBD 的熟悉
RDB 的概念
RDB（Redis DataBase）是 Redis 的一种长期化方式，它用于将当前内存中的数据生存到硬盘上的一个快照（snapshot）文件中。这个快照文件包含了一个特定时刻的所有数据，包括键值对、数据布局等。RDB 的工作方式雷同于数据库的备份，它将内存中的数据定期生存到一个长期化文件中，以便在需要时进行数据规复。
RDB 长期化机制的优缺点
优点：
[*] 高性能： RDB长期化机制在性能上体现精彩。因为RDB是通过 fork 子进程来完成的，主进程不需要执行繁重的 IO 操纵，这可以确保Redis 在天生 RDB 快照时保持高吞吐量。
[*] 紧凑和可读性好： RDB 文件采用了一种高效的二进制格式，可以很好地生存数据，而且非常紧凑。这使得 RDB 文件既节省磁盘空间，又具有很高的可读性，方便备份和迁移。
[*] 适用于灾难规复： RDB 文件是完备的数据库快照，可以用于从灾难中规复数据，例如硬盘故障或不可逆的数据破坏。
[*] 备份和迁移： 由于 RDB 文件的紧凑性和可读性，它非常适用于备份数据或在不同情况之间迁移 Redis 数据。
[*] 节省磁盘空间： 可以根据需要设置 RDB 的生存频率，从而在肯定程度上控制磁盘空间的占用。
缺点：
[*] 数据大概有损失： RDB 是定期天生的快照文件，如果 Redis 服务器在天生快照之间崩溃，大概会丢失最后一次快照之后的数据。
[*] 不适用于大规模数据： 在处理大规模数据时，天生 RDB 文件大概会导致较长时间的阻塞，影响性能。在某些情况下，阻塞时间大概会变得不可接受。
[*] 不适用于实时长期化需求： RDB 是基于快照的，因此不能提供实时长期化。如果需要每个写操纵都立即长期化到磁盘，RDB 大概不是最佳选择。
[*] 设置文件的修改： 如果频繁地修改Redis的设置文件，RDB大概就变得不得当，因为它只有在 Redis 服务器正常关闭时才会天生快照。这大概会导致在设置更改后发生数据丢失。
总之，RDB 长期化机制在性能、备份和紧凑性方面体现精彩，适用于很多使用场景，但需要注意数据大概会有损失，而且在处理大规模数据时需要慎重思量。如果对实时长期化有更高要求，可以思量使用 AOF 长期化机制或肴杂长期化来弥补 RDB 的不敷。
RDB 的相干设置
Redis的RDB长期化可以通过在Redis设置文件（通常是redis.conf）中进行相干设置。以下是一些与RDB长期化有关的常见设置项：
[*] 生存快照的频率：
save 900 1 # 表示在900秒（15分钟）内，如果至少有1个键发生变化，就会触发RDB快照保存。
save 300 10 # 表示在300秒（5分钟）内，如果至少有10个键发生变化，就会触发RDB快照保存。
save 60 10000 # 表示在60秒内，如果至少有10000个键发生变化，就会触发RDB快照保存。
这些设置项界说了 RDB 长期化的触发条件。根据具体的应用需求，就可以根据不同的时间间隔和键变化数来触发 RDB 快照。
[*] RDB文件名和路径：
dbfilename dump.rdb # 指定RDB快照文件的名称
dir /var/lib/redis # 指定RDB文件的保存路径
这些设置项答应指定 RDB 快照文件的名称和生存路径。注意需要确保文件夹存在并具有适当的权限。
[*] 禁用 RDB 主动长期化：
save "" # 禁用自动RDB持久化
如果想禁用主动触发的 RDB 长期化，可以将save设置项设置为空字符串。
[*] RDB 长期化压缩：
rdbcompression yes# 开启 RDB 文件压缩（默认情况下是开启的）
这个设置项控制是否对天生的RDB文件进行压缩，开启后可以减小 RDB 文件的巨细，但会占用额外的 CPU 资源。
[*] 检查点文件：
rdbchecksum yes # 在保存RDB文件时是否进行校验和检查（默认情况下是开启的）
这个设置项控制是否在生存 RDB 文件时进行校验和检查，以确保文件的完备性。
请注意，要使设置更改收效，就需要重启 Redis 服务器。根据具有的应用需求和数据量，可以调整这些设置项，以满足性能和长期性的要求。
2.2 RDB 的触发时机
RDB的触发时机分为主动触发和手动触发两种方式：
主动触发
主动触发是通过设置文件中的生存快照的频率来实现的。在 Redis 的设置文件（redis.conf）中，可以设置一个或多个save指令来界说何时主动触发 RDB 快照的生存。每个save指令都有两个参数，第一个参数是时间间隔（单位为秒），第二个参数是发生变化的键的数目。
例如，以下是一个生存快照的主动触发设置示例：
save 900 1 # 表示在900秒（15分钟）内，如果至少有1个键发生变化，就会触发RDB快照保存。
save 300 10 # 表示在300秒（5分钟）内，如果至少有10个键发生变化，就会触发RDB快照保存。
save 60 10000 # 表示在60秒内，如果至少有10000个键发生变化，就会触发RDB快照保存。
这些设置项界说了 RDB 主动触发快照生存的条件。Redis 会定期检查这些条件，如果满足此中任何一个条件，就会触发RDB快照的天生。
当然如果设置了save ""，则会克制主动触发。
手动触发：SAVE
和 BGSAVE
手动触发 RDB 快照是通过 Redis 的下令来实现的，主要有两个下令可用：
[*]SAVE
下令： 使用 SAVE
下令可以立即天生一个 RDB 快照，它会阻塞 Redis 服务器，直到 RDB 快照天生完成为止。这个下令不常用，因为它会导致 Redis 服务器在天生快照期间制止响应其他请求。
语法：
SAVE
[*]BGSAVE
下令： 使用 BGSAVE
下令可以在后台天生 RDB 快照，而不会阻塞 Redis 服务器的正常操纵，这是通常推荐的手动触发方式。
BGSAVE
BGSAVE
下令会使用操纵系统提供的 fork 系统调用启动一个子进程，该子进程负责天生 RDB 快照文件，而主进程继承响应其他请求。一旦天生完成，BGSAVE
会将 RDB 文件生存到磁盘，然后通知主进程。
BGSAVE
下令的运作流程：
https://i-blog.csdnimg.cn/blog_migrate/a34797ee55f1a2dfa59fffe2336c1699.png
说明：
[*]执行 BGSAVE
下令时，Redis 父进程起首会判断当进步是否存在其他正在执行的子进程，例如执行 RDB大概AOF 相干下令的子进程，如果存在，此时的 BGSAVE
下令则会直接返回。
[*]父进程会执行 fork 创建子进程，fork 的过程中父进程会阻塞，通过 info stats 下令检察 latest_fork_usec 选项，可以获取最近一次 fork操纵的耗时，单位为微秒。
[*]父进程执行 fork 完成后，BGSAVE
下令会返回 “Background saving started” 信息，今后将不再阻塞父进程，可以继承响应其他下令。同时子进程负责天生 RDB 快照文件。
[*]子进程在创建 RDB 文件时，会根据父进程的内存天生临时的快照文件，完成后会对原有dump.rdb文件进行原子替换。执行 lastsave下令可以获取最后⼀次天生 RDB 的时间，对应 info 统计的 rdb_last_save_time 选项。
[*]子进程创建RDB文件完成后会发送信号给父进程体现完成了，父进程则会更新统计信息。
手动触发RDB快照通常用于备份 Redis 数据、手动管理长期化计谋或在执行某些操纵前创建数据的同等性快照。总之，RDB 的触发时机可以通过主动触发和手动触发两种方式来实现，具体取决于具体的应用需求和管理计谋。主动触发是定期生存的机制，而手动触发则答应您在需要时立即创建RDB快照。
2.3 RDB 文件的处理
RDB文件是 Redis 数据库的快照文件，它生存了当前内存中的数据以便在需要时进行规复。以下是关于RDB文件的处理和管理的告急信息：
生存 RDB 文件
[*] 文件生存路径： RDB 文件生存在 Redis 设置文件中指定的目录下，默认情况下是/var/lib/redis/。文件名由设置文件中的dbfilename参数指定，默认为 “dump.rdb”。可以在 Redis 运行时使用 CONFIG SET 下令动态更改生存目录和文件名，例如：
CONFIG SET dir /new/directory/
CONFIG SET dbfilename newdump.rdb
这将使RDB文件生存到新的目录和使用新的文件名。
[*] 手动生存： 可以通过执行SAVE
或BGSAVE
下令来手动触发 RDB 文件的生存。SAVE
下令会在 Redis 服务器天生 RDB 文件的同时阻塞其他请求，而 BGSAVE
下令会在后台天生 RDB 文件，不会阻塞其他操纵。
SAVE
BGSAVE
压缩 RDB 文件
Redis默认采用 LZF 算法对天生的 RDB 文件进行压缩处理，以减小文件的体积，节省磁盘空间和网络带宽。压缩是默认开启的，但我们可以通过以下下令动态修改：
CONFIG SET rdbcompression yes # 开启RDB文件压缩
CONFIG SET rdbcompression no # 禁用RDB文件压缩
固然压缩RDB文件会斲丧CPU资源，但通常发起开启，特别是在磁盘空间和网络带宽有限的情况下，因为它可以显著减小文件的巨细。
校验 RDB 文件
Redis 在启动时会加载 RDB 文件，如果文件破坏或格式错误，Redis 将拒绝启动。为了检查 RDB 文件的完备性和有效性，可以使用Redis提供的 redis-check-rdb 工具。这个工具会检测 RDB 文件并天生相应的错误陈诉，资助我们识别和办理问题。
https://i-blog.csdnimg.cn/blog_migrate/e3792561493993f1b054cea0350c002b.png
检查 RDB 文件：
https://i-blog.csdnimg.cn/blog_migrate/7e5ae7858f386e9ebb1164f105335a4f.png
处理和管理RDB文件是确保Redis数据长期性和可靠性的告急任务。了解怎样生存、压缩和校验RDB文件可以资助我们更好地管理 Redis 数据库。
三、AOF 长期化机制
3.1 对 AOF 的熟悉
AOF 的概念
AOF（Append-Only File）是 Redis 的一种长期化机制，用于将 Redis 服务器的写操纵以追加的方式纪录到一个文本文件中，从而实现数据长期化。每个写操纵都会以 Redis 下令的情势追加到 AOF 文件的末端，因此 AOF 文件是一个按照时间次序纪录写操纵的日志文件。
AOF 的优缺点
优点：
[*] 数据安全性：AOF 纪录了每个写操纵，因此在服务器故障或崩溃时，只会丢失最后一次写操纵之后的数据。这提供了较高的数据安全性。
[*] 可读性：AOF 文件是一个文本文件，易于人类阅读和理解。这使得AOF文件在需要手动规复数据或进行调试时非常有效。
[*] 灵活性：AOF 文件的追加方式写入使得数据长期化非常实时，可以根据需求选择不同的同步计谋，从完全同步到异步。
[*] 主动重写：Redis 提供了 AOF 文件的主动重写机制，可以避免 AOF 文件过大，提高了性能。
缺点：
[*] 文件体积：相对于 RDB 长期化，AOF 文件通常较大，因为它包含了每个写操纵的下令文本。这大概会占用较多的磁盘空间。
[*] 写入性能：AOF 长期化会导致每个写操纵都需要追加到 AOF 文件中，这大概会对写入性能产生肯定的影响，尤其是在使用同步写入计谋时。
AOF 的相干设置
在Redis中，可以通过设置文件或使用 CONFIG 下令来设置 AOF 长期化的相干参数。以下是一些常用的 AOF 设置选项：
[*] appendonly：用于启用或禁用AOF长期化。设置为"yes"体现启用AOF，设置为"no"体现禁用。默认情况下，AOF长期化是禁用的，需要手动启用。
[*] appendfilename：指定AOF文件的文件名，默认为"appendonly.aof"。您可以根据需要更改文件名。
https://i-blog.csdnimg.cn/blog_migrate/347b73f9fc54df773b73deb648add1c0.png
[*] appendfsync：指定AOF文件同步到磁盘的计谋。可以选择的选项包括"always"（每次写操纵都同步）、“everysec”（每秒同步一次）和"no"（完全异步）。
https://i-blog.csdnimg.cn/blog_migrate/f042a300b3f68106d4d9cd7b0dc4eb05.png
[*] auto-aof-rewrite-percentage和auto-aof-rewrite-min-size：用于设置 AOF 主动重写的触发条件。前者体现 AOF 文件的巨细相对于上一次重写时的巨细增长了多少百分比时触发重写，后者体现 AOF 文件的最小巨细。
https://i-blog.csdnimg.cn/blog_migrate/68119ee6b525cbd9464171595d348acf.png
这些设置选项可以在Redis的设置文件（通常是redis.conf）中找到，也可以通过CONFIG下令进行动态设置。根据您的需求和应用场景，可以灵活设置 AOF 长期化以实现数据的长期性和性能要求。
3.2 AOF 的使用
使用演示
当设置完 AOF 相干选项之后，需要使用下令service redis-server restart重启 Redis 服务器，当重启之后，就会发现在和 dump.rdb 文件相同的目录下多了一个 appendonly.aof 文件：
https://i-blog.csdnimg.cn/blog_migrate/c67195926743ce221da7531ec174a32f.png
向 Redis 中设置两条数据：
https://i-blog.csdnimg.cn/blog_migrate/7108a83a8f74d6fcfc60a251f00dbffe.png
检察 appendonly.aof 文件：
https://i-blog.csdnimg.cn/blog_migrate/32aca293aac7398251e3812731339b3b.png
其文件内容就是刚才的写入数据的下令。
突然终止 Redis 服务器，然后再启动：
https://i-blog.csdnimg.cn/blog_migrate/13f862c57aaa37297ae6834ba54a805f.png
毗连并查询 Redis 数据库，发现数据并没有丢失：
https://i-blog.csdnimg.cn/blog_migrate/2defa23f1b6afbcf3d46fae3fe83a856.png
AOF 工作流程
工作流程图示如下：
https://i-blog.csdnimg.cn/blog_migrate/4a34f439607d8bf897ea5ff30e7dfe09.png
[*]所有的写入下令会追加到 aof_buf 缓冲区中。
[*]AOF 缓冲区根据对应的计谋向硬盘做同步操纵。
[*]随着 AOF 文 件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
[*]当 Redis 服务器启动时，会加载 AOF 文件中的下令进行数据规复。
下令写入：
AOF 下令写入的内容是直接遵循 Redis 的文本协议格式。例如，set hello world 下令在 AOF 缓冲区中以文本协议格式体现如下：
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
Redis 选择文本协议的原因包括兼容性好、实现简朴以及具备可读性等特点。
为什么使用aof_buf 缓冲区：
AOF 缓冲区（aof_buf）的存在是为了提高写入性能。因为 Redis 是单线程响应下令的，如果每次写入都直接同步到硬盘，性能将受到严重影响。通过起首将下令写入缓冲区，Redis 可以有效减少 IO 操纵的次数，提高性能。此外，Redis 还提供多种缓冲区同步计谋，使用户可以根据性能和数据安全性的需求进行权衡选择。
3.3 AOF 同步文件计谋
Redis 提供了多种 AOF 缓冲区同步文件计谋，由设置文件（redis.conf）中的参数appendfsync 控制，可设置的值及其说明如下表所示：
可设置值说明always每次通过write 写入 aof_buf 中都会立即强制调用 fsync 将数据同步到磁盘，确保数据安全，但写入性能较差。everysec通过 write 操纵起首追加到 aof_buf 中，然后每秒执行一次同步操纵，将数据同步到 AOF 文件中，以平衡性能和数据安全性。no只将写入操纵通过 write 追加到aof_buf中，同步操纵由操纵系统控制。这种设置提供最高的写入性能，但数据安全性较低。 有关系统调用 write 和 fsync 的说明：
[*] write 操纵触发了延迟写（delayed write）机制。Linux 内核提供页面缓冲区以提高硬盘 I/O 性能。write 操纵将数据写入系统缓冲区后立即返回。同步到硬盘的操纵依赖于操纵系统的调理机制，例如，缓冲区页面满或达到特定时间间隔。如果系统在同步文件之前崩溃或宕机，缓冲区内的数据大概会丢失。
[*] fsync是针对单个文件的操纵，它执行强制硬盘同步，fsync 会阻塞直到数据被写入到硬盘。
不同的设置值：
[*] 设置为always时，每次写入都会强制同步 AOF 文件，这会导致性能很差。在一般的 SATA 硬盘上，只能支持几百个 TPS 的写入。通常不发起设置为always，除非数据非常告急。
[*] 设置为no时，由于操纵系统同步计谋不受控制，固然提高了性能，但数据丢失的风险大大增加。一般情况下不发起设置为no，除非数据的告急性很低。
[*] 设置为everysec是默认设置，也是推荐的设置选项，它兼顾了数据安全性和性能。理论上最多只会丢失1秒的数据。
这些设置选项答应用户根据性能和数据安全性的需求来选择得当的 AOF 同步计谋。
3.4 AOF 重写机制
为什么要进行 AOF 文件的重写
进行 AOF 文件的重写是为了办理 Redis 中大概存在的大量无效下令积累的问题。让我们通过一些简朴的例子来说明：
在 Redis 中，执行了以下一系列写入下令：
SET key1 123
SET key1 hello
SET key1 world
SET key1 123
只管上面执行了 4 条写入下令，但终极在 Redis 中只存在最后一条下令写入的数据，也就是key1的值为123。
同样，执行了以下一系列写入下令：
SET key2 123
SET key2 hello
SET key2 world
SET key2 123
DEL key2
固然上面执行了 5 条写入下令，但终极 key2 在 Redis 中并不存在。
[*] 例如在 Redis 中执行下列下令：
https://i-blog.csdnimg.cn/blog_migrate/cc00e1c0060c71309b77f8df7ff63b67.png
[*] 重写前：
https://i-blog.csdnimg.cn/blog_migrate/c12d015f7116d75d321fc740e0eecd17.png
[*] 重写后：
https://i-blog.csdnimg.cn/blog_migrate/5f7d5f5a18e8cb9729c5761227736f31.png
此时发现出现了乱码，便是以二进制的情势储存的，发生这样的原因是因为同时开启了AOP 和 RDB ，因此此时 Redis 采取的长期化计谋就是肴杂长期化了。
https://i-blog.csdnimg.cn/blog_migrate/26dfed3bf753cd6a5117c11d05e00602.png
[*]使用 Redis 提供的检查工具redis-check-aof 检查 AOF 文件，可以发现 AOF 文件是正当的：
https://i-blog.csdnimg.cn/blog_migrate/d2ce2a5ed30cb086ca840a8f8588b5f2.png
通过上面两个简朴的例子可以得出：
[*]如果没有 AOF 文件的重写机制，Redis 将持续存储大量无效的下令，这会导致 AOF 文件变得巨大，占用大量磁盘空间，而且低落 AOF 文件的读取性能。
[*]AOF 文件的重写通过将这些无效下令清除，天生一个更加紧凑和高效的新 AOF 文件，办理了这个问题。新的 AOF 文件只包含有效的写入下令，这有助于减小文件体积，提高读取性能，并确保不丢失任何有效数据。这是为什么要进行AOF文件的重写的原因。
AOF 重写的触发方式
AOF文件的重写可以通过以下两种方式触发：
[*] 手动触发：通过调用 Redis 提供的BGREWRITEAOF下令，可以手动触发 AOF 文件的重写过程。这个下令会立即开始 AOF 文件的重写，而不会影响 Redis 的正常运行。
[*] 主动触发：Redis 也支持主动触发 AOF 文件的重写，触发的时机是基于两个设置参数来决定的：
[*] auto-aof-rewrite-min-size：这个参数界说了AOF文件的最小巨细，以MB为单位。默认值为64MB。只有当AOF文件的巨细超过这个阈值时，才会思量触发主动重写。
[*] auto-aof-rewrite-percentage：这个参数界说了AOF文件巨细相对于前次重写后的增长比例，以百分比体现。默认值为100%。如果AOF文件的巨细增长超过了前次重写后的这个百分比，就会触发主动重写。
例如，如果将auto-aof-rewrite-min-size设置为64MB，auto-aof-rewrite-percentage设置为100%，那么只有当AOF文件的巨细超过64MB，而且比前次重写后增长了100%或更多时，主动重写才会被触发。
主动触发AOF文件的重写是为了确保AOF文件不会无穷定地增长，同时避免过于频繁地执行重写操纵。这样可以在不丢失任何数据的情况下，保持AOF文件的合理巨细，提高性能，并减少磁盘空间的占用。
AOP 重写的执行流程
https://i-blog.csdnimg.cn/blog_migrate/e60012b9eb4f12766608f7c4a4dcd24f.png
AOP 重写的执行流程如下：
[*] 执行 AOF 重写请求。
[*]如果当进步程正在执行 AOF 重写，请求不执行。
[*]如果当进步程正在执行 bgsave 操纵，重写下令将延迟到 bgsave 完成后再执行。
[*] 父进程执行 fork 创建子进程。
[*] 重写过程：
a. 主进程在 fork 之后继承响应其他下令。所有修改操纵会被写入 AOF 缓冲区，并根据 appendfsync 计谋同步到硬盘，以确保旧 AOF 文件机制的精确性。
b. 子进程只有 fork 之前的所有内存信息，以是父进程需要将 fork 之后这段时间内的修改操纵写入 AOF 重写缓冲区中。
[*] 子进程根据内存快照，将下令合并到新的 AOF 文件中。
[*] 子进程完成重写：
a. 新文件写入后，子进程发送信号给父进程。
b. 父进程将 AOF 重写缓冲区内临时生存的下令追加到新 AOF 文件中。
c. 使用新 AOF 文件替换旧 AOF 文件。
四、肴杂长期化
肴杂长期化是指 Redis 同时使用 AOF（Append-Only File）和 RDB（Redis Database）两种长期化方式来保障数据的长期性。这种计谋团结了两种不同的长期化方法，以兼顾不同的需求和场景。
下面是肴杂长期化的工作原理和优点：
1. AOF 长期化：
[*]AOF 是一种追加写日志文件，纪录了每个写操纵的下令，以及这些下令的参数。
[*]AOF 长期化是实时的，即每个写操纵都会追加到 AOF 文件中，确保了数据的完备性。
[*]AOF 文件可以用于数据的规复，Redis可以通过重新执行 AOF 文件中的下令来重修数据状态。
2. RDB 长期化：
[*]RDB 是一种快照长期化，它将 Redis 内存中的数据以二进制情势生存到磁盘上。
[*]RDB 长期化是点对点的，即在指定的时间间隔内天生一次快照文件，通常是在内存数据发生变化后天生。
[*]RDB 文件是一个经过压缩的二进制文件，用于在需要时快速规复整个数据库的状态。
肴杂长期化的工作方式：
[*]Redis 同时启用了 AOF 和 RDB 长期化方式。
[*]AOF 文件会纪录每个写操纵，而 RDB 文件则会在特定的时间间隔内天生一次快照。
[*]在数据规复时，Redis 会起首尝试使用 AOF 文件进行规复，因为它包含了更多的历史下令，可以提供更完备的数据规复。
[*]如果 AOF 文件破坏大概过大，Redis 可以使用 RDB 文件进行快速的启动，然后再根据 AOF 文件进行数据修复。
肴杂长期化的优点：
[*]数据安全性：AOF 提供实时的数据追加和历史纪录，使得数据更加安全。RDB 提供了快速的规复方式。
[*]性能：AOF 的写操纵相对 RDB 更加高效，而 RDB 提供了快速的数据规复。
[*]灵活性：肴杂长期化答应根据不同的需求和场景来选择适当的规复方式。
[*]低落数据损失：由于 AOF 文件包含了历史操纵，可以减少数据损失的大概性。
总之，肴杂长期化将 AOF 和 RDB 两种长期化方式团结起来，兼顾了实时性和规复性，提供了更全面的数据掩护计谋，使 Redis 在不同应用场景中更加强大和可靠。但需要注意的是，肴杂长期化大概会增加存储开销和磁盘 I/O 负载，因此在设置时需要谨慎思量。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]