上下文定向的缓存+TTL+异步抓取架构：cache miss不阻塞返回空集合

上下文定向需要根据当前网页的内容给它打上标签，但网页内容抓取和内容挖掘（提取关键词、语义分类、主题建模）本身是相对耗时的操作，完全和[[RTB全链路百毫秒时延约束对架构的强制要求]]描述的几十毫秒响应预算不兼容。系统的解法是把”抓取和挖掘”与”实时查询”彻底解耦，用缓存把两者串起来：以URL为key建立一个缓存（cache），广告请求到来时，如果这个URL命中了缓存，立即把缓存里已经算好的标签内容返回；如果没有命中（说明这个URL之前没被抓取分析过），不会同步等待去现场抓取和分析，而是直接返回一个空集合（放弃这次请求的上下文定向能力，但不阻塞整体响应时延），同时把这个URL放进一个后台抓取队列；后台任务异步抓取这个URL的内容、做内容挖掘、打上标签，写入缓存供之后的请求命中。缓存本身设置TTL，长期没有被访问的URL标签会被清除以节省空间，而访问频繁的热点URL会持续保持在缓存里，实际运行较长时间后，大部分真正有流量价值的热点URL都会被缓存覆盖，冷启动的代价只发生在长尾URL第一次出现的那一瞬间。这套架构模式的普遍价值在于：面对”实时响应预算内做不完的耗时计算”，正确的处理方式不是想办法把耗时计算硬塞进响应时间预算里，而是承认这次请求可能拿不到最优结果（返回空集合、降级处理），把真正的计算挪到异步链路里完成，用缓存把”异步算好的结果”和”下一次同步请求”连接起来——牺牲极少数首次请求的精确度，换取绝大多数请求的稳定低延迟。

结构图：

flowchart TD
    A["广告请求到达\n携带当前网页URL"] --> B{"URL是否命中缓存？"}
    B -->|"命中"| C["立即返回缓存的标签内容"]
    B -->|"未命中"| D["返回空集合\n(不阻塞，放弃本次定向)"]
    D --> E["URL加入后台抓取队列"]
    E --> F["异步抓取网页内容"]
    F --> G["内容挖掘：语义分类/主题模型"]
    G --> H["打标签写入缓存\n设置TTL"]
    H -.->|"下次同一URL请求可命中"| B
    C --> I["长期未访问则TTL过期清除\n热点URL持续保留"]