49图库缓存重构：重复查询命中率提升至 92.4%

2026 年 9 月 22 日，49图库完成缓存层重构。查询结果改为按条件指纹缓存，重复查询的命中率从 71.6% 提升到 92.4%，服务端响应中位数从 128 毫秒降至 46 毫秒。静态资源统一加版本号参数，图片缓存 30 天并标记为不可变，修改后版本号递增即可立即生效。

旧缓存以完整 URL 为键，只要查询参数顺序不同就会被视为新请求。实际使用中，同一组筛选条件经常以不同顺序出现，例如“号码 07,22 + 区间 500”和“区间 500 + 号码 22,07”，两者结果完全一致却各占一份缓存，命中率因此停在 71.6%，缓存空间也被无效条目占掉 34.2%。

重构的核心是把参数归一化后计算指纹：号码升序排列、区间转成数值、逻辑类型转成枚举，再对这些规范化字段做哈希。只要语义相同，指纹就相同。

指纹怎么算，失效怎么触发

指纹由四段组成：排序后的号码列表、区间数值、逻辑类型、数据版本号。前三段保证语义相同即命中，第四段保证数据更新后旧缓存自动失效——每天入库完成后数据版本号递增，所有旧指纹自然不再被引用，无需逐个清理。

缓存内容只包含期号、号码、日期与统计结果，不含任何请求头、IP 或时间戳，因此不存在个人化数据残留。单条缓存最大 48 千字节，整体上限 2.4 吉字节，超出后按最近最少使用淘汰。

指纹使用 64 位哈希，输入为排序后的条件串加数据版本号。理论上存在碰撞可能，实际条目上限为 2 万条并按最近最少使用淘汰，碰撞概率可以忽略。缓存键不包含 IP、UA 或任何设备信息，同一组条件在任何设备上得到的结果完全相同，响应中也不下发用于追踪的 Cookie。

缓存最容易出问题的地方不是命中率，而是该失效的时候没失效。把数据版本号写进指纹，这个问题就一次性解决了。—— 49图库数据工程负责人 陈立恒

命中率与响应时间的实测

重构后连续观察 14 天，共处理查询 218 万次，缓存命中 201.4 万次，命中率 92.4%；未命中的 7.6% 主要是首次出现的组合与数据版本更新后的第一批请求。服务端响应中位数 46 毫秒，95 分位 132 毫秒。

静态资源方面，样式与脚本加版本号参数后，回访用户的请求数从平均 9 个降到 3 个；图片缓存 30 天并标记不可变，二次访问直接命中本地缓存，页面重复访问的首屏时间从 1.4 秒降到 0.8 秒。

命中率按查询类型分层：检索类 94.1%，筛选类 91.6%，走势图类 89.8%。走势图偏低是因为区间与号码组合更分散，长尾条件更多。每天数据更新后的五分钟内，整体命中率会短暂降到 62% 左右，随后随新指纹积累回升，这个过程不需要人工干预。

数据版本号由一个独立文件承载，入库任务全部完成后才写入新版本号，缓存层每次请求读取一次。这样避免了“数据写了一半、缓存已经按新版本计算”的情况：版本号没变，旧缓存继续可用；版本号变了，说明这批数据已经完整落库。

使用者能感知到什么

最直接的变化是重复筛选几乎瞬时返回。以“三个号码 + 500 期”这样的组合为例，首次查询 0.12 秒，再次查询因为命中缓存降到 0.04 秒。数据更新后第一次查询会重新计算，界面上不会出现加载提示，因为整个过程仍在 0.2 秒内。

缓存不会改变结果。所有命中缓存的查询仍然会按同一套统计规则输出，导出文件与首次查询完全一致。如果发现两次查询结果不同，请检查数据版本是否在两次之间更新——这种情况通常发生在开奖后 5 分钟内。

使用者能感知到的变化主要是等待消失。旧版在筛选条件较多时会先出现骨架屏，再填充结果；新版因为命中缓存，多数请求在骨架屏出现前就已返回。为了避免闪烁，页面改为延迟 120 毫秒再显示加载状态，实际使用中几乎看不到这个状态。

缓存条目上限 2 万条，按最近最少使用淘汰，单条平均 4 千字节，占用约 80 兆字节。把上限调到 5 万条时命中率只提升 1.1 个百分点，内存占用却翻了一倍多，因此维持 2 万条。这个数字每个季度复评一次，依据是命中率与内存占用的实测曲线。

缓存是加速手段，不是数据来源。任何时候清空缓存，结果都必须一样，这是验收标准。—— 49图库数据校验组负责人 周敏

新的缓存策略已覆盖检索、筛选与走势图三类查询，客户端离线包不使用服务端缓存，行为不受影响。下一阶段会把缓存命中情况做成公开的状态页，让使用者能确认自己拿到的是首次计算还是缓存结果。