1. 课程导论：倒排索引缓存一致性闭环方案
1.1 倒排索引基础概念
倒排索引（Inverted Index）是全文检索系统的核心数据结构。与正排索引（Forward Index）以文档ID为键不同，倒排索引以词项（Term）为键，记录该词项出现在哪些文档中，以及在该文档中的位置信息。这种结构使得关键词搜索可以在毫秒级完成，是Elasticsearch、Solr、Lucene等搜索引擎的基石。
| 对比维度 | 正排索引 | 倒排索引 |
|---|---|---|
| 键结构 | 文档ID → 文档内容 | 词项 → 文档ID列表 |
| 查询效率 | 需扫描全量文档，O(n) | 直接定位词项，O(1) ~ O(log n) |
| 存储开销 | 较低，无需额外映射 | 较高，需维护词典+倒排表 |
| 典型应用 | 关系型数据库B+树 | 搜索引擎、日志分析 |
在分布式系统中，倒排索引通常被拆分为多个分片（Shard）分布在集群节点上。每个分片维护自己的倒排表，查询时需合并多个分片的结果。这种架构虽然提升了写入和存储的扩展性，但也引入了缓存一致性的挑战。
关键认知：倒排索引的缓存不是简单的KV缓存，而是包含词典缓存（Term Dictionary Cache）、倒排表缓存（Postings Cache）、文档值缓存（Doc Values Cache）三层结构。每一层的失效策略和一致性要求都不同。
1.2 缓存一致性问题背景
在分布式倒排索引场景中，缓存一致性问题的根源在于：写入操作发生在主节点或分片主副本，而查询操作可能落在任意副本节点。当索引文档发生增、删、改时，如果缓存没有及时更新，就会产生以下三类典型问题：
- 脏读（Stale Read）：查询命中了过期缓存，返回了已被删除或修改的文档。
- 幻读（Phantom Read）：新写入的文档在缓存中不可见，导致查询结果缺失。
- 缓存雪崩（Cache Avalanche）：大量缓存同时失效，导致后端存储压力骤增，系统响应时间飙升。
| 问题类型 | 触发场景 | 影响范围 | 典型后果 |
|---|---|---|---|
| 脏读 | 文档更新后缓存未失效 | 单条查询 | 搜索结果包含已删除内容 |
| 幻读 | 新文档写入后缓存未加载 | 范围查询 | 搜索结果缺失最新数据 |
| 缓存雪崩 | 大量缓存同时过期/失效 | 全局查询 | 数据库/存储层过载 |
工程痛点：在传统缓存方案中，通常使用TTL（Time-To-Live）被动失效策略。但对于倒排索引，TTL设置过短会导致缓存命中率下降，设置过长则一致性窗口过大。实测数据显示，在每秒10万次查询的集群中，TTL每增加1秒，一致性窗口内可能产生约10万次脏读。
1.3 闭环方案总体架构
本课程提出的倒排索引缓存一致性闭环方案，核心思想是构建一个写-失效-确认-重建的闭环链路，确保缓存与底层索引数据始终保持最终一致。整体架构分为四个核心模块：
- 变更捕获层（Change Capture Layer）：监听索引写入日志（如Elasticsearch的Translog、Lucene的Segment Flush），实时捕获文档变更事件。
- 失效决策层（Invalidation Decision Layer）：根据变更类型（新增/更新/删除）和缓存层级，生成精确的失效指令，避免全量缓存清空。
- 缓存重建层（Cache Rebuild Layer）：异步从底层索引重新加载受影响的缓存条目，支持批量重建和优先级调度。
- 一致性校验层（Consistency Verification Layer）：定期对缓存与索引进行哈希比对，发现不一致时触发修复流程。
闭环核心指标：本方案追求在99.9%的查询场景下，缓存与索引的一致性延迟控制在500ms以内。通过变更捕获的实时性、失效决策的精确性、缓存重建的并发度以及一致性校验的周期性，形成完整的闭环保障。