探密Redis中键的自动过期功能

在Redis的使用过程中,经常会遇到一些在特定时间之后就需要删除的数据,Redis提供了键的过期时间这个功能来解决这个问题。通过这个功能,可以让特定的键在指定的时间之后自动删除,而不需要手动执行删除操作。

设置键的生存时间或过期时间

通过EXPIRE命令或者PEXPIRE命令,客户端可以以秒或者毫秒精度为数据库中的某个键设置生存时间(TimeToLive,TTL),在经过指定的秒数或者毫秒数之后,服务器就会自动删除生存时间为0的键:

127.0.0.1:6379> set key value
OK
127.0.0.1:6379> expire key 5 //设置过期时间为5s
(integer) 1
127.0.0.1:6379> get key //5s之内执行
"value"
127.0.0.1:6379> get key //5s之后执行
(nil)
127.0.0.1:6379>
127.0.0.1:6379> set key value
OK
127.0.0.1:6379> pexpire key 5000 //设置过期时间为5000ms
(integer) 1
127.0.0.1:6379> get key //5000ms之内执行
"value"
127.0.0.1:6379> get key //5000ms之后执行
(nil)
127.0.0.1:6379>

SETEX命令可以在设置一个字符串键的同时为键设置过期时间,其原理与EXPIRE命令设置过期时间的原理是完全一样的。

EXPIREAT命令或PEXPIREAT命令,以秒或者毫秒精度给数据库中的某个键设置过期时间(expire time),过期时间是一个UNIX时间戳,当键的过期时间来临时,服务器就会自动从数据库中删除这个键:

127.0.0.1:6379> set key value
OK
127.0.0.1:6379> time
1) "1563250186"
2) "495791"
127.0.0.1:6379> expireat key 1563250199
(integer) 1
127.0.0.1:6379> get key
"value"
127.0.0.1:6379> get key
(nil)
127.0.0.1:6379>

TTL命令和PTTL命令接受一个带有生存时间或者过期时间的键,返回这个键的剩余生存时间,也就是,返回距离这个键被服务器自动删除还有多长时间:

127.0.0.1:6379> set key value
OK
127.0.0.1:6379> expire key 100 //设置过期时间为100s
(integer) 1
127.0.0.1:6379> ttl key
(integer) 95
127.0.0.1:6379> pttl key
(integer) 90167
127.0.0.1:6379> pttl key
(integer) -2
127.0.0.1:6379> set key value
OK
127.0.0.1:6379> time
1) "1563250520"
2) "97708"
127.0.0.1:6379> expireat key 1563250550 //设置过期时间为30s以后
(integer) 1
127.0.0.1:6379> ttl key
(integer) 13
127.0.0.1:6379> ttl key
(integer) 10
127.0.0.1:6379> ttl key
(integer) 2
127.0.0.1:6379> ttl key
(integer) -2

设置过期时间

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命令一样。

EXPIRE命令转换成PEXPIRE命令:

def EXPIRE(key,ttl_in_sec):    
    #将TTL从秒转换成毫秒    
    ttl_in_ms = sec_to_ms(ttl_in_sec)    
    PEXPIRE(key, ttl_in_ms)

PEXPIRE命令转换成PEXPIREAT命令:

def PEXPIRE(key,ttl_in_ms):    
    #获取以毫秒计算的当前UNIX时间戳    
    now_ms = get_current_unix_timestamp_in_ms()    
    #当前时间加上TTL,得出毫秒格式的键过期时间    
    PEXPIREAT(key,now_ms+ttl_in_ms)

EXPIREAT命令转换成PEXPIREAT命令:

def EXPIREAT(key,expire_time_in_sec):
    # 将过期时间从秒转换为毫秒    
    expire_time_in_ms = sec_to_ms(expire_time_in_sec)    
    PEXPIREAT(key, expire_time_in_ms)

最终,EXPIRE、PEXPIRE和EXPIREAT三个命令都会转换成PEXPIREAT命令来执行:

保存过期时间

redisDb结构的expires字典保存了数据库中所有键的过期时间,这个字典称为过期字典:

  • 过期字典的键是一个指针,这个指针指向键空间中的某个键对象(也即是某个数据库键)。
  • 过期字典的值是一个longlong类型的整数,这个整数保存了键所指向的数据库键的过期时间——一个毫秒精度的UNIX时间戳。
/* Redis database representation. There are multiple databases identified
 * by integers from 0 (the default database) up to the max configured
 * database. The database number is the 'id' field in the structure. */
typedef struct redisDb {

    // 数据库键空间,保存着数据库中的所有键值对
    dict *dict;                 /* The keyspace for this DB */

    // 键的过期时间,字典的键为键,字典的值为过期事件 UNIX 时间戳
    dict *expires;              /* Timeout of keys with a timeout set */

    // 正处于阻塞状态的键
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP) */

    // 可以解除阻塞的键
    dict *ready_keys;           /* Blocked keys that received a PUSH */

    // 正在被 WATCH 命令监视的键
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */

    struct evictionPoolEntry *eviction_pool;    /* Eviction pool of keys */

    // 数据库号码
    int id;                     /* Database ID */

    // 数据库的键的平均 TTL ,统计信息
    long long avg_ttl;          /* Average TTL, just for stats */

} redisDb;

一个带有过期字典的数据库例子,键空间保存了数据库中的所有键值对,而过期字典则保存了数据库键的过期时间。

备注:为了展示方便,图中的键空间和过期字典中重复出现了两次alphabet键对象和book键对象。在实际中,键空间的键和过期字典的键都指向同一个键对象,所以不会出现任何重复对象,也不会浪费任何空间。

  • 第一个键值对的键为alphabet键对象,值为1563350356000,这表示数据库键alphabet的过期时间为1563350356000(2019-07-17 15:59:16)。
  • 第二个键值对的键为book键对象,值为1563350529000,这表示数据库键book的过期时间为1563350529000(2019-07-17 16:02:09)。
    当客户端执行PEXPIREAT命令(或者其他三个会转换成PEXPIREAT命令的命令)为一个数据库键设置过期时间时,服务器会在数据库的过期字典中关联给定的数据库键和过期时间。如果数据库当前的状态如上图所示,那么在服务器执行以下命令之后:
127.0.0.1:6379> set message "Hello World"
OK
127.0.0.1:6379> pexpireat message 1563351324000  //过期时间为2019-07-17 16:15:24
(integer) 1
127.0.0.1:6379> get message
"Hello World"
127.0.0.1:6379> get message
(nil)

这时过期字典将新增一个键值对,其中键为message键对象,而值则为1563351324000(2019-07-17 16:15:24),如图所示:

以下是PEXPIREAT命令的伪代码定义:

def PEXPIREAT(key, expire_time_in_ms):    
    # 如果给定的键不存在于键空间,那么不能设置过期时间    
    if key not in redisDb.dict:        
        return 0    
    # 在过期字典中关联键和过期时间    
    redisDb.expires[key] = expire_time_in_ms    
    # 过期时间设置成功    
    return 1 

移除过期时间

PERSIST命令可以移除一个键的过期时间:

127.0.0.1:6379> set message "Hello World"
OK
127.0.0.1:6379> pexpireat message 1563352500000  //设置过期时间为2019-07-17 16:35:00
(integer) 1
127.0.0.1:6379> ttl message
(integer) 320
127.0.0.1:6379> pttl message
(integer) 309665
127.0.0.1:6379> persist message
(integer) 1
127.0.0.1:6379> ttl message
(integer) -1  //-1代表这个key没有期时间

PERSIST命令就是PEXPIREAT命令的反操作:PERSIST命令在过期字典中查找给定的键,并解除键和值(过期时间)在过期字典中的关联。

如果数据库当前的状态如上图所示,那么当服务器执行以下命令之后:

127.0.0.1:6379> persist book
(integer) 1

那么数据库的状态将更新为如下图所示:

可以看到,当PERSIST命令执行之后,过期字典中原来的book键值对消失了,这代表数据库键book的过期时间已经被移除。

以下是PERSIST命令的伪代码定义:

def PERSIST(key):    
    # 如果键不存在,或者键没有设置过期时间,那么直接返回    
    if key not in redisDb.expires:        
        return 0    
    # 移除过期字典中给定键的键值对关联    
    redisDb.expires.remove(key)    
    # 键的过期时间移除成功    
    return 1

计算并返回剩余生存时间

TTL命令以秒为单位返回键的剩余生存时间,而PTTL命令则以毫秒为单位返回键的剩余生存时间:

127.0.0.1:6379> rpush alphabet a b c
(integer) 3
127.0.0.1:6379> pexpireat alphabet 1563354600000
(integer) 1
127.0.0.1:6379> ttl alphabet
(integer) 106
127.0.0.1:6379> pttl alphabet
(integer) 102971

TTL和PTTL两个命令都是通过计算键的过期时间和当前时间之间的差来实现的,以下是这两个命令的伪代码实现:

def PTTL(key):    
    # 键不存在于数据库    
    if key not in redisDb.dict:        
        return -2    
    # 尝试取得键的过期时间    
    # 如果键没有设置过期时间,那么 expire_time_in_ms 将为 None    
    expire_time_in_ms = redisDb.expires.get(key)    
    # 键没有设置过期时间    
    if expire_time_in_ms is None:        
        return -1    
    # 获得当前时间    
    now_ms = get_current_unix_timestamp_in_ms()    
    # 过期时间减去当前时间,得出的差就是键的剩余生存时间    
    return(expire_time_in_ms - now_ms)
    
def TTL(key):    
    # 获取以毫秒为单位的剩余生存时间    
    ttl_in_ms = PTTL(key)
    #处理返回值为-2和-1的情况    
    if ttl_in_ms < 0:
        return ttl_in_ms    
    else:        
        # 将毫秒转换为秒        
        return ms_to_sec(ttl_in_ms)

过期键的判定

通过过期字典,程序可以用以下步骤检查一个给定键是否过期:

  • 检查给定键是否存在于过期字典:如果存在,那么取得键的过期时间。
  • 检查当前UNIX时间戳是否大于键的过期时间:如果是的话,那么键已经过期;否则的话,键未过期。
def is_expired(key):    
    # 取得键的过期时间    
    expire_time_in_ms = redisDb.expires.get(key)    
    # 键没有设置过期时间
     if expire_time_in_ms is None:        
         return False    
     # 取得当前时间的UNIX时间戳    
     now_ms = get_current_unix_timestamp_in_ms()    
     # 检查当前时间是否大于键的过期时间    
     if now_ms > expire_time_in_ms:        
         # 是,键已经过期       
         return True    
     else:        
         # 否,键未过期        
         return False

备注:实现过期键判定的另一种方法是使用TTL命令或者PTTL命令,比如说,如果对某个键执行TTL命令,并且命令返回的值大于等于0,那么说明该键未过期。在实际中,Redis检查键是否过期的方法和is_expired函数所描述的方法一致,因为直接访问字典比执行一个命令稍微快一些。

过期键删除策略

了解了数据库键的过期时间都保存在过期字典中,以及如何根据过期时间去判断一个键是否过期,现在剩下的问题是:如果一个键过期了,那么它什么时候会被删除呢?
三种不同的删除策略:

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

其中第一种和第三种为主动删除策略,而第二种则为被动删除策略。

定时删除

优点:对内存是最友好的。通过使用定时器,定时删除策略可以保证过期键会尽可能快地被删除,并释放过期键所占用的内存。

缺点:对CPU时间是最不友好的。在过期键比较多的情况下,删除过期键这一行为可能会占用相当一部分CPU时间,在内存不紧张但是CPU时间非常紧张的情况下,将CPU时间用在删除和当前任务无关的过期键上,无疑会对服务器的响应时间和吞吐量造成影响。

如果正有大量的命令请求在等待服务器处理,并且服务器当前不缺少内存,那么服务器应该优先将CPU时间用在处理客户端的命令请求上面,而不是用在删除过期键上面。

备注:创建一个定时器需要用到Redis服务器中的时间事件,而当前时间事件的实现方式——无序链表,查找一个事件的时间复杂度为O(N)——并不能高效地处理大量时间事件。

惰性删除

优点:对CPU时间来说是最友好的。程序只会在取出键时才对键进行过期检查,这可以保证删除过期键的操作只会在非做不可的情况下进行,并且删除的目标仅限于当前处理的键,这个策略不会在删除其他无关的过期键上花费任何CPU时间。

缺点:对内存是最不友好的:如果一个键已经过期,而这个键又仍然保留在数据库中,那么只要这个过期键不被删除,它所占用的内存就不会释放。

在使用惰性删除策略时,如果数据库中有非常多的过期键,而这些过期键又恰好没有被访问到的话,那么它们也许永远也不会被删除(除非用户手动执行FLUSHDB),这种情况看作是一种内存泄漏——无用的垃圾数据占用了大量的内存,而服务器却不会自己去释放它们,对于运行状态非常依赖于内存的Redis服务器来说,可能会引发内存使用问题。

例如对于一些和时间有关的数据,比如日志(log),在某个时间点之后,对它们的访问就会大大减少,甚至不再访问,如果这类过期数据大量地积压在数据库中,用户以为服务器已经自动将它们删除了,但实际上这些键仍然存在,而且键所占用的内存也没有释放,那么造成的后果肯定是非常严重的。

定期删除

定时删除占用太多CPU时间,影响服务器的响应时间和吞吐量。

惰性删除浪费太多内存,有内存泄漏的危险。

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

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

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

  • 如果删除操作执行得太频繁,或者执行的时间太长,定期删除策略就会退化成定时删除策略,以至于将CPU时间过多地消耗在删除过期键上面。
  • 如果删除操作执行得太少,或者执行的时间太短,定期删除策略又会和惰性删除策略一样,出现浪费内存的情况。

因此,如果采用定期删除策略的话,服务器必须根据情况,合理地设置删除操作的执行时长和执行频率。

Redis的过期键删除策略

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

惰性删除策略的实现

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

  • 如果输入键已经过期,那么expireIfNeeded函数将输入键从数据库中删除。
  • 如果输入键未过期,那么expireIfNeeded函数不做动作。
/*
 * 检查 key 是否已经过期,如果是的话,将它从数据库中删除。
 * 返回 0 表示键没有过期时间,或者键未过期。
 * 返回 1 表示键已经因为过期而被删除了。*/
int expireIfNeeded(redisDb *db, robj *key) {
    // 取出键的过期时间
    mstime_t when = getExpire(db,key);
    mstime_t now;
    // 没有过期时间
    if (when < 0) return 0; /* No expire for this key */
    /* Don't expire anything while loading. It will be done later. */
    // 如果服务器正在进行载入,那么不进行任何过期检查
    if (server.loading) return 0;

    /* If we are in the context of a Lua script, we claim that time is
     * blocked to when the Lua script started. This way a key can expire
     * only the first time it is accessed and not in the middle of the
     * script execution, making propagation to slaves / AOF consistent.
     * See issue #1525 on Github for more information. */
    now = server.lua_caller ? server.lua_time_start : mstime();

    /* If we are running in the context of a slave, return ASAP:
     * the slave key expiration is controlled by the master that will
     * send us synthesized DEL operations for expired keys.
     *
     * Still we try to return the right information to the caller, 
     * that is, 0 if we think the key should be still valid, 1 if
     * we think the key is expired at this time. */
    // 当服务器运行在 replication 模式时
    // 附属节点并不主动删除 key
    // 它只返回一个逻辑上正确的返回值
    // 真正的删除操作要等待主节点发来删除命令时才执行
    // 从而保证数据的同步
    if (server.masterhost != NULL) return now > when;
    // 运行到这里,表示键带有过期时间,并且服务器为主节点
    /* Return when this key has not expired */
    // 如果未过期,返回 0
    if (now <= when) return 0;

    /* Delete the key */
    server.stat_expiredkeys++;

    // 向 AOF 文件和附属节点传播过期信息
    propagateExpire(db,key);

    // 发送事件通知
    notifyKeyspaceEvent(REDIS_NOTIFY_EXPIRED,
        "expired",key,db->id);

    // 将过期键从数据库中删除
    return dbDelete(db,key);
}

Redis命令调用expireIfNeeded函数的过程如图所示:

expireIfNeeded函数就像一个过滤器,它可以在命令真正执行之前,过滤掉过期的输入键,从而避免命令接触到过期键。

因为每个被访问的键都可能因为过期而被expireIfNeeded函数删除,所以每个命令的实现函数都必须能同时处理键存在以及键不存在这两种情况:

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

定期删除策略的实现

过期键的定期删除策略由redis.c/activeExpireCycle函数实现,每当Redis的服务器周期性操作redis.c/serverCron函数执行时,activeExpireCycle函数就会被调用,它在规定的时间内,分多次遍历服务器中的各个数据库,从数据库的expires字典中随机检查一部分键的过期时间,并删除其中的过期键。
整个过程可以用伪代码描述如下:

# 默认每次检查的数据库数量
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函数的工作模式可以总结如下:

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

AOF、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文件追加(append)一条DEL命令,来显式地记录该键已被删除。

例如,如果客户端使用GETmessage命令,试图访问过期的message键,那么服务器将执行以下三个动作:

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

AOF文件重写

和生成RDB文件时类似,在执行AOF重写的过程中,程序会对数据库中的键进行检查,已过期的键不会被保存到重写后的AOF文件中。

例如,如果数据库中包含三个键k1、k2、k3,并且k2已经过期,那么在进行重写工作时,程序只会对k1和k3进行重写,而k2则会被忽略。
因此,数据库中包含过期键不会对AOF重写造成影响。

Redis复制

当服务器运行在复制模式下时,从服务器的过期键删除动作由主服务器控制:

  • 主服务器在删除一个过期键之后,会显式地向所有从服务器发送一个DEL命令,告知从服务器删除这个过期键。
  • 从服务器在执行客户端发送的读命令时,即使碰到过期键也不会将过期键删除,而是继续像处理未过期的键一样来处理过期键。
  • 从服务器只有在接到主服务器发来的DEL命令之后,才会删除过期键。

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

例如,有一对主从服务器,它们的数据库中都保存着同样的三个键alphabet、book和message,其中alphabet为过期键,如图所示:

如果这时有客户端向从服务器发送命令get alphabet,那么从服务器将发现alphabet键已经过期,但从服务器并不会删除alphabet键,而是继续将alphabet键的值返回给客户端,就好像alphabet键并没有过期一样,如图所示:

假设在此之后,有客户端向主服务器发送命令get alphabet,那么主服务器将发现键alphabet已经过期:主服务器会删除alphabet键,向客户端返回空回复,并向从服务器发送del alphabet命令,如图所示:

从服务器在接收到主服务器发来的del alphabet命令之后,也会从数据库中删除alphabet键,在这之后,主从服务器都不再保存过期键alphabet了,如图所示:

总结

  • expires字典的键指向数据库中的某个键,而值则记录了数据库键的过期时间,过期时间是一个以毫秒为单位的UNIX时间戳。
  • Redis使用惰性删除和定期删除两种策略来删除过期的键:惰性删除策略只在碰到过期键时才进行删除操作,定期删除策略则每隔一段时间主动查找并删除过期键。
  • 执行SAVE命令或者BGSAVE命令所产生的新RDB文件不会包含已经过期的键。
  • 执行BGREWRITEAOF命令所产生的重写AOF文件不会包含已经过期的键。
  • 当一个过期键被删除之后,服务器会追加一条DEL命令到现有AOF文件的末尾,显式地删除过期键。
  • 当主服务器删除一个过期键之后,它会向所有从服务器发送一条DEL命令,显式地删除过期键。
  • 从服务器即使发现过期键也不会自作主张地删除它,而是等待主节点发来DEL命令,这种统一、中心化的过期键删除策略可以保证主从服务器数据的一致性。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,047评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,807评论 3 386
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,501评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,839评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,951评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,117评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,188评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,929评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,372评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,679评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,837评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,536评论 4 335
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,168评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,886评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,129评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,665评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,739评论 2 351

推荐阅读更多精彩内容