4、一致性模型：强一致性、最终一致性、因果一致性、会话一致性在缓存中的适用场景

在倒排索引缓存系统中，一致性模型决定了写入操作对后续读取操作的可见性顺序与延迟。不同模型在性能、可用性与数据正确性之间做出不同权衡。本章逐一分析四种核心一致性模型在缓存场景中的适用边界与工程约束。

4.1 一致性模型全景对比

下表从可见性延迟、写入吞吐、典型实现方式三个维度对比四种模型，帮助架构师快速选型。

4.2 强一致性（Strong Consistency）

强一致性保证：一旦写入操作确认返回，后续任何节点的读取操作都能读到该写入的最新值。在缓存系统中，这通常意味着写入必须同步传播到所有副本，并等待法定人数确认。

适用场景

• 倒排索引的词典与跳表指针： 词典中 term 到 posting list 的映射关系一旦变更，所有查询节点必须立即感知，否则会导致查询结果遗漏或重复。
• 分片路由表： 缓存集群的分片拓扑变更（如扩缩容、主从切换）必须全局原子可见。
• 计数器与配额： 缓存命中率统计、限流令牌等需要精确一致的状态。

工程代价

• 写入延迟增加：同步复制等待最慢副本确认。
• 可用性下降：法定人数不可达时写入失败。
• 吞吐瓶颈：单点写入序列化。

4.3 最终一致性（Eventual Consistency）

最终一致性允许写入后存在一个不一致窗口，系统保证在没有新写入的情况下，所有副本最终会收敛到相同状态。这是分布式缓存中最常见的一致性模型。

适用场景

• 文档倒排列表的异步更新： 新增文档的倒排索引可以异步构建并推送到缓存节点，短时间内的查询缺失可接受。
• 搜索结果缓存（TTL 过期）： 热门查询结果的缓存允许短暂过期，由后台任务定期刷新。
• 非关键聚合数据： 如搜索建议、热门词云等允许最终一致的统计信息。

收敛机制

• 反熵协议（Anti-Entropy）： 节点间定期交换 Merkle Tree 哈希，快速发现并修复差异。
• Gossip 传播： 写入事件通过 Gossip 协议在集群内扩散，通常经过 O(log N) 轮次收敛。
• Hinted Handoff： 临时不可达节点恢复后，从邻居节点回放缺失的写入。

4.4 因果一致性（Causal Consistency）

因果一致性保证：如果操作 A 在因果上先于操作 B（A → B），那么所有节点看到 B 时，必须已经看到 A。没有因果关系的并发操作可以乱序可见。

适用场景

• 增量索引更新： 先删除旧文档，再添加新文档（更新操作）——删除必须在添加之前可见。
• 用户会话内的连续查询： 用户先执行搜索，再点击翻页——翻页结果必须基于搜索上下文。
• 多步骤索引构建： 先创建索引段，再更新词典指针——词典更新必须看到索引段就绪。

实现方式

• 向量时钟（Vector Clock）： 每个节点维护一个版本向量，写入时递增本地计数器，读取时检查因果依赖。
• 版本向量（Version Vector）： 类似向量时钟，但只跟踪副本组内的版本，适合固定副本数的缓存集群。

// 向量时钟示例：检测因果依赖
class VectorClock {
    Map<NodeId, Long> clock;

    boolean happensBefore(VectorClock other) {
        boolean lessOrEqual = true;
        boolean strictlyLess = false;
        for (NodeId node : union(clock.keySet(), other.clock.keySet())) {
            long local = clock.getOrDefault(node, 0L);
            long remote = other.clock.getOrDefault(node, 0L);
            if (local > remote) return false;  // 本地有更新，不满足 happens-before
            if (local < remote) strictlyLess = true;
        }
        return strictlyLess;
    }
}

4.5 会话一致性（Session Consistency）

会话一致性保证：在同一个客户端会话内，读取操作满足单调读、单调写、读写一致、写读一致等约束。不同会话之间没有一致性保证。

适用场景

• 搜索分页翻页： 用户翻页时，必须看到前一页相同的搜索结果集，不能因为后台索引更新导致结果漂移。
• 滚动查询（Scroll）： 深度分页场景下，同一 scroll 上下文内的所有查询必须基于同一快照。
• 用户偏好缓存： 用户修改搜索偏好后，同一会话内的后续查询必须应用新偏好。

实现方式

• Sticky Session（会话粘性）： 将同一会话的所有请求路由到同一缓存节点，利用单节点本地顺序保证。
• 会话级版本戳： 客户端携带会话版本戳，缓存节点检查版本戳是否单调递增，拒绝过期读取。
• 快照隔离： 为每个会话创建缓存快照，会话内所有读取基于该快照，写入在会话结束时合并。

// 会话版本戳检查伪代码
class SessionCache {
    Map<SessionId, Long> sessionVersions;

    boolean readAllowed(SessionId sid, long clientVersion) {
        long serverVersion = sessionVersions.getOrDefault(sid, 0L);
        // 单调读：客户端版本必须 ≥ 服务器版本
        return clientVersion >= serverVersion;
    }

    void writeCommit(SessionId sid) {
        sessionVersions.merge(sid, 1L, Long::sum);
    }
}

4.6 一致性模型选择决策树

以下 SVG 图展示在倒排索引缓存架构中，根据数据特征选择一致性模型的决策流程。

4.7 混合一致性策略

实际倒排索引缓存系统很少只使用单一一致性模型。推荐采用 分层混合策略：

4.8 一致性模型与错误处理的集成

一致性模型的选择直接影响错误处理策略：

• 强一致性：写入失败时直接返回错误给客户端，不进行自动重试（避免重复写入导致状态不一致）。
• 最终一致性：写入失败时采用 异步重试队列，配合幂等性保证（如唯一请求 ID）防止重复。
• 因果一致性：因果依赖缺失时返回 409 Conflict，客户端需重放前置操作。
• 会话一致性：会话版本戳不匹配时返回 412 Precondition Failed，客户端需重新建立会话。

// 一致性模型与错误处理集成示例
enum ConsistencyLevel {
    STRONG,       // 失败直接返回错误
    EVENTUAL,     // 失败加入重试队列
    CAUSAL,       // 失败返回 409 + 缺失依赖列表
    SESSION       // 失败返回 412 + 期望版本戳
}

class CacheWriteHandler {
    CompletableFuture<WriteResult> write(WriteRequest req) {
        return switch (req.consistencyLevel()) {
            case STRONG -> writeStrong(req);
            case EVENTUAL -> writeEventual(req);
            case CAUSAL -> writeCausal(req);
            case SESSION -> writeSession(req);
        };
    }

    private CompletableFuture<WriteResult> writeStrong(WriteRequest req) {
        return replicaSet.writeSync(req)
            .thenApply(v -> WriteResult.success())
            .exceptionally(e -> WriteResult.failure("强一致性写入失败: " + e.getMessage()));
    }

    private CompletableFuture<WriteResult> writeEventual(WriteRequest req) {
        return replicaSet.writeAsync(req)
            .thenApply(v -> WriteResult.success())
            .exceptionally(e -> {
                retryQueue.enqueue(req);  // 异步重试
                return WriteResult.accepted("已接受，后台重试");
            });
    }
}