2. 缓存一致性理论：缓存一致性定义、强一致性、弱一致性、最终一致性模型对比
在倒排索引缓存系统中，缓存一致性（Cache Consistency）定义了缓存数据与后端主数据源（如磁盘上的倒排表、正排索引）之间的同步程度。选择错误的一致性模型会导致搜索结果不准确（脏读）或系统吞吐量急剧下降。本节从定义出发，对比四种核心模型。
2.1 缓存一致性定义
缓存一致性指：对于同一份数据，缓存中的副本与主副本（权威数据源）在任意时刻或特定时刻保持内容相同的程度。在倒排索引场景中，一致性体现在：
- 文档更新：新增/删除文档后，缓存中的倒排链是否立即反映该变更。
- 词项合并：索引段合并后，缓存中的段映射是否同步更新。
- 统计值：缓存中的文档频率（DF）、词项频率（TF）是否与实时索引一致。
核心矛盾：强一致性带来高延迟和低并发，弱一致性可能返回过期结果。倒排索引缓存需要在查询准确性与写入吞吐之间做工程权衡。
2.2 四种一致性模型对比
| 模型 | 定义 | 读延迟 | 写延迟 | 适用场景 |
|---|---|---|---|---|
| 强一致性 | 写操作完成后，任何后续读操作都能读到最新写入的值 | 高（需同步验证） | 高（需等待所有副本确认） | 金融搜索、库存精确查询 |
| 弱一致性 | 写操作完成后，不保证后续读操作能立即看到新值 | 低（直接读缓存） | 低（异步更新） | 日志搜索、非实时聚合 |
| 最终一致性 | 在没有新写入的条件下，经过足够长时间后，所有副本最终达到一致 | 低（可能短暂过期） | 中（异步+重试） | 倒排索引缓存、搜索引擎、CDN |
| 因果一致性 | 有因果关系的写操作必须按顺序被观察到 | 中 | 中 | 评论回复、社交搜索 |
工程建议：倒排索引缓存通常选择最终一致性作为默认模型，配合TTL过期和版本号校验来缩小不一致窗口。
2.3 强一致性 vs 最终一致性：倒排索引场景的SVG对比
下图展示强一致性与最终一致性在倒排索引缓存更新流程中的核心差异。左侧强一致性要求缓存写入必须等待主索引确认；右侧最终一致性允许缓存先返回旧数据，后台异步同步。
2.4 最终一致性在倒排索引中的实现策略
倒排索引缓存最常采用最终一致性，以下是三种主流实现方式：
- TTL（Time-To-Live）过期：缓存项设置固定生存时间（如 30s），过期后强制从主索引重新加载。实现简单，但存在短暂不一致窗口。
- 版本号 + 乐观锁：缓存携带主索引的版本号，查询时校验版本；若版本过期则异步回源更新。适合高并发读场景。
- 变更通知 + 缓存失效：主索引发生变更时，通过消息队列（如 Kafka）广播失效事件，缓存节点收到后删除或刷新对应条目。延迟取决于消息队列积压。
避坑提示：不要对倒排索引缓存使用“写穿透（Write-Through）”强一致策略。倒排索引的写入通常是批量合并（Segment Merge），逐条同步会导致写入放大和严重的锁竞争，吞吐量下降 80% 以上。
2.5 一致性模型选择决策树
在实际工程中，可根据以下条件选择合适的一致性模型：
2.6 一致性模型选型总结
| 评估维度 | 强一致性 | 最终一致性 | 倒排索引推荐 |
|---|---|---|---|
| 写入延迟 | 高（同步等待） | 低（异步返回） | 最终一致性 |
| 读延迟 | 高（需校验） | 低（直接命中） | 最终一致性 |
| 实现复杂度 | 低（锁/事务） | 中（版本/队列） | 最终一致性 |
| 吞吐量 | 低（串行化） | 高（并行） | 最终一致性 |
| 数据新鲜度 | 实时 | 秒级延迟 | 按业务容忍度 |
工程经验：在倒排索引缓存中，推荐默认使用最终一致性 + TTL 30s + 版本号校验的组合。对于核心词项（如品牌词、热词），可降级为因果一致性，保证同一用户的操作顺序可见；对于长尾词，直接使用弱一致性以最大化缓存命中率。