4. 倒排索引缓存场景分析：查询缓存、词典缓存、倒排列表缓存、聚合结果缓存

在搜索引擎与倒排索引系统中，缓存是降低磁盘I/O、缩短查询响应时间的核心手段。然而，不同缓存场景在数据粒度、更新频率、一致性要求上存在显著差异。本章对四种典型缓存场景进行深度分析，明确各自的数据特征、访问模式与一致性挑战。

4.1 缓存场景全景对比

下表从数据粒度、典型大小、更新方式、一致性敏感度四个维度，对四种缓存场景进行横向对比：

4.2 查询缓存（Query Cache）

查询缓存以完整查询请求为键，以搜索结果集为值。典型场景包括：热门搜索词、分页翻页、相同过滤条件的重复查询。

• 数据特征：键空间大但命中率集中在头部；结果集大小随查询复杂度变化。
• 更新触发：索引变更（新增/删除文档）、词典更新、排序权重调整。
• 一致性策略：全量缓存失效（Flush All）或按索引版本号批量过期。
• 典型实现：LRU + TTL 组合，配合查询归一化（去除空格、大小写折叠）。

// 查询缓存伪代码示例
class QueryCache {
    cache: Map<string, SearchResult>
    maxSize: int
    ttlMs: long

    fun get(query: NormalizedQuery): SearchResult? {
        val key = query.normalizedKey()
        val entry = cache[key] ?: return null
        if (now() - entry.timestamp > ttlMs) {
            cache.remove(key)
            return null
        }
        return entry.result
    }

    fun invalidateOnIndexChange(version: long) {
        // 当索引版本号变更时，清空全部查询缓存
        cache.clear()
    }
}

4.3 词典缓存（Dictionary Cache）

词典缓存存储词项 → 倒排列表元数据的映射关系，包括文档频率（DF）、倒排列表指针、压缩参数等。它是查询解析阶段的第一道关卡。

• 数据特征：键值对数量大（百万～亿级），但单条记录极小（几十字节）。
• 更新触发：增量索引合并、新词项加入、DF 值变化。
• 一致性策略：版本号 + 按词项粒度失效；支持读写分离（读旧版本 + 后台预热新版本）。
• 典型实现：ConcurrentHashMap + 分段锁 + 版本戳。

4.4 倒排列表缓存（Posting List Cache）

倒排列表缓存存储词项 → 文档ID列表（含位置信息、payload）。这是缓存中数据量最大、内存消耗最严重的场景。

• 数据特征：每个词项的倒排列表长度差异极大（高频词百万级，低频词个位数）。
• 更新触发：分段（Segment）合并、文档更新、删除操作。
• 一致性策略：分段级失效 + 写时复制（Copy-on-Write）；允许短暂读取旧分段。
• 典型实现：按分段组织缓存，每个分段维护独立版本号；查询时合并多个分段缓存结果。

// 倒排列表缓存分段管理示意
class SegmentPostingCache {
    data class Segment(val id: Long, val version: Long, val postings: Map<String, PostingList>)

    private val segments = CopyOnWriteArrayList<Segment>()

    fun getPostings(term: String): List<PostingList> {
        return segments.mapNotNull { it.postings[term] }
    }

    fun replaceSegment(newSegment: Segment) {
        // 原子替换旧分段，不影响正在进行的查询
        segments.removeAll { it.id == newSegment.id }
        segments.add(newSegment)
    }
}

4.5 聚合结果缓存（Aggregation Cache）

聚合结果缓存存储分组统计、排序、去重计数、直方图等计算密集型结果。常用于仪表盘、报表、推荐系统。

• 数据特征：结果集小（KB级），但计算代价高（需扫描大量文档）。
• 更新触发：定时刷新、数据变更事件、手动预热。
• 一致性策略：最终一致性 + 异步刷新；允许返回近似值（如 HyperLogLog 基数估计）。
• 典型实现：后台定时任务 + 双缓冲（Double Buffer）切换。

4.6 四种缓存场景的一致性闭环架构

下图展示了四种缓存场景在倒排索引系统中的位置，以及一致性闭环的通信路径：

4.7 场景选择与一致性权衡

在实际系统中，并非所有场景都需要强一致性。以下决策树可帮助架构师快速选择策略：

1. 用户是否直接感知结果？ → 是 → 查询缓存、词典缓存 → 强一致性或版本校验。
2. 数据量是否超过内存上限？ → 是 → 倒排列表缓存 → 分段失效 + 写时复制。
3. 结果是否允许近似？ → 是 → 聚合结果缓存 → 异步刷新 + TTL。
4. 更新频率是否极高？ → 是 → 考虑降低缓存粒度或放弃缓存，改用实时计算。