Redis中的过期删除与内存淘汰

1.Redis中的过期删除策略

在 Redis 中，过期删除策略是为了管理存储在 Redis 中的带有过期时间的数据。每当数据存储时，可能会为其设定一个过期时间。当到达这个时间点后，该数据就被标记为"过期"。为了确保不再需要的过期数据不会占用系统资源，Redis 会通过过期删除策略来移除它们。

1. 1惰性删除策略

什么是惰性删除策略？

惰性删除策略的意思是，Redis 不会主动去检查所有键是否过期，而是等到用户访问一个键时才去检查它是否已经过期。如果 Redis 在访问这个键时发现它已经过期了，就会立即删除这个键，并返回一个"键不存在"的结果。

通俗地说 ，惰性删除策略就像是"按需检查"。就好比在图书馆里，管理员不会逐一检查每本书是否过期，而是等到有人去借某本书时，才去检查这本书的借阅期限。只有发现过期了，管理员才会收回这本书。

惰性删除的优缺点：

• 优点：惰性删除不占用额外资源来检查键的状态，节省了系统性能。
• 缺点：如果某些键长期无人访问，那么即便它们过期了也不会被删除，依然会占用内存。

1.2 定期删除策略

什么是定期删除策略？

定期删除策略是一种 Redis 主动定期检查键是否过期的方式。Redis 会每隔一段时间（比如默认每秒）抽样检查一些带有过期时间的键。如果发现某些键已经过期，它会立即删除这些键。注意，这种检查并不是遍历所有键，而是从带有过期时间的键中随机抽样一部分来检查。

通俗地说 ，定期删除策略就像是"定期抽查"。假设图书管理员每隔一段时间，随便检查一部分书籍，看看它们的借阅期限是否过期。如果发现某本书过期了，管理员就把它收回。这样可以减少无用的过期数据。

定期删除的优缺点：

• 优点：相比惰性删除策略，它能及时清除一部分无用的过期数据，避免内存占用过多。
• 缺点：定期删除策略无法保证每次都能检查到所有过期数据，因此依然会有一些过期但未被清除的数据留在内存中。此外，如果检查频率太高，也会影响系统性能。

2.Redis 持久化中过期键的策略

当 Redis 数据持久化到硬盘上时，有可能会遇到一些带有过期时间的数据。这时，Redis 如何处理这些过期键，取决于你使用的是哪种持久化格式。我们从 RDB 持久化格式 和 AOF 持久化格式 两方面分别讲解。

2.1 RDB 文件

2.1.1 RDB 文件生成阶段

当 Redis 触发 RDB 文件生成时，会将内存中的数据快照写入到 RDB 文件。在生成 RDB 文件时，Redis 会对键的过期时间进行检查，确保只把有效的、未过期的数据写入文件。因此，如果一个键已经过期，Redis 会直接跳过这个键，不会将它写入 RDB 文件。这种处理方式避免了过期键被保存到持久化文件中，节省了存储空间。

• 例子：假设键 "session:12345" 已经过期，那么在 RDB 文件生成时，Redis 检查到它已经过期，会将该键从快照中剔除，不写入 RDB 文件。

• 优缺点：

  • 优点：RDB 文件不会保存过期的数据，文件体积更小，且避免了加载过期数据的情况。
  • 缺点：RDB 文件生成过程稍微增加了检查过期时间的开销。

2.2.2 RDB 文件加载阶段

当 Redis 重启并加载 RDB 文件时，主服务器和从服务器会有不同的过期键处理逻辑：

• 主服务器 ：在主服务器上加载 RDB 文件时，会对每个键进行过期检查，如果发现某个键已经过期了，Redis 会直接跳过，不将其加载到内存中。这样可以确保主服务器只加载有效的数据。

• 从服务器：在从服务器加载 RDB 文件时，Redis 不会进行过期检查。即使某些键在从服务器看来已过期，它们依旧会被加载到内存中。这个处理方式是为了让从服务器的数据状态与主服务器保持一致。在主服务器上，过期键删除的操作会同步到从服务器，确保最终数据的一致性。

• 例子：假设 RDB 文件包含一个键 "user

  "，它的过期时间是今天中午。如果在今天下午重启主服务器，主服务器会检测到这个键已过期，直接跳过加载它。而从服务器则会无条件加载该键，并等待从主服务器同步删除指令。

• 优缺点：

  • 优点：主服务器能够自动清理过期键，避免加载到内存中；从服务器则确保与主服务器的状态一致。
  • 缺点：从服务器加载过期键可能会消耗内存，直到主服务器的同步删除命令生效。

2.2 AOF 文件

2.2.1 AOF 文件写入阶段

在 Redis 处理 AOF 持久化时，每次执行写操作，Redis 会把命令追加到 AOF 文件中。对于有过期时间的键，当它过期并被删除时，Redis 会在 AOF 文件中追加一条 DEL 命令。这条命令标记了该键的删除，确保 AOF 文件反映当前的内存状态。

• 例子 ：假设 Redis 在某次访问中发现键 "session:456" 已经过期并执行删除操作，那么 Redis 会将 DEL session:456 命令追加到 AOF 文件中。下次重启时，AOF 文件会根据这条命令删除过期键。

• 优缺点：

  • 优点：AOF 文件可以及时反映键的过期状态，重启后保证只加载有效数据。
  • 缺点：AOF 文件会随着每次操作变大，但可通过重写机制优化。

2.2.2 AOF 文件重写阶段

为了避免 AOF 文件过大，Redis 提供了 AOF 文件重写机制。重写时，Redis 会基于当前内存数据生成一个新的 AOF 文件。对于已经过期的数据，不会将它们写入新的 AOF 文件。这样，新生成的 AOF 文件就只包含当前有效的数据，不会带有任何过期数据。

• 例子：假设键 "cache

  " 在内存中已经过期，则在 AOF 文件重写时，Redis 会忽略该键，不会将它写入新的 AOF 文件。

• 优缺点：

  • 优点：重写后的 AOF 文件更加精简，没有过期数据，占用的磁盘空间较小。
  • 缺点：重写过程中会占用一些系统资源，不过能够大幅减少 AOF 文件体积。

3.Redis 主从模式中过期键的处理

在 Redis 的主从复制结构下，主库和从库的过期机制是这样分配的：

1. 主库（Master） ：主库会定期检查和删除已过期的键，通过主动过期扫描和惰性过期检查来清理过期数据。主库删除一个键时，会在 AOF 文件或复制流中加入一条 DEL 指令，并同步给从库。这意味着从库会接收到这条 DEL 指令，从而清除相应的过期键。

2. 从库（Slave） ：从库不会进行主动的过期扫描，也不主动检查过期键的状态。它只是被动地接收来自主库的 DEL 指令，并删除相应的键。这种被动删除的机制确保了主从库在键的状态上始终保持一致。

3. 被动删除的触发：当从库响应客户端的读请求时，如果请求到的是一个过期键（此键在从库上未被主动删除），从库并不会直接删除它，而是仍然返回数据。因为主从复制的核心目标是保持数据的一致性，而非数据的新鲜度；从库的数据主要用于高效地进行读操作，而不是清理过期键。

总结来说，从库依赖于主库的过期删除通知来清理过期键，从而减少过期检查带来的资源消耗，并最大限度地保证主从数据一致。

4.Redis的内存淘汰机制

4.1Redis 的八种内存淘汰策略

1. noeviction：不淘汰任何键。当内存满了之后，写操作会返回错误，不允许新增数据。

2. volatile-random：只从设置了过期时间的键中随机淘汰一个键，以释放内存。

3. volatile-ttl：只从设置了过期时间的键中淘汰生存时间（TTL）最短的键。即选择即将到期的键进行淘汰。

4. volatile-lru：只从设置了过期时间的键中淘汰最近最少使用的键（LRU 策略）。

5. volatile-lfu：只从设置了过期时间的键中淘汰最少使用的键（LFU 策略）。

6. allkeys-random：从所有键中随机淘汰一个键，不论是否设置了过期时间。

7. allkeys-lru：从所有键中淘汰最近最少使用的键（LRU 策略），不论是否设置了过期时间。

8. allkeys-lfu：从所有键中淘汰最少使用的键（LFU 策略），不论是否设置了过期时间。

4.2 LRU 和 LFU 算法的区别

• LRU（Least Recently Used） ：即最近最少使用 ，关注的是数据的"最近访问时间"。如果数据很久没有被访问过，系统认为它的再利用可能性较低，因此优先被淘汰。换句话说，越久没被访问的键，越容易被淘汰。

• LFU（Least Frequently Used） ：即最少使用 ，关注的是数据的"访问频率"。如果一个键的访问频率很低，则系统认为它的重要性较低，可以优先淘汰。因此，那些被访问次数少的数据更容易被淘汰。

总结：

• LRU 适合短期内访问频率波动较大的数据，因为它仅考虑"最近访问"。
• LFU 适合较长期、访问次数较为稳定的情况，因为它累计访问频率，而不是按时间优先。

4.3 什么是 LRU 算法？

LRU 算法的全称是"最近最少使用"算法。LRU 的基本理念是：

• 如果一个键最近被访问过，那么未来也更可能被访问。这种情况适用于很多缓存场景，因为短期访问有一定的连贯性。
• 反之，那些长时间没有被访问的数据很可能未来也不再需要，因此更适合被淘汰。

常见 LRU 实现方式：

• 一般可以通过链表来实现 LRU，将最近访问的节点移到表头，而长时间未访问的节点逐渐移向表尾，最终从表尾淘汰。

4.4 Redis 是如何实现 LRU 算法的？

Redis 的 LRU 实现并不严格，因为 Redis 强调高性能和轻量操作，严格实现 LRU 会消耗大量内存和时间，因此 Redis 采用了一种近似 LRU的方式：

1. 访问时间记录：每个键在 Redis 中都记录了最近一次访问的时间戳信息，这是一个 24 位的访问计数器，用来帮助 Redis 判断哪些键最近未被使用。这个计数器会在键被访问时更新。

2. 采样淘汰：

   • 当 Redis 达到内存上限时，它不会遍历所有键去找到最久未使用的键，而是采用随机采样的方式：从键空间中随机抽取一部分键（默认 16 个），然后从中找到最近最少访问的键进行淘汰。
   • 这种"采样"方法可以避免在键数量较大时遍历带来的性能开销，但仍然实现类似 LRU 的效果。

3. 可调采样数量 ：Redis 提供了 maxmemory-samples 参数来控制采样的键数量。例如，maxmemory-samples 的默认值是 5，即每次淘汰会随机抽取 5 个键，并从中选取最久未使用的键进行淘汰。采样数量越大，结果越接近严格 LRU，但会增加系统开销。

4.5 什么是 LFU 算法？

LFU 算法的全称是"最少使用"算法，核心思想是：

• 如果一个数据使用频率很低，那么它在未来再次使用的可能性较低，因此可以优先淘汰。
• 换句话说，历史访问频率低的数据，更适合被淘汰。适合访问次数稳定的场景。

与 LRU 不同，LFU 关注的是数据的访问频率 而非最近访问时间。LFU 更适合一些被长期且稳定访问的数据场景。

4.6 Redis 是如何实现 LFU 算法的？

Redis 中的 LFU 实现也采取了近似算法，并采用了"频率计数+衰减"的机制，具体分为以下几个要点：

1. 访问频率计数器：

   • 每个键在 Redis 中都有一个 8 位计数器，用于记录该键的访问频率，范围为 0 到 255。
   • Redis 并不会严格增加访问频率计数，而是采用概率增量。当键被访问时，计数器以一定概率递增，这样能防止访问频率高的键增长速度过快，避免少量高频数据长期占据空间，减少"垄断"现象。

2. 衰减机制：

   • LFU 中，访问频率会随着时间逐渐"遗忘"历史访问次数，避免"僵尸数据"问题（即过去访问频繁但长时间未被访问的键）。
   • Redis 设置了衰减机制，计数器会随时间按比例减少。这种逐渐减少的设计可以逐步将那些曾经高频但已长时间不被访问的数据淘汰出去。
   • Redis 会定期对这些计数值进行衰减，通常是在达到内存上限或频繁触发淘汰时进行衰减操作，从而避免低频访问的数据长期占据内存。