向爬虫而生---Redis 拓宽篇5 ＜redis持久化 --- AOF章＞

前言:

继上一篇:https://blog.csdn.net/m0_56758840/article/details/135439319

这次来讲一下AOF...

正文:

什么是AOF

AOF（Append-only file）是Redis中的一种持久化方式，用于记录每个写操作的日志。与快照持久化不同，AOF持久化以日志追加的方式将写操作记录到一个文件中，这个文件按顺序记录了所有修改数据的命令。通过读取AOF文件并重新执行其中的命令，Redis可以还原数据库的状态。

AOF持久化的原理

1. Redis服务器将每个修改数据的命令追加到AOF文件的末尾，形成一系列有序的命令日志。
2. Redis会在每次执行写操作之后，将该命令追加到AOF缓冲区中，并异步地将缓冲区内容写入AOF文件。
3. 当Redis需要重启时，它会遍历并重新执行AOF文件中的所有命令，从而还原数据库的状态。

相较于快照(RDB)持久化，AOF持久化具有以下优点：

1. 数据更加持久：AOF持久化记录了每个写操作的命令日志，并以追加方式保存到文件中。在Redis服务器重启时，可以通过重新执行这些命令来完整地还原数据库的状态，从而减少数据丢失的风险。

2. 更高的数据安全性：由于AOF持久化记录了完整的命令流，它提供了更高的数据安全性。在发生故障或断电时，Redis可以依靠AOF文件来恢复数据。

3. 灵活的恢复和回滚：通过查看和修改AOF文件中的命令，可以实现对数据库的灵活恢复和回滚操作。

PS: AOF持久化方式相对于快照持久化而言，可能会占用更多的磁盘空间，并且由于每个写操作都需要追加到AOF文件中，写操作会产生一定的性能开销。

配置AOF

在Redis的配置文件中，可以通过配置 appendonly yes来启用AOF持久化。

AOF的三种策略

当配置AOF持久化时，Redis提供了三种不同的AOF（Append-only file）策略，即always、everysec和no。这些策略控制着Redis将AOF缓冲区的内容写入磁盘的频率，从而提供了不同级别的持久化和性能权衡。

1. always（默认策略）：每次Redis执行写操作后，都会将AOF缓冲区的内容立即写入磁盘。这是最安全的选择，因为最小化了数据丢失的风险，但也会带来损失一定性能的代价。

2. everysec：Redis会每秒将AOF缓冲区的内容异步地写入磁盘。这意味着写操作在发生时会先写入AOF缓冲区，然后等待1秒后才将缓冲区的内容写入磁盘。这种方式在数据安全性和性能之间达到了一个平衡，可以减少写入磁盘的次数，提高写操作的吞吐量。

3. no：Redis完全依赖操作系统来处理数据同步到磁盘的工作。这意味着Redis将写入磁盘的频率完全依赖于操作系统的策略。虽然这样可能会提供更好的性能，但也增加了数据丢失的风险，因为在发生故障时，可能会丢失最近的一些写操作。

如何配置AOF策略:

这些AOF策略可以在Redis配置文件（redis.conf）中进行设置。

appendonly yes
appendfsync always

在这个例子中，always策略被启用，表示每次写操作后都会立即将AOF缓冲区的内容同步到磁盘。

三种策略的比较

当比较AOF的三种策略（always、everysec和no）时，主要要考虑的因素是数据安全性和性能。以下是这三种策略的比较：

always（始终同步策略）：

• 数据安全性：使用always策略，Redis会在每次写操作后立即将AOF缓冲区的内容同步到磁盘。这意味着即使在发生故障时，也能最小化数据丢失的风险。这是最安全的策略，对于对数据安全性有严格要求的环境是首选。
• 性能：always策略会在每次写操作后都触发磁盘写入，这会导致相对较低的性能。磁盘写入操作通常比内存操作慢得多，因此可能对写操作的吞吐量产生一定的影响。

everysec（每秒同步策略）：

• 数据安全性：使用everysec策略，Redis会每秒异步将AOF缓冲区的内容写入磁盘。这意味着写操作在发生时会先写入AOF缓冲区，然后等待1秒后再将缓冲区的内容同步到磁盘。这种策略在数据安全性和性能之间达到了一定的平衡。
• 性能：相对于always策略，everysec策略可以减少磁盘同步的频率，从而提高写操作的吞吐量。这是一种较为流行的策略，适用于需要在一定程度上提高性能同时保持合理的数据安全性的场景。

no（不同步策略）：

• 数据安全性：使用no策略，Redis完全依赖操作系统来处理数据同步到磁盘的工作。这意味着Redis不对磁盘同步进行显式控制，而是完全依赖操作系统默认的同步策略。这种方式提供了最佳的性能，但也带来了较高的数据丢失风险。
• 性能：no策略提供了最高的性能，因为Redis不需要等待磁盘写入完成。这种策略适合于对性能要求较高，同时可以容忍一些数据丢失的场景。但需要注意的是，这种方式下数据是不可恢复的。

ps:  选择适合自己应用场景的AOF策略需要权衡数据安全性和性能。如果对数据安全性要求高，可以使用always或everysec策略；如果对性能要求高且可以容忍一定的数据丢失，可以考虑使用no策略。

AOF的重写 

AOF的重写（AOF Rewrite）是Redis中一种优化AOF文件大小和性能的机制。AOF Rewrite通过创建一个新的AOF文件来代替现有的AOF文件，从而实现对AOF文件的压缩和重建。

AOF Rewrite重写的过程

1. 后台进程启动：Redis会启动一个后台进程，负责执行AOF Rewrite操作。

2. 读取现有AOF文件：后台进程会读取现有的AOF文件，将其中的写命令进行解析，并将过期或重复的命令过滤掉。

3. 重建新AOF文件：后台进程会将过滤后的命令按顺序重新写入一个新的AOF文件，并以压缩的方式存储，从而减小AOF文件的大小。

4. 切换到新AOF文件：当新AOF文件重建完成后，Redis会将AOF重写进程的输出缓冲区与新AOF文件交换，然后切换到新的AOF文件。

AOF Rewrite重写的好处

1. 压缩AOF文件：由于AOF文件包含了每个写操作的完整命令，随着时间的推移，AOF文件会变得越来越大。通过重写AOF文件，可以去除过期和重复的命令，从而减小AOF文件的大小，节省磁盘空间。

2. 提高AOF加载性能：AOF文件重写后，新的AOF文件只包含了必要的写命令，不会存在过期或重复的命令。因此，加载新的AOF文件速度更快，从而提高了Redis启动时的性能。

ps : AOF Rewrite是一个耗时和资源密集型的操作。因此，为了避免对主线程的影响，AOF Rewrite是在后台进行，并且Redis通过后台子进程来执行重写操作，不会阻塞正常的命令处理。

重写配置

在Redis配置文件中，有几个与AOF重写（AOF Rewrite）相关的选项可供配置。

1. auto-aof-rewrite-percentage:

   • 默认值：100
   • 该选项指定了AOF文件当前大小与最近重写过的AOF文件大小之间的百分比差值。当AOF文件的当前大小超过最近重写文件大小的指定百分比时，Redis会自动触发AOF Rewrite。
   • 例如，如果设置为100，表示当前AOF文件大小达到之前重写AOF文件大小的两倍时，会启动自动的AOF Rewrite。
   • 如果你想完全禁用自动AOF Rewrite，可以将该选项的值设置为0。

2. auto-aof-rewrite-min-size:

   • 默认值：64MB
   • 该选项指定了触发自动AOF Rewrite的最小AOF文件大小阈值。只有当AOF文件的大小超过指定大小时，Redis才会自动触发AOF Rewrite。
   • 例如，如果设置为64MB，只有当AOF文件的大小超过64MB时，才会自动触发AOF Rewrite。
   • 如果你想禁用AOF Rewrite的最小大小限制，可以将该选项的值设置为0。

通过配置这些选项，可以自动触发AOF Rewrite以优化AOF文件的大小和性能。自动触发可以避免手动触发AOF Rewrite的繁琐，并确保AOF文件得到合理的维护和压缩。

ps:AOF Rewrite是一个资源密集型的操作，因此在生产环境中，建议在高负载低峰期执行AOF Rewrite，以避免对Redis性能的影响。

AOF自动触发时机.

AOF（Append-only file）自动触发是在Redis中根据一定条件自动执行AOF重写操作。AOF自动触发的时机取决于两个主要的配置选项：auto-aof-rewrite-percentage和auto-aof-rewrite-min-size。

当满足以下条件之一时，Redis会自动触发AOF重写：

1. 当auto-aof-rewrite-percentage选项设置为非零值时，且当前AOF文件大小超过最近重写文件大小的指定百分比阈值。
2. 当auto-aof-rewrite-min-size选项设置为非零值时，且当前AOF文件大小超过指定的最小AOF文件大小阈值。

ps:自动触发AOF重写是在后台进行的，并且由Redis的后台子进程负责执行。这样可以避免对Redis主线程的影响和阻塞。   你可以根据自己的需求和对AOF文件大小的控制，选择适当的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size的值来配置AOF的自动触发时机。

额外补充---统计项:

在Redis中，统计项是用于收集和监控不同方面的性能指标和统计信息的功能。它们提供了对Redis实例的运行状况、资源使用情况和性能表现等方面的实时数据，用于分析和优化Redis的运行。

常见的统计项及其用途：

1. Keyspace Stats：键空间统计项提供了对Redis数据库中键的分布和使用情况的统计信息。它包括键的数量、过期键的数量、类型分布、内存使用等。这些统计信息可以帮助你了解数据库的大小、键的存储情况和内存使用情况，以及对于缓存数据来说，缓存命中率等。

2. Memory Stats：内存统计项提供了关于Redis实例内存使用情况的统计信息。它包括Redis实例使用的总内存量、内存碎片化、内存分配器信息等。这些统计信息可以帮助你监控和优化Redis的内存使用情况，识别内存相关问题，以及评估Redis实例的内存需求。

3. CPU Stats：CPU统计项提供了关于Redis实例CPU使用情况的统计信息。它包括Redis进程的CPU占用率、命令执行时间等。通过这些统计信息，你可以了解Redis在处理命令时的CPU消耗情况，帮助你识别潜在的性能瓶颈或高CPU使用情况。

4. Replication Stats：复制统计项提供了与Redis复制相关的统计信息，包括主从角色、同步状态、从节点延迟等。这些统计信息可以帮助你监控和调试Redis复制的状态和性能，以及识别潜在的复制问题。

要使用这些统计项，你可以通过Redis的命令行界面（CLI）或使用Redis的监控工具（如RedisInsight、Redis-Stat、Redis-Dashboard等）来获取和监控这些统计信息。这些工具能够提供可视化的界面，让你更方便地查看和分析统计数据。

配置统计项通常不需要进行额外的配置，因为Redis默认会收集这些统计信息。但是，你可以根据需要进行定制化的配置。例如，你可以使用CONFIG SET命令来启用或禁用特定类型的统计项，并通过修改Redis配置文件中的参数来调整统计项的采样频率或其他相关设置。

总结:

在项目中,为了满足开销尽量小,且维护好数据的安全性,我推荐这个方案:

1. 只使用AOF持久化：

   • 如果你对数据安全性的要求不是特别高，可以只启用AOF持久化，而不使用RDB持久化。这样可以降低持久化过程中的开销和磁盘空间消耗。

2. 调整AOF持久化策略：

   • 使用everysec选项代替默认的always选项。这样可以降低AOF持久化操作对性能的影响，每秒同步一次数据到磁盘。
   • 调整auto-aof-rewrite-percentage和auto-aof-rewrite-min-size选项的阈值。通过增大阈值，可以减少AOF重写的频率，从而降低开销。

3. 调整RDB持久化策略：

   • 调整save选项的条件，减少RDB持久化的频率。你可以更长的时间间隔进行RDB持久化，以降低落盘的频率和开销。 (例如,每天到某个时段,保存一次!)