Java学习笔记（二十一）

1 auto-aof-rewrite-percentage 100、auto-aof-rewrite-min-size 64mb redis 配置分析

在 Redis 配置中，auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 是与 AOF（Append Only File）持久化相关的两个重要参数。它们共同决定了何时触发 AOF 文件的重写操作，以优化文件的大小和性能。下面是对这两个配置参数的详细分析：

1.1 auto-aof-rewrite-percentage 100

• 含义：这个参数设置了 AOF 文件重写触发的百分比阈值。当 AOF 文件的大小比上一次重写后的大小增长了指定的百分比时，就会触发重写操作。
• 值：100 表示 AOF 文件的大小增长到上一次重写后大小的两倍时触发重写。这是一个相对较高的阈值，意味着 AOF 文件会相对较大时才进行重写，这可能会导致在 AOF 文件非常大之前不会有重写操作，从而减少了重写操作的频率，但可能增加了重写时的开销和所需时间。
• 影响：较高的值会减少重写操作的频率，但每次重写时可能需要更多的时间和资源。较低的值会增加重写操作的频率，但有助于保持 AOF 文件的大小在一个较小的范围内，减少重写时的开销。

1.2 auto-aof-rewrite-min-size 64mb

• 含义：这个参数设置了 AOF 文件重写操作的最小文件大小阈值。只有当 AOF 文件的大小大于或等于这个值时，才会考虑触发重写操作（基于 auto-aof-rewrite-percentage 的条件）。
• 值：64mb 表示只有当 AOF 文件的大小至少为 64MB 时，才会考虑是否需要进行重写。
• 影响：较小的值意味着即使 AOF 文件不大，也可能触发重写操作，这可能会增加重写操作的频率，但有助于保持 AOF 文件的大小。较大的值则减少了小 AOF 文件被重写的可能性，降低了重写操作的频率，但可能使得 AOF 文件在增长较大时才进行重写。

1.3 综合分析

将 auto-aof-rewrite-percentage 设置为 100 和 auto-aof-rewrite-min-size 设置为 64mb 的组合意味着：

• 只有当 AOF 文件的大小增长到上一次重写后大小的两倍，并且这个大小至少为 64MB 时，才会触发 AOF 文件的重写操作。
• 这样的配置适用于那些对 AOF 文件大小不是特别敏感，或者希望减少重写操作频率的场景。它可能适用于写入操作不是特别频繁，或者对性能要求较高，不希望频繁进行 AOF 重写以影响 Redis 性能的场景。

然而，这样的配置也可能导致 AOF 文件变得相对较大，特别是在写入操作频繁或数据量较大的情况下。因此，在选择这些参数的值时，需要根据具体的应用场景和性能需求进行权衡。

2 no-appendfsync-on-rewrite no redis 配置分析

在 Redis 配置中，no-appendfsync-on-rewrite 是一个关键的配置项，它决定了在后台执行 RDB 快照重写（如 BGREWRITEAOF 或 BGSAVE）期间，是否暂停 appendfsync 操作。以下是对 no-appendfsync-on-rewrite 设置为 no 的详细分析：

2.1 配置含义

• no-appendfsync-on-rewrite=no：表示在 RDB 快照重写或 AOF 重写期间，Redis 不会暂停 appendfsync 操作。appendfsync 是 Redis 用于保证数据持久化一致性的机制之一，它决定了每次写操作后，AOF（Append Only File）日志文件何时被同步到磁盘。

2.2 影响分析

1. 数据一致性：

   • 当设置为 no 时，即使在重写期间，每次写操作后的 AOF 日志文件也会被同步到磁盘，从而保证了数据的一致性。这意味着，即使系统在此期间发生崩溃或断电，自上次成功同步到磁盘以来的写操作也不会丢失。

2. 性能影响：

   • 由于在重写期间仍然执行 appendfsync 操作，这可能会增加磁盘 I/O 的压力，从而影响 Redis 的性能。特别是在 AOF 的 appendfsync 配置为 always 或 everysec 时，后台处理进程（如 BGSAVE 或 BGREWRITEAOF）会执行大量的 I/O 操作，这可能会进一步加剧性能问题。

3. 资源利用率：

   • 持续的 appendfsync 操作可能会占用较多的磁盘 I/O 资源，这可能会影响其他需要磁盘 I/O 的操作或进程的性能。因此，在设置此选项时，需要权衡数据一致性和资源利用率之间的关系。

2.3 实际应用建议

1. 评估需求：

   • 在决定是否将 no-appendfsync-on-rewrite 设置为 no 之前，应仔细评估应用对数据一致性和性能的需求。如果数据一致性至关重要，建议保持该选项为默认值（即 no）。

2. 监控与调优：

   • 启用该选项后，应密切监控 Redis 实例的性能和数据持久化情况。如果发现性能下降明显或数据丢失风险增加，应及时调整配置。

3. 备份策略：

   • 无论是否启用该选项，都应制定完善的备份策略，以应对可能的数据丢失风险。这包括定期备份 Redis 数据、使用持久化机制（如 RDB 和 AOF）以及配置合适的复制和故障转移策略。

综上所述，no-appendfsync-on-rewrite=no 的配置保证了 Redis 在重写期间的数据一致性，但可能会带来一定的性能影响和资源利用率问题。因此，在实际应用中需要根据具体需求进行权衡和选择。

3 aof-use-rdb-preamble yes redis 配置分析

在 Redis 配置中，aof-use-rdb-preamble 是一个重要的配置项，它决定了 AOF（Append Only File）重写时是否使用 RDB（Redis Database Backup file）格式的前缀。以下是对 aof-use-rdb-preamble 设置为 yes 的详细分析：

3.1 配置含义

• aof-use-rdb-preamble=yes：表示在 AOF 重写时，会将 Redis 的持久化数据以 RDB 的格式写入到 AOF 文件的开头，之后的数据再以 AOF 的格式追加到文件的末尾。这种混合持久化的方式结合了 RDB 和 AOF 的优点，使得数据恢复既快速又安全。

3.2 影响分析

1. 数据恢复速度：

   • 由于 AOF 文件的开头包含了 RDB 格式的数据快照，Redis 在启动时可以先加载 RDB 内容，再加载剩余的 AOF 内容。这种方式比单纯的 AOF 恢复要快得多，因为 RDB 文件是一个紧凑的二进制文件，加载速度较快。

2. 数据安全性：

   • 混合持久化结合了 RDB 的快照功能和 AOF 的写操作记录功能，降低了数据丢失的风险。即使在两次快照之间 Redis 发生故障，也可以通过 AOF 部分的数据恢复丢失的写操作。

3. 文件可读性：

   • AOF 文件在添加了 RDB 格式的内容后，可读性变差。这对于需要手动查看或编辑 AOF 文件的情况来说可能不太方便。但通常情况下，用户不需要直接操作 AOF 文件，因此这一点对大多数用户来说影响不大。

4. 兼容性：

   • 混合持久化生成的 AOF 文件不能用于 Redis 4.0 之前的版本。因此，在升级 Redis 版本时需要特别注意这一点，确保新版本支持混合持久化功能。

5. 性能影响：

   • 在 AOF 重写期间，Redis 会使用额外的 CPU 和磁盘 I/O 资源来生成 RDB 格式的数据快照。这可能会对 Redis 的性能产生一定的影响，特别是在数据量较大或写操作频繁的情况下。但通常来说，这种影响是可以接受的，因为 AOF 重写是一个后台操作，不会阻塞主线程的处理。

3.3 实际应用建议

1. 评估需求：

   • 在决定是否启用混合持久化之前，应仔细评估应用对数据恢复速度和数据安全性的需求。如果两者都非常重要，那么混合持久化是一个不错的选择。

2. 监控与调优：

   • 启用混合持久化后，应密切监控 Redis 实例的性能和数据持久化情况。如果发现性能下降明显或数据丢失风险增加，应及时调整配置或优化系统资源。

3. 备份策略：

   • 无论是否启用混合持久化，都应制定完善的备份策略。这包括定期备份 Redis 数据、使用持久化机制（如 RDB 和 AOF）以及配置合适的复制和故障转移策略。

综上所述，aof-use-rdb-preamble=yes 的配置结合了 RDB 和 AOF 的优点，提高了数据恢复的速度和安全性。但在实际应用中需要根据具体需求进行权衡和选择，并密切监控 Redis 实例的性能和数据持久化情况。

4 详细介绍 Redis 7 的各种持久化机制

Redis 7 提供了多种持久化机制，以确保数据的可靠性和持久性。以下是 Redis 7 中各种持久化机制的详细介绍：

4.1 RDB（Redis Database）持久化

RDB 持久化通过生成数据集的时间点快照（snapshot）来保存数据。这些快照文件是紧凑压缩的二进制文件，占用空间较小，非常适合用于备份和全量复制等场景。

1. 工作原理：

   • 当需要持久化时，Redis 会创建一个子进程，该子进程会负责将内存中的数据集写入到一个临时的 RDB 文件中。
   • 当子进程完成写入后，它会用新的 RDB 文件替换旧的 RDB 文件。
   • 这个过程利用了写时复制（Copy-on-Write）机制，因此不会阻塞主进程，Redis 可以继续处理客户端请求。

2. 触发方式：

   • 手动触发：可以使用 SAVE 或 BGSAVE 命令来手动触发 RDB 持久化。SAVE 命令会阻塞 Redis 服务器，直到持久化完成；而 BGSAVE 命令则会在后台异步执行持久化操作。
   • 自动触发：Redis 还可以根据配置文件中指定的时间间隔和键值对数量自动触发 RDB 持久化。例如，可以配置为每隔 3600 秒（1 小时）且至少有 1 个键发生变化时自动触发 BGSAVE。

3. 优缺点：

   • 优点：RDB 文件生成速度快，恢复时只需加载 RDB 文件即可，恢复速度也较快；RDB 文件适合用于备份和灾难恢复。
   • 缺点：RDB 持久化只能保存某个时间点的数据快照，如果 Redis 在两次快照之间宕机，那么这期间的数据变更将会丢失；在大数据量的情况下，fork 操作可能会消耗较多的 CPU 和内存资源，对 Redis 的性能有一定的影响。

4.2 AOF（Append Only File）持久化

AOF 持久化通过记录 Redis 服务器接收到的所有写操作命令，并以文本的形式追加到磁盘上的 AOF 文件中来保存数据。当 Redis 重启时，会通过重新执行 AOF 文件中的命令来恢复数据。

1. 工作原理：

   • 每当 Redis 执行一条写操作时，都会将该操作追加到 AOF 文件中。
   • AOF 文件会随着时间的推移而不断增长，因为它记录了所有的写操作命令。
   • 在 Redis 重启时，会读取 AOF 文件中的命令并按照顺序执行它们以恢复数据集的状态。

2. 写回策略：

   • AOF 缓存区会根据写回策略将缓存区中的命令写回磁盘 AOF 文件中。Redis 提供了三种写回策略：
     • always：每个写命令都立即写入磁盘，这提供了最高的数据安全性，但可能会对性能产生较大的影响。
     • everysec（默认）：每秒写入一次磁盘，这提供了较好的数据安全性，同时也不会对性能产生太大的影响。
     • no：由操作系统决定何时写入磁盘，这可能会提供较好的性能，但数据安全性较低。

3. AOF 重写：

   • 由于 AOF 文件会随着时间的推移而不断增长，因此 Redis 提供了 AOF 重写机制来压缩 AOF 文件的大小。AOF 重写会创建一个新的 AOF 文件，其中包含重建当前数据集所需的最小命令集。
   • 可以通过 BGREWRITEAOF 命令来手动触发 AOF 重写操作，也可以在配置文件中设置自动触发条件（例如当 AOF 文件的大小超过某个阈值时自动触发重写）。

4. 优缺点：

   • 优点：AOF 持久化可以记录所有的写操作命令，因此即使 Redis 在宕机后也可以保证数据的可靠性；AOF 文件以文本形式存储，易于阅读和解析。
   • 缺点：AOF 文件可能会占用大量的磁盘空间；在 Redis 重启进行数据恢复时，需要逐行执行 AOF 文件中的命令，这可能会导致恢复速度较慢；如果 AOF 文件在写入过程中发生错误或损坏，可能会导致数据恢复时出现不一致的情况。

4.3 混合持久化（RDB+AOF）

混合持久化结合了 RDB 和 AOF 两种持久化方式的优点。在 Redis 重启时，会优先读取 RDB 文件来恢复数据，然后再根据 AOF 文件中的命令来进一步恢复数据。

1. 工作原理：

   • 在执行 RDB 快照时，Redis 会同时将 AOF 中的命令写入到 RDB 文件中，生成一个包含数据和部分 AOF 日志的混合文件。
   • 在 Redis 重启时，会先读取 RDB 文件来快速恢复数据集的大部分状态，然后再根据 AOF 文件中的命令来恢复剩余的状态。

2. 优缺点：

   • 优点：混合持久化既保证了数据的可靠性（通过 AOF），又提高了数据恢复的速度（通过 RDB）。
   • 缺点：混合持久化可能会增加持久化文件的复杂性和管理难度。

4.4 无持久化

在某些场景下，如果 Redis 仅用作缓存且对数据的一致性要求不高，可以选择禁用持久化功能。这样 Redis 数据只会保存在内存中，重启时会丢失所有数据。

4.5 总结

Redis 7 提供了多种持久化机制以满足不同的应用场景和需求。在选择持久化机制时，需要根据实际的应用场景和需求来权衡持久化和性能之间的关系。例如，可以通过调整持久化的频率、使用更快的磁盘、优化磁盘 I/O 等方式来减少持久化对 Redis 性能的影响。同时，也需要关注 Redis 的监控和调优，及时发现和解决性能问题。

您所描述的是 Redis 的混合持久化机制，它结合了 RDB（Redis Database）快照和 AOF（Append Only File）日志的优点。下面是对这一机制的详细分析：

5 混合持久化机制（RDB+AOF）

5.1 开启混合方式设置

在 Redis 配置文件中（通常是 redis.conf），可以通过设置 aof-use-rdbc 的值为 yes 来启用混合持久化。当设置为 yes 时，表示开启混合持久化；当设置为 no 时，表示禁用，此时 Redis 将只使用 AOF 或 RDB 单一持久化方式。

5.2 RDB+AOF 的混合方式

• RDB 镜像做全量持久化：

  • 在混合持久化过程中，首先会生成一个 RDB 格式的快照，这个快照包含了当前 Redis 内存中的所有数据。
  • RDB 快照是压缩和二进制格式的，因此它非常紧凑且易于传输和备份。

• AOF 做增量持久化：

  • 在生成 RDB 快照之后，Redis 会继续以 AOF 格式记录所有的写操作。
  • 这些写操作会追加到 AOF 文件中，从而确保在快照生成之后发生的数据变更不会丢失。

• 重写策略：

  • 当 AOF 文件变得过大或满足其他重写条件时，Redis 会触发 AOF 重写机制。
  • 在混合持久化模式下，重写后的文件仍然以 RDB 格式开头，后面跟着 AOF 格式的增量操作。
  • 这样做的目的是在保持数据完整性的同时，减少 AOF 文件的大小并提高恢复性能。

5.3 数据恢复过程

• 当 Redis 服务重启时，它会首先加载混合持久化文件。
• 由于文件以 RDB 格式开头，Redis 会先读取并加载 RDB 快照，从而快速恢复大部分数据。
• 接着，Redis 会继续读取并应用 AOF 文件中的增量操作，以确保数据的完整性和一致性。

5.4 优点与缺点

• 优点：

  • 混合持久化结合了 RDB 和 AOF 的优点，既能够快速恢复数据（通过 RDB 快照），又能够确保数据不丢失（通过 AOF 增量操作）。
  • 相对于单一的 RDB 或 AOF 持久化方式，混合持久化在数据恢复性能和数据完整性方面都有更好的表现。

• 缺点：

  • 混合持久化文件可能比单一的 RDB 或 AOF 文件更大，因为它同时包含了 RDB 快照和 AOF 增量操作。
  • 在某些情况下，混合持久化可能会增加 Redis 的写操作延迟，因为需要同时维护 RDB 快照和 AOF 日志。

总的来说，混合持久化是一种非常有效的 Redis 数据持久化方式，它能够在保证数据完整性的同时提高恢复性能。然而，是否使用混合持久化还需要根据具体的业务需求和 Redis 服务器的性能情况进行权衡。