先讨论一个常见隐患：如果Redis缓存中大量数据未设置有效期限，会出现什么后果？答案显而易见——内存占用持续增长，最终触发内存溢出（OOM）。反之，若过期时间设置过于集中，则可能引发周期性的集中清理压力，导致主线程阻塞。如何平衡这一矛盾，是许多类似Codex的系统在线上部署时必须解决的实际难题。

Redis提供了四种核心的时效控制方式，每种方式在适用场景与时间精度上各有侧重：

第一种，EXPIRE命令——为已存在的键设置基于秒的相对过期时间。例如在运行中的Codex服务中，需动态调整用户会话token的有效期，即可直接对已有缓存键追加生存时间控制。

操作流程简洁明了：首先通过redis-cli连接到目标实例（假设为本机访问，端口6379，密码通过-a参数传递）。然后执行EXPIRE keyname 3600，这表示将keyname的生存时间设为3600秒（即1小时）。命令返回1代表设置成功；返回0则说明键不存在或该键类型不支持过期设置（例如在Redis集群中操作不属于当前哈希槽的键）。最后可用TTL命令验证：执行TTL keyname，即可查看剩余秒数。返回-2表示键已失效删除；返回-1则意味着键未设置过期时间，或键本身不存在。

需要注意的是，EXPIRE命令仅对普通键生效。对于Redis Cluster中跨slot的复杂数据结构（例如列表中的某个子元素），无法通过EXPIRE单独控制其过期。

第二种，创建键时同步指定其过期时间。这是在Codex中初始化缓存数据时最推荐的做法。先写入数据再补充过期时间的做法存在竞态风险，不如一次性完成设置。这种方式特别适合验证码、临时任务ID等一次性使用数据。

方法一：使用SETEX命令。该命令可一次性完成字符串数据的写入与秒级过期时间设置。例如SETEX codex:verify:abc123 180 "8472"，在写入键值的同时，设置180秒后自动过期，仅需一条指令。

方法二：SET命令配合EX参数。例如SET codex:session:uid789 "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" EX 3600。相较于SETEX，此方式参数更灵活，且为后续扩展非字符串键类型留有余地。

方法三：实现毫秒级精度控制。使用PX参数替代EX参数。例如SET codex:rate:192.168.1.100 "15" PX 60000，该命令常用于限制IP每分钟的请求频率，60000毫秒即60秒，精度更高，可有效避免因系统调度延迟导致的时间窗口漂移问题。

第三种，基于绝对时间戳设定过期点。当Codex需要与外部系统（如优惠券截止、定时报告生成）的时间点严格对齐时，就不能依赖相对时长，而必须锚定到具体的Unix时间戳。

使用EXPIREAT命令：EXPIREAT codex:coupon:20260615 1718121600，该键将在UTC时间2026年6月12日00:00:00准时失效。时间戳可通过命令date -d "2026-06-12 00:00:00 UTC" +%s生成。

PEXPIREAT则支持毫秒级精度：PEXPIREAT codex:report:daily_20260611 1718121600000，适用于对亚秒级同步要求严苛的场景，如实时仪表盘的缓存刷新。

命令操作本身并不复杂。但关键点在于，务必确保服务器时区与UTC一致，否则EXPIREAT会按照本地时间解析。Linux系统必须执行timedatectl set-timezone UTC进行时区校准，否则时间戳偏差将导致缓存键提前或延后失效。

第四种，批量设置过期时间并与淘汰策略协同工作。Codex服务中常遇到需要为一批具有关联性的键统一设置时效的情况，例如用户的所有会话键（session:*）、所有临时文件元数据（tempfile:*）。使用单条EXPIRE命令逐个处理，效率低下。

建议改用Lua脚本实现原子化批量操作：redis-cli --eval /tmp/set-expires.lua session:* , 1800。脚本内部可利用SCAN命令匹配特定前缀的键，并对每个匹配到的键执行EXPIRE，从而避免客户端循环调用及多次网络往返产生的开销。

与此同时，还需调整Redis配置以适配业务节奏。编辑配置文件/etc/redis/redis.conf，将maxmemory-policy设置为volatile-lru。如此配置后，当内存达到上限时，Redis会优先淘汰那些设置了过期时间的、最近最少使用（LRU）的键，从而避免误删那些需要永久保存的核心配置项。修改后重启服务生效：systemctl restart redis-server。

总而言之，缓存过期管理并非“设定一个时间即可”的简单操作，它需要结合业务使用场景、数据特性以及内存预算进行综合规划。只有选择正确的方法并控制好执行节奏，才能确保Redis缓存系统既高效又稳定地运行。