枫秀学习日志

枫秀学习日志

0%

redis之过期策略

发表于 分类于 Disqus： Valine：
本文字数： 5.8k 阅读时长 ≈ 5 分钟

过期时间的基本操作

Redis有四个不同的命令可以用于设置键的生存时间（键可以存在 多久）或过期时间（键什么时候会被删除）：

  • EXPIRE <key> <ttl>命令用于将键key的生存时间设置为ttl秒。
  • PEXPIRE <key> <ttl>命令用于将键key的生存时间设置为ttl毫秒。
  • EXPIREAT <key> <timestamp>命令用于将键key的过期时间设置为 timestamp所指定的秒数时间戳。
  • PEXPIREAT <key> <timestamp>命令用于将键key的过期时间设置为 timestamp所指定的毫秒数时间戳。

虽然有多种不同单位和不同形式的设置命令，但实际上EXPIRE、 PEXPIRE、EXPIREAT三个命令都是使用PEXPIREAT命令来实现的： 无论客户端执行的是以上四个命令中的哪一个，经过转换之后，最终的执行效果都和执行PEXPIREAT命令一样。

设置过期时间

保存过期时间
redis数据库使用字典保存了数据库中所有键的过期时间，称这个字典为过期字典：

  • 过期字典的键是一个指针，这个指针指向键空间中的某个键对象 （也即是某个数据库键）。
  • 过期字典的值是一个long long类型的整数，这个整数保存了键所指 向的数据库键的过期时间——一个毫秒精度的UNIX时间戳。

移除过期时间
PERSIST命令可以移除一个键的过期时间，PERSIST命令就是PEXPIREAT命令的反操作：PERSIST命令在过期 字典中查找给定的键，并解除键和值（过期时间）在过期字典中的关联。

计算并返回剩余生存时间
TTL命令以秒为单位返回键的剩余生存时间，而PTTL命令则以毫秒为单位返回键的剩余生存时间。

过期键的判定
通过过期字典，程序可以用以下步骤检查一个给定键是否过期：

  1. 检查给定键是否存在于过期字典：如果存在，那么取得键的过 期时间。
  2. 检查当前UNIX时间戳是否大于键的过期时间：如果是的话，那 么键已经过期；否则的话，键未过期。

过期删除策略

目前有的过期删除策略有以下三种

  • 定时删除：在设置键的过期时间的同时，创建一个定时器 （timer），让定时器在键的过期时间来临时，立即执行对键的删除操 作。
  • 惰性删除：放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键；如果没有过期， 就返回该键。
  • 定期删除：每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。

在这三种策略中，第一种和第三种为主动删除策略，而第二种则为被动删除策略。

定时删除策略对内存是最友好的：通过使用定时器，定时删除策略可以保证过期键会尽可能快地被删除，并释放过期键所占用的内存。
另一方面，定时删除策略的缺点是，它对CPU时间是最不友好的： 在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU时间，在内存不紧张但是CPU时间非常紧张的情况下，将CPU时间用在删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响前不缺少内存，那么服务器应该优先将CPU时间用在处理客户端的命令请求上面，而不是用在删除过期键上面。

除此之外，创建一个定时器需要用到Redis服务器中的时间事件， 而当前时间事件的实现方式——无序链表，查找一个事件的时间复杂度 为O（N）——并不能高效地处理大量时间事件。 因此，要让服务器创建大量的定时器，从而实现定时删除策略，在 现阶段来说并不现实。

惰性删除策略对CPU时间来说是最友好的：程序只会在取出键时才 对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情 况下进行，并且删除的目标仅限于当前处理的键，这个策略不会在删除 其他无关的过期键上花费任何CPU时间。 惰性删除策略的缺点是，它对内存是最不友好的：如果一个键已经 过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删 除，它所占用的内存就不会释放。 在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些 过期键又恰好没有被访问到的话，那么它们也许永远也不会被删除（除 非用户手动执行FLUSHDB），我们甚至可以将这种情况看作是一种内存泄漏——无用的垃圾数据占用了大量的内存，而服务器却不会自己去 释放它们，这对于运行状态非常依赖于内存的Redis服务器来说，肯定不是一个好消息。

定期删除从上面对定时删除和惰性删除的讨论来看，这两种删除方式在单一使用时都有明显的缺陷：

  • 定时删除占用太多CPU时间，影响服务器的响应时间和吞吐量。
  • 惰性删除浪费太多内存，有内存泄漏的危险。

定期删除策略是前两种策略的一种整合和折中：

  • 定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。
  • 除此之外，通过定期删除过期键，定期删除策略有效地减少了因 为过期键而带来的内存浪费。

定期删除策略的难点是确定删除操作执行的时长和频率：

  • 如果删除操作执行得太频繁，或者执行的时间太长，定期删除策 略就会退化成定时删除策略，以至于将CPU时间过多地消耗在删除过期 键上面。
  • 如果删除操作执行得太少，或者执行的时间太短，定期删除策略 又会和惰性删除策略一样，出现浪费内存的情况。 因此，如果采用定期删除策略的话，服务器必须根据情况，合理地 设置删除操作的执行时长和执行频率。

Redis的过期键删除策略

Redis服务器实际使用的是惰性删除和定期删除两种策略： 通过配合使用这两种删除策略，服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。

惰性删除
过期键的惰性删除策略由expireIfNeeded函数实现，所有读写数据库的Redis命令在执行之前都会调用expireIfNeeded函数对输入键进行检查：

  • 如果输入键已经过期，那么expireIfNeeded函数将输入键从数据库 中删除。
  • 如果输入键未过期，那么expireIfNeeded函数不做动作。
    命令调用expireIfNeeded函数的过程如图9-15所示。

命令执行过程

expireIfNeeded函数就像一个过滤器，它可以在命令真正执行之前，过滤掉过期的输入键，从而避免命令接触到过期键。 另外，因为每个被访问的键都可能因为过期而被expireIfNeeded函数删除，所以每个命令的实现函数都必须能同时处理键存在以及键不存 在这两种情况：

  • 当键存在时，命令按照键存在的情况执行。
  • 当键不存在或者键因为过期而被expireIfNeeded函数删除时，命令 按照键不存在的情况执行。

定期删除策略
定期删除的时机是由redis服务器的周期任务来调用，每当调用的时候，定期删除任务或在规定的时间内，分多次遍历服务器中的各个数据库，从数据库的expires字典中随机检查一部分键的过 期时间，并删除其中的过期键。 整个过程可以用伪代码描述如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# 默认每次检查的数据库数量 
DEFAULT_DB_NUMBERS = 16 

# 默认每个数据库检查的键数量 
DEFAULT_KEY_NUMBERS = 20 

#全局变量，记录检查进度 
current_db = 0 

def activeExpireCycle(): 
    # 初始化要检查的数据库数量 
    # 如果服务器的数据库数量比DEFAULT_DB_NUMBERS要小 
    # 那么以服务器的数据库数量为准
    if server.dbnum < DEFAULT_DB_NUMBERS:
            db_numbers = server.dbnum 
    else:
        db_numbers = DEFAULT_DB_NUMBERS 
    # 遍历各个数据库 
    for i in range(db_numbers): 
        # 如果current_db的值等于服务器的数据库数量 
        # 这表示检查程序已经遍历了服务器的所有数据库一次 
        #将current_db 重置为0 ，开始新的一轮遍历 
        if current_db == server.dbnum: 
            current_db = 0 
        # 获取当前要处理的数据库 
            redisDb = server.db[current_db] 
        # 将数据库索引增1 ，指向下一个要处理的数据库 current_db += 1 
        # 检查数据库键
        for j in range(DEFAULT_KEY_NUMBERS): 
            # 如果数据库中没有一个键带有过期时间，那么跳过这个数据库
            if redisDb.expires.size() == 0:
              break 
            # 随机获取一个带有过期时间的键 key_with_ttl = redisDb.expires.get_random_key() 
            # 检查键是否过期，如果过期就删除它
             if is_expired(key_with_ttl): 
                 delete_key(key_with_ttl) 
             # 已达到时间上限，停止处理 
             if reach_time_limit():
                 return

activeExpireCycle函数的工作模式可以总结如下：

  1. 函数每次运行时，都从一定数量的数据库中取出一定数量的随机 键进行检查，并删除其中的过期键。
  2. 全局变量current_db会记录当前activeExpireCycle函数检查的进度， 并在下一次activeExpireCycle函数调用时，接着上一次的进度进行处理。比如说，如果当前activeExpireCycle函数在遍历10号数据库时返回 了，那么下次activeExpireCycle函数执行时，将从11号数据库开始查找 并删除过期键
  3. 随着activeExpireCycle函数的不断执行，服务器中的所有数据库都 会被检查一遍，这时函数将current_db变量重置为0，然后再次开始新一 轮的检查工作

AOF、RDB和复制功能对过期键的处理

RDB处理

生成RDB文件在执行SAVE命令或者BGSAVE命令创建一个新的RDB文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的RDB文件中。
举个例子，如果数据库中包含三个键k1、k2、k3，并且k2已经过期，那么当执行SAVE命令或者BGSAVE命令时，程序只会将k1和k3的数据保存到RDB文件中，而k2则会被忽略。 因此，数据库中包含过期键不会对生成新的RDB文件造成影响。
载入RDB文件 在启动Redis服务器时，如果服务器开启了RDB功能，那么服务器 将对RDB文件进行载入：

  • 如果服务器以主服务器模式运行，那么在载入RDB文件时，程序会对文件中保存的键进行检查，未过期的键会被载入到数据库中，而过期键则会被忽略，所以过期键对载入RDB文件的主服务器不会造成影响。
  • 如果服务器以从服务器模式运行，那么在载入RDB文件时，文件中保存的所有键，不论是否过期，都会被载入到数据库中。不过，因为主从服务器在进行数据同步的时候，从服务器的数据库就会被清空，所以一般来讲，过期键对载入RDB文件的从服务器也不会造成影响。 举个例子，如果数据库中包含三个键k1、k2、k3，并且k2已经过期，那么当服务器启动时：
    • 如果服务器以主服务器模式运行，那么程序只会将k1和k3载入到 数据库，k2会被忽略。
    • 如果服务器以从服务器模式运行，那么k1、k2和k3都会被载入到 数据库。

AOF处理

AOF文件写入 当服务器以AOF持久化模式运行时，如果数据库中的某个键已经过期，但它还没有被惰性删除或者定期删除，那么AOF文件不会因为这个过期键而产生任何影响。 当过期键被惰性删除或者定期删除之后，程序会向AOF文件追加 （append）一条DEL命令，来显式地记录该键已被删除。
举个例子，如果客户端使用GET message命令，试图访问过期的 message键，那么服务器将执行以下三个动作：

  1. 从数据库中删除message键。
  2. 追加一条DEL message命令到AOF文件。
  3. 向执行GET命令的客户端返回空回复。

AOF重写和生成RDB文件时类似，在执行AOF重写的过程中，程序会对数据库中的键进行检查，已过期的键不会被保存到重写后的AOF文件中。 举个例子，如果数据库中包含三个键k1、k2、k3，并且k2已经过 期，那么在进行重写工作时，程序只会对k1和k3进行重写，而k2则会被 忽略。因此，数据库中包含过期键不会对AOF重写造成影响

主从模式下过期主键处理

主从节点对于过期主键的处理策略
当服务器运行在复制模式下时，从服务器的过期键删除动作由主服务器控制：

  • 主服务器在删除一个过期键之后，会显式地向所有从服务器发送 一个DEL命令，告知从服务器删除这个过期键。
  • 从服务器在执行客户端发送的读命令时，主要有俩种处理模式大于3.2版本的会判断当前主键是否过期，如果过期则返回不存在，小于3.2的版本，即使碰到过期键也不会将过期键删除，而是继续像处理未过期的键一样来处理过期键。
  • 从服务器只有在接到主服务器发来的DEL命令之后，才会删除过期键

通过由主服务器来控制从服务器统一地删除过期键，可以保证主从服务器数据的一致性，也正是因为这个原因，当一个过期键仍然存在于主服务器的数据库时，这个过期键在从服务器里的复制品也会继续存在。

过期时间的处理
在设置过期时间，我们一般采用EXPIRE和PEXPIRE，表示从执行命令那个时刻开始，往后延长ttl 时间。严重依赖于开始时间从什么时候算起。
会出现下面这样一种情况

  1. 主库在t1时刻写入一个带过期时间的数据，数据的有效期一直到
  2. t3由于网络原因、或者缓存服务器的执行效率，从库的命令并没有立即执行。一直等到了t2才开始执行， 数据的有效期则会延后到 t5
  3. 如果，此时客户端访问从库，发现数据依然处于有效期内，可以正常使用

解决方案可以采用Redis的另外两个命令，EXPIREAT和 PEXPIREAT，相对简单，表示过期时间为一个具体的时间点。避免了对开始时间从什么时候算起的依赖。

但是这里统一有一个问题，EXPIREAT和PEXPIREAT设置的是时间点，依赖于当前服务器的时钟，如果俩个服务器的时钟不一致，就会导致过期时间发生的点不一致，所以，主从节点上的时钟要保持一致，具体的做法是，让主从节点和相同的NTP服务器（时间服务器）进行时钟同步。

参考

1Redis的Key过期问题处理

相关文章推荐