原标题：探秘 Redis 中键的自动过期功能
自我介绍
冷正磊，2018 年 2 月加入去哪儿网 DBA 团队，主要负责公司 Redis 和机票业务 MySQL 数据库的运维工作，同时承担去哪儿网数据库自动化运维平台部分模块的开发工作，对数据库技术具有浓厚兴趣，具有多年 Oracle、MySQL 及 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 秒。
PEXPIRE 命令用于将键 key 的生存时间设置为 ttl 毫秒。
EXPIREAT 命令用于将键 key 的过期时间设置为 timestamp 所指定的秒数时间戳。
PEXPIREAT 命令用于将键 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 , we claim that time is
* blocked to when the Lua started. This way a key can expire
* only the first time it is accessed and not in the middle of the
* 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 键，那么服务器将执行以下三个动作：
从数据库中删除 message 键。
追加一条 DELmessage 命令到 AOF 文件。
向执行 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 键并没有过期一样(Redis3.2 之前版本)，如图所示：
假设在此之后，有客户端向主服务器发送命令 get alphabet，那么主服务器将发现键 alphabet 已经过期：主服务器会删除 alphabet 键，向客户端返回空回复，并向从服务器发送 del alphabet 命令，如图所示：
从服务器在接收到主服务器发来的 del alphabet 命令之后，也会从数据库中删除 alphabet 键，在这之后，主从服务器都不再保存过期键 alphabet 了，如图所示：
总结
expires 字典的键指向数据库中的某个键，而值则记录了数据库键的过期时间，过期时间是一个以毫秒为单位的 UNIX 时间戳。
Redis 使用惰性删除和定期删除两种策略来删除过期的键：惰性删除策略只在碰到过期键时才进行删除操作，定期删除策略则每隔一段时间主动查找并删除过期键。
执行 SAVE 命令或者 BGSAVE 命令所产生的新 RDB 文件不会包含已经过期的键。
执行 BGREWRITEAOF 命令所产生的重写 AOF 文件不会包含已经过期的键。
当一个过期键被删除之后，服务器会追加一条 DEL 命令到现有 AOF 文件的末尾，显式地删除过期键。
当主服务器删除一个过期键之后，它会向所有从服务器发送一条 DEL 命令，显式地删除过期键。
从服务器即使发现过期键也不会自作主张地删除它，而是等待主节点发来 DEL 命令，这种统一、中心化的过期键删除策略可以保证主从服务器数据的一致性。返回搜狐，查看更多
责任编辑：
806
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
