Redis是否支持TTL过期前条件校验及过期触发自定义脚本？

• Redis原生不支持TTL过期前自动执行自定义条件校验，也没有开放键过期删除时触发用户自定义脚本的内置钩子。原生过期策略是「惰性删除+定期抽样删除」组合：键到期后要么被访问时判定失效删除，要么被后台任务抽样扫描到删除，整个流程没有预留用户逻辑注入点，不要尝试通过修改配置实现这类触发逻辑，原生版本做不到。

核心思路是把「TTL和业务键强绑定」的思路转成「规则全局管控、过期判定跟着访问走」，完全规避规则变更时批量修改存量键的开销：

• 优先选：逻辑过期+固定短物理TTL兜底
  存储结构和逻辑做如下调整，规则变更时零存量键修改成本：
  1. 所有业务键的value中额外存一个逻辑过期时间戳字段，这个字段的计算逻辑关联Redis中存储的全局业务过期规则，规则更新时只需要修改这一份全局配置，不需要碰任何存量业务数据
  2. 给所有业务键统一设置一个固定长度的短物理TTL（比如取业务规则允许的最长TTL再加1_{2天，或者按业务访问周期设为24}48小时），这个TTL只做冷数据兜底清理用，和实际业务过期规则无关
  3. 业务侧每次访问键时，先校验value中的逻辑过期时间：如果已经超过当前时间，直接判定数据失效，走数据源回源逻辑同时异步删除旧键；如果未到逻辑过期时间，正常返回数据，顺便将键的物理TTL续期回预设的固定兜底值即可。
     这个方案所有操作都嵌入正常业务访问链路，没有额外的扫描、批量操作开销，不管业务规则怎么调整，都不需要遍历存量数据，是海量数据场景下的最优解。
• 备选：键空间通知+异步校验补偿（仅适合非核心数据场景）
  如果不想改业务存储结构，可以开启Redis键空间通知，修改配置notify-keyspace-events Ex，开启后Redis会在键被过期删除时向专用频道推送事件消息：
  1. 部署独立的消费服务订阅过期事件频道，收到某键过期的消息时，拉取当前生效的最新业务规则，判断该键按新规则是否真的到期：如果确实到期直接忽略；如果按新规则还需留存，就重新写入该键并设置符合新规则的TTL。
  2. 注意这个方案有明显缺陷：Redis键空间通知不做持久化，不保证100%送达，消费端宕机、消息积压丢消息都会导致本该续期的键被误删；且海量键同时过期时会产生瞬时海量消息，很容易打满消费带宽，因此只适合对数据一致性要求不高的非核心场景。

不推荐低峰期全量扫描键修改TTL的方案：哪怕用SCAN游标式扫描，数百万甚至更多键的遍历加TTL修改操作会持续占用Redis主线程资源，干扰正常业务请求，一旦业务规则变更频繁，扫描速度根本赶不上规则调整的速度，完全没有可行性。也不建议修改Redis源码注入过期钩子，自定义逻辑一旦出现慢执行会直接阻塞Redis主线程，线上故障风险极高。

内容的提问来源于stack exchange，提问作者Rahul