3. 缓存一致性基础理论：缓存一致性定义、强一致性、弱一致性、最终一致性模型
在倒排索引缓存系统中，缓存一致性（Cache Consistency）定义了缓存节点中的数据与后端持久化存储（如磁盘索引、数据库）中数据之间的同步程度。对于搜索引擎而言，索引的更新（文档新增、删除、修改）必须准确反映到缓存中，否则会导致搜索结果遗漏、重复或排序错误。本章从一致性模型的理论基础出发，为后续的闭环架构设计奠定核心概念框架。
3.1 缓存一致性的核心定义
缓存一致性描述的是：当数据源（Source of Truth）发生写操作后，缓存中的数据在什么时间点、以何种顺序、以何种可见性被后续的读操作所感知。在分布式倒排索引场景中，数据源通常是索引写入节点（Indexer），缓存层则是分布式的内存索引副本（Replica）。
| 维度 | 定义 | 倒排索引场景示例 |
|---|---|---|
| 写后读一致性 | 写入操作完成后，后续的读操作必须能读到该写入的最新值 | 用户新增一篇文档，立即搜索该文档关键词，必须能命中 |
| 单调读一致性 | 如果一个进程先读取到某个值，后续的读操作不会读到更旧的值 | 搜索请求A看到文档v2，同一会话的请求B不会回退到v1 |
| 因果一致性 | 具有因果关系的操作，所有节点必须按因果顺序观察到 | 先删除文档A，再新增文档B；所有副本必须先看到删除，再看到新增 |
3.2 强一致性模型（Strong Consistency）
强一致性要求：任何一次读操作都能读到某个数据的最新写入结果，且所有节点看到的写入顺序完全一致。在分布式缓存中，这通常意味着写入操作必须同步传播到所有缓存副本，或者通过分布式共识协议（如 Paxos、Raft）来保证全局有序。
3.2.1 核心特征
- 线性izability（线性一致性）：操作在时间上有一个全局唯一的顺序，读操作返回的是最近一次写操作的结果。
- 同步复制：写操作必须等待所有（或法定数量）缓存副本确认后才返回成功。
- 无中间状态：缓存要么是旧值，要么是新值，不存在“部分更新”或“脏读”。
3.2.2 在倒排索引中的代价
搜索引擎的索引更新通常是批量操作（每秒数万次写入），强一致性要求每次写入都同步所有副本，会导致：
- 写入延迟剧增：跨网络同步 + 共识协议开销，延迟从毫秒级上升到秒级。
- 可用性下降：如果少数副本故障，写入操作可能被阻塞或拒绝。
- 吞吐量瓶颈：共识协议通常只能处理每秒数千次写入，远低于搜索引擎的写入需求。
3.3 弱一致性模型（Weak Consistency）
弱一致性对一致性的约束最宽松：不保证写操作后读操作能立即看到新值，也不保证不同节点上的读顺序。系统只保证“如果停止写入，经过一段不确定的时间后，所有副本最终会收敛到一致状态”。
3.3.1 核心特征
- 无时效性保证：读操作可能返回过期数据（Stale Data）。
- 无顺序保证：不同客户端可能看到不同的写入顺序。
- 高可用与低延迟：写入只需写入本地缓存或主节点，无需同步等待。
3.3.2 在倒排索引中的应用场景
弱一致性适用于对实时性要求不高的场景，例如：
- 非关键性搜索：如站内搜索的“猜你喜欢”模块，允许几秒到几分钟的延迟。
- 批量索引重建：全量索引构建期间，缓存可以暂时不更新，待重建完成后一次性切换。
- 日志型数据：如点击流日志搜索，用户不要求立即看到刚产生的日志。
3.4 最终一致性模型（Eventual Consistency）
最终一致性是弱一致性的一个特例，也是分布式缓存系统中最常用的一致性模型。它保证：如果系统在一段时间内没有新的写入操作，那么所有缓存副本最终会达到一致状态。最终一致性在“可用性”和“一致性”之间取得了平衡，是倒排索引缓存架构的默认选择。
3.4.1 核心特征
- 收敛性：所有副本最终会持有相同的数据版本。
- 无全局时钟依赖：不要求所有节点有同步的物理时钟。
- 冲突解决机制：当多个写入并发发生时，系统需要定义冲突解决策略（如最后写入者获胜 LWW、向量时钟、CRDT）。
3.4.2 最终一致性的变体
| 变体名称 | 描述 | 倒排索引适用性 |
|---|---|---|
| 读己之写 | 写入者自己后续的读操作一定能看到自己的写入 | 适用于用户个人文档搜索（如笔记、邮件） |
| 会话一致性 | 在同一个会话内，读操作能看到该会话之前的所有写入 | 适用于搜索会话中的分页、排序一致性 |
| 单调读一致性 | 一旦读到某个版本，后续读不会回退到更旧版本 | 适用于搜索结果列表的滚动加载 |
| 因果一致性 | 有因果关系的操作按因果顺序被观察到 | 适用于文档更新链（如先创建再修改） |
3.4.3 最终一致性的收敛时间
收敛时间（Convergence Time）是衡量最终一致性系统质量的关键指标。它取决于：
- 传播延迟：写入从主节点传播到所有副本的网络时间。
- 冲突检测与解决：并发写入的冲突处理时间。
- 反熵机制：后台定期对比和修复差异的周期。
在搜索引擎中，最终一致性的收敛时间通常控制在 秒级到分钟级。例如，Elasticsearch 的 refresh_interval 默认 1 秒，意味着索引写入后最多 1 秒内，新文档对搜索可见。
3.5 三种一致性模型的对比
| 对比维度 | 强一致性 | 弱一致性 | 最终一致性 |
|---|---|---|---|
| 读可见性 | 立即看到最新写入 | 可能看到过期数据 | 最终看到最新写入 |
| 写入延迟 | 高（需同步确认） | 低（本地写入即可） | 中（异步传播） |
| 系统可用性 | 低（部分故障影响写入） | 高（容忍节点故障） | 高（容忍分区和故障） |
| 实现复杂度 | 高（共识协议） | 低（TTL 或简单广播） | 中（冲突解决 + 反熵） |
| 搜索引擎适用性 | 仅元数据 | 非实时搜索 | 主搜索链路 |
3.6 一致性模型在倒排索引缓存中的选择策略
在实际的搜索引擎缓存架构中，不会只使用一种一致性模型，而是根据数据的重要性和实时性要求，采用分层混合策略：
- 元数据缓存（分片路由、索引配置）：使用强一致性，通过 ZooKeeper/Etcd 等共识服务保证。
- 热词缓存（高频搜索词对应的倒排列表）：使用最终一致性，通过异步消息队列 + 版本号比对实现。
- 冷词缓存（低频搜索词）：使用弱一致性，设置较长的 TTL（如 5-10 分钟），过期后重新加载。
- 实时索引缓存（最近几秒写入的文档）：使用最终一致性，配合 refresh_interval 和 translog 机制。
3.7 一致性模型与缓存失效策略的关系
一致性模型决定了缓存失效（Cache Invalidation）的触发方式和粒度：
| 一致性模型 | 失效策略 | 说明 |
|---|---|---|
| 强一致性 | 同步失效（Write-through） | 写入时同步更新或删除所有缓存副本 |
| 弱一致性 | TTL 过期失效 | 缓存项到期后自动失效，不主动通知 |
| 最终一致性 | 异步失效 + 版本校验 | 写入后发送失效消息，副本收到后对比版本号，不一致则重新加载 |
在倒排索引缓存中，最常用的失效策略是基于版本号的异步失效：每个索引段（Segment）或文档分片（Shard）维护一个递增的版本号，缓存节点在服务读请求时，附带版本号与数据源比对，若版本落后则触发异步刷新。
3.8 一致性模型选择对系统设计的影响
选择不同的一致性模型，会直接影响缓存系统的通信机制、数据结构和故障恢复策略：
- 强一致性：需要引入分布式共识协议（如 Raft），通信开销大，但系统设计简单（无冲突）。
- 弱一致性：通信最轻量，但需要容忍数据过期，且需要设计“过期后如何优雅降级”。
- 最终一致性：需要设计反熵协议（Anti-Entropy）和冲突解决逻辑，通信机制最复杂，但灵活性和可扩展性最好。