Linux环境Codex缓存策略优化：Redis键值对过期时间设置实战教程
一个常见问题：如果Redis中大量缓存项未设置过期时间，后果是什么？内存将持续膨胀直至触发OOM。反之，若过期时间过于集中，将引发周期性删除风暴，严重拖慢主线程。平衡这一矛盾，正是Codex类应用在部署时必须应对的真实挑战。
Redis提供四种设置过期时间的核心方法，每种方法各有适用场景和精度控制：
第一种，EXPIRE命令——为已存在的键追加秒级过期。例如在运行中的Codex服务里，需要动态调整用户会话token的存活窗口，直接对已有缓存项施加时效控制。
操作并不复杂：先用redis-cli连接目标实例（假设本地访问，端口6379，密码通过-a参数传递）。然后执行EXPIRE keyname 3600，表示将keyname的生存期设为3600秒，即1小时。返回1表示设置成功；返回0说明key不存在或类型不支持过期（比如在Redis集群中操作非hash slot的key）。最后用TTL验证：TTL keyname，剩余秒数一目了然。返回-2表示key已消失，返回-1则说明要么未设过期时间，要么key根本不存在。
需注意的是，EXPIRE仅对普通键生效。对于Redis Cluster中跨slot的复合结构（如list里的某个子项），无法通过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，键在2026-06-12 00:00:00 UTC准时失效。时间戳可通过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匹配前缀，对每个匹配的key执行EXPIRE，避免客户端循环加网络往返开销。
同时需调整Redis配置以匹配业务节奏。编辑/etc/redis/redis.conf，将maxmemory-policy设为volatile-lru。这样，当内存达到上限时，Redis会优先淘汰带过期时间的LRU键，而非误删永久配置项。最后重启服务生效：systemctl restart redis-server。
缓存过期并非简单的“设一个时间就完事”，它需要根据业务场景、数据特性和内存预算综合决策。选对方法、控制好节奏，才能让Redis既快又稳。
