Key 已停用却还能调用一会儿，怎样量化鉴权缓存的失效窗口

管理端已经把Key设为停用，一个副本却仍接收新请求，可能是它正在使用尚未失效的鉴权缓存。本文把数据库状态、每副本缓存和在途调用分开，用双副本假时钟量化新请求的陈旧准入窗口，不讨论已在上游执行的任务能否被追回。

从撤销时刻计算陈旧窗口

附件设撤销发生在两千毫秒，缓存有效期一万毫秒。副本一在零毫秒加载，失效点一万；副本二在一千毫秒加载，失效点一万一。若只等待TTL，两者在撤销后最多还会分别使用八秒和九秒旧许可。不能用“TTL十秒”代替实际陈旧窗口，因为每个副本加载时刻不同。

查询向量覆盖撤销瞬间、失效事件到达、一万前一毫秒、恰好一万以及一万一的边界。本例缓存条件是现在严格早于expires才有效；到期点必须重新读权威状态。若实现用小于等于，可能多允许一个边界请求。测试应记录每次新准入究竟命中缓存还是读取了权威状态，不能只看数据库里的禁用标志。

主动失效也要测试事件丢失

第二条路径中，副本一在两千一百毫秒收到失效事件，陈旧窗口缩到一百毫秒；副本二没有收到，仍可能陈旧九秒。平均传播时间很快，不能证明最慢副本满足撤销目标。验收应同时给最大窗口、未确认副本集合和TTL兜底，而不是只展示成功收到事件的节点。

事件可能乱序或重复。实际接入时可携带Key状态版本，旧的“启用”消息不能覆盖更新的“停用”；重复失效则应保持无害。权威存储读取失败时继续使用旧许可还是拒绝新请求，也必须是明确策略。本文没有替任何产品选择故障模式，更没有把消息总线可靠性视为已测事实。

给撤销目标一个可测口径

可将目标写成“权威停用被确认后，所有副本在规定时间内拒绝该Key的新准入”，并记录确认时刻与最后一次陈旧准入时刻。在途请求另列，避免一个旧连接持续输出使报告误认为撤销广播一直失败。缓存为空的新副本也要覆盖，不能因为其他副本还持有许可就跟着放行。

附件只在内存中回放TTL和事件到达，没有部署LiteLLM、Redis或广播组件。虚拟Key官方文档用于核对管理能力，失效窗口以实际版本和配置为准。把本例九秒、一百毫秒和事件丢失三个答案作为参考，可以审查自己的测试是否真的覆盖最慢节点。若日志里没有缓存来源、版本和副本标识，即使收集到很多成功失败记录，也很难把传播延迟从鉴权逻辑错误中分开。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C012。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文讲双Key轮换与应急停用；本文用双副本缓存时间线只测新请求的失效传播，不写泄漏处置，不覆盖已在途调用取消。