redis采用惰性删除与定期删除协同机制，不依赖定时器实时删除：惰性删除仅在访问键时通过expireifneeded()检查并删除过期键，未访问的过期键长期驻留内存；定期删除默认每100ms随机扫描20个带ttl的键清理，存在漏扫可能；集群环境下分片、主从同步及节点独立配置进一步加剧过期状态延迟与不一致。
Redis集群中TTL过期键不会在到期瞬间消失，这是设计使然，不是bug。根本原因在于它压根不依赖“定时器到期即删”这种模型，而是靠expireIfNeeded()（惰性）和后台周期性扫描（定期）协同清理——两者都存在天然延迟，且集群拓扑会进一步放大这种不确定性。
为什么get或exists时才可能触发删除
惰性删除只在命令执行前调用expireIfNeeded()检查目标key。这意味着：
- 如果一个key过期了但从未被
get、set、hget等任何读写命令访问，它就一直留在内存里，TTL返回值可能还是正数（因为未触发检查） -
keys *、scan这类遍历命令**不会**触发惰性删除，它们只查键名，不查过期状态 - 集群环境下，哪怕你连的是正确的slot节点，只要该key没被访问过，它就“假装还活着”，
ttl命令返回的仍是原始剩余秒数，而非-2（不存在）或-1（永不过期）
定期删除每100ms扫描一次，但只看“过期字典”里的随机样本
Redis维护一个独立的expires字典，所有带TTL的key都会被索引进去。定期删除逻辑（activeExpireCycle()）默认每100ms执行一次，但它不是全量扫描：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 每次只从
expires字典中**随机选取20个key**做检查（可由active-expire-effort配置调整） - 只删除其中真正过期的key；若本轮删得少，下轮继续，但不保证“本轮扫到你就删”
- 如果过期key集中在某个db或某个slot，而随机采样没覆盖到，它们就会滞留更久——集群分片越多，这种概率越高
- 当内存压力大时，该循环会更激进（比如尝试更多轮次），但日常负载下，它就是“尽力而为”
集群模式下，主从同步与分片加剧了过期可见性偏差
在Redis Cluster中，过期行为不是全局原子的：
- 过期判断发生在**本地节点**，主节点删了，从节点不会立刻同步这个“删除动作”，而是等后续复制流把DEL指令传过去
- 如果你用
redis-cli -c连接集群，执行ttl mykey，返回结果取决于你路由到哪个节点——若该节点还没触发惰性/定期删除，就仍显示剩余时间 - 跨slot操作（如
eval脚本访问多个key）无法保证所有涉及key在同一节点被同时检查，过期状态可能不一致 -
CONFIG SET active-expire-effort 1这类调优只作用于当前节点，集群各节点需单独配置，否则行为不统一
真正需要“强时效”的场景（比如会话token必须精确到秒级失效），不能依赖Redis自动过期机制本身；得配合业务层主动校验时间戳，或用EXPIREAT + 定时任务兜底。过期策略本质是资源权衡——它用可控的延迟换来了单线程模型下的CPU稳定性和内存释放弹性。
