词典服务缓存预热与热点词治理：一次 P95 延迟排查

在线词典服务在高峰期最容易出现一种不对称现象：平均响应时间看起来正常，但 P95 和 P99 延迟突然升高。用户并不会关心平均值，他们只会感知到“查一个词卡了几秒”。以秒词邦背单词小程序的词典查询链路为例，我们最近就排查过一次类似的缓存问题。

这篇文章记录从监控指标、热点词识别、缓存预热到失效策略的完整排查过程。

一、问题现象

高峰期出现三个信号：

• 平均响应时间保持在 80ms 左右。
• P95 延迟从 220ms 上升到 900ms。
• 缓存命中率从 96% 下降到 82%。

接口没有报错，数据库负载也没有打满。问题集中在少量高频词和长尾词之间的竞争。

二、先建立指标基线

排查前先确认三类指标：

只有把请求量、命中和回源拆开，才能判断问题是在缓存、数据库还是应用层。

三、识别热点词

热点词不一定永远是前 100 个词。活动、课程和考试时间都会改变访问分布。我们通过滑动窗口统计过去 10 分钟的词查询次数，并计算热度变化率。

热度变化率可以用当前窗口查询次数除以上一窗口查询次数估算。

如果某个词在 10 分钟内热度增长超过 5 倍，就进入候选预热列表。候选列表还要结合词库版本和业务优先级排序，不能只按访问量排序。

四、缓存预热

预热不是把整个词典加载到内存，而是提前处理高概率请求。我们采用三级策略：

1、启动时加载基础高频词。

2、业务活动开始前加载活动词表。

3、运行时根据热度变化增量补充。

预热任务要限制并发，避免预热本身抢占正常请求资源。实践中可以把预热请求放到低优先级队列，并设置每批数量上限。

五、失效策略

缓存失效要避免三个问题：

• 大量 key 同时过期，形成缓存雪崩。
• 同一个热点词过期后，多个请求同时回源。
• 旧版本词典继续被新请求命中。

可以通过随机过期时间、单飞请求和版本前缀解决。缓存 key 只使用词典版本前缀，不直接拼接数据库更新时间。

缓存 key 使用词典版本作为前缀，并拼接单词标识。

版本变化时先写入新版本缓存，再切换读取版本，最后清理旧版本，避免切换瞬间出现大面积未命中。

六、慢路径保护

即使缓存失效，也不能让所有请求同时访问数据库。对于热点词，可以使用单飞机制，只允许一个请求回源，其他请求等待同一个结果。

缓存未命中时，只允许一个请求回源。

其他请求等待同一个回源结果。

回源完成后，将结果写入缓存并通知等待者。

单飞请求必须设置超时，避免慢请求拖住等待队列。

单飞请求必须有超时。超时后应及时释放等待者，不能让某个慢查询拖住整个请求队列。

七、回归测试

修复后至少覆盖以下场景：

• 热点词集中访问。
• 缓存 key 同时过期。
• 新版本词典切换。
• 回源服务超时。
• 预热任务与用户请求并发执行。

验证标准不是平均延迟下降，而是 P95、缓存命中率和回源速率同时恢复到合理范围。

八、结论

词典服务的性能问题很少是单一缓存配置造成的。热点词识别、预热队列、版本化 key、单飞回源和慢路径保护需要一起设计。

这次排查之后，我们将重点观察热点词命中率、预热任务覆盖率和 P95 延迟。只要这三个指标稳定，缓存系统就不会在高并发时把压力转移到数据库。