在Redis中，过期键（Expire Key）机制是实现缓存自动失效、临时数据管理的核心功能。EXPIRE命令作为设置键过期时间的基础工具，其工作原理与使用细节直接影响系统的内存效率和数据一致性。本章将系统解析EXPIRE命令的特性、过期键的回收机制，以及实际场景中的应用技巧。

一、EXPIRE命令基础：语法与核心功能

EXPIRE命令用于为指定键设置生存时间（以秒为单位），当时间到期后，键会被自动删除。这一特性让Redis能够自动清理临时数据（如会话、验证码），避免内存长期占用。

1. 基本语法与返回值

# 为key设置过期时间（单位：秒）
EXPIRE key seconds

• 返回值：

• 1：设置成功（键存在且过期时间已生效）。
• 0：设置失败（键不存在）。

2. 示例：设置与验证过期时间

# 设置键mykey的值为"Hello"
SET mykey "Hello"
# 为mykey设置10秒过期时间
EXPIRE mykey 10  # 返回1（成功）
# 查看剩余生存时间（单位：秒）
TTL mykey  # 返回10（剩余10秒）
# 5秒后再次查看
TTL mykey  # 返回5（剩余5秒）
# 10秒后查看（键已过期删除）
TTL mykey  # 返回-2（键不存在）

二、过期时间的特性：修改、继承与清除

过期时间并非一旦设置就固定不变，Redis提供了灵活的机制来调整或清除过期时间，同时支持键的属性继承。

1. 过期时间的刷新与覆盖

• 刷新：对已设置过期时间的键再次执行EXPIRE，会更新其过期时间为新值。
  示例：EXPIRE mykey 10后5秒执行EXPIRE mykey 20，键的总生存时间变为20秒（从第二次设置时开始计算）。
• 覆盖：执行SET、GETSET等覆盖键值的命令，会直接清除过期时间（键变为持久化）。
  示例：EXPIRE mykey 10后执行SET mykey "new value"，TTL mykey返回-1（永不过期）。

2. 过期时间的清除

• PERSIST命令：显式清除键的过期时间，使其变为持久化。

EXPIRE mykey 10
PERSIST mykey  # 返回1（成功清除过期时间）
TTL mykey      # 返回-1（永不过期）

• 删除键：DEL命令删除键时，其过期时间也会被一并删除。

3. 键重命名后的属性继承

使用RENAME命令重命名键时，新键会继承原键的过期时间：

SET oldkey "value"
EXPIRE oldkey 60
RENAME oldkey newkey
TTL newkey  # 返回60（继承原键的过期时间）

若目标键（如newkey）已存在，重命名后会覆盖其原有属性（包括过期时间）。

三、过期键的回收机制：被动与主动结合

Redis不会在键过期的瞬间立即删除，而是通过被动淘汰和主动淘汰两种机制结合，平衡内存释放与CPU消耗。

1. 被动淘汰（Lazy Expiration）

• 触发时机：当客户端访问某个键时，Redis会先检查该键是否过期。若已过期，立即删除并返回nil。
• 优势：不消耗额外CPU资源，仅在访问时处理。
• 缺陷：对于长期未被访问的过期键，会占用内存（“内存泄漏”风险）。

2. 主动淘汰（Active Expiration）

为解决被动淘汰的缺陷，Redis会周期性主动检查并删除过期键，流程如下：

1. 每秒执行10次（频率由hz配置控制，默认10），每次从“带过期时间的键”集合中随机选择20个键。
2. 删除其中已过期的键。
3. 若这20个键中过期比例超过25%，重复步骤1（继续随机检查），直到比例低于25%或检查次数上限。

• 概率性设计：通过随机抽样，用少量CPU开销覆盖大部分过期键，避免全量扫描的性能损耗。
• 内存控制：理论上，未被删除的过期键最多占“带过期时间的键”总数的25%，保证内存不会被过度占用。

四、过期键与持久化：AOF、RDB与主从复制的一致性

过期键的处理需要保证持久化文件（AOF、RDB）和主从复制中的数据一致性，Redis通过中心化管理实现这一目标。

1. RDB文件中的过期键

• 生成RDB：执行SAVE或BGSAVE时，过期键不会被写入RDB文件。
• 加载RDB：启动时加载RDB文件，若键已过期且服务器为主节点，会忽略这些键；若为从节点，则会保留（待主节点同步删除命令）。

2. AOF文件中的过期键

• 键过期时，Redis会向AOF文件写入DEL命令，确保后续加载AOF时该键被删除。
• 若AOF重写（BGREWRITEAOF），过期键会被直接跳过，不写入新AOF文件。

3. 主从复制中的过期键

• 主节点：负责检测过期键，删除时会向所有从节点发送DEL命令，保证从节点同步删除。
• 从节点：不会主动删除过期键，仅在收到主节点的DEL命令后执行删除（避免主从数据不一致）。

五、特殊场景与注意事项

1. 负时间值的处理

若EXPIRE的seconds为负数（如EXPIRE mykey -5），键会被立即删除（等效于DEL），且触发del事件（而非expired事件）。

2. 过期时间的精度

• Redis 2.4及以前：精度较低（误差0-1秒）。
• Redis 2.6及以后：精度提升至毫秒级（误差0-1毫秒），适合对时间敏感的场景（如秒杀倒计时）。

3. 服务器时间的影响

过期时间基于服务器的Unix时间戳存储，若服务器时间被手动调整（如向前跳跃），可能导致键提前过期：
示例：设置键1000秒后过期，若服务器时间突然增加2000秒，键会立即被判定为过期。

六、实战模式：导航会话（Navigation Session）案例

利用EXPIRE的刷新特性，可实现用户导航会话的自动管理——仅保留用户最近60秒内的页面访问记录：

# 每次用户访问页面时执行
MULTI
# 将页面URL添加到用户的访问列表
RPUSH pageviews.user:123 "https://example.com/page1"
# 刷新会话过期时间为60秒（若用户59秒内再次访问，时间会重新计算）
EXPIRE pageviews.user:123 60
EXEC

• 若用户连续访问，会话时间不断刷新，记录得以保留；
• 若超过60秒未访问，列表会被自动删除，节省内存。

七、总结：过期键管理的最佳实践

1. 合理设置过期时间：根据业务需求（如会话有效期、缓存失效时间）设置，避免过长或过短。
2. 利用刷新机制：对需要“续期”的场景（如用户活跃时延长会话），通过EXPIRE动态更新时间。
3. 监控过期键比例：若内存占用过高，检查是否有大量未被访问的过期键（可通过INFO stats的expired_keys指标监控）。
4. 注意主从一致性：主从架构中，依赖主节点的DEL命令同步过期键，避免从节点数据残留。

EXPIRE命令看似简单，但其背后的过期机制是Redis内存管理的核心。掌握这些细节，能帮助你在缓存设计、临时数据处理中避免内存泄漏，同时保证系统的高效运行。