3. 缓存同步的常见数据一致性模型：最终一致性、读己之写、强同步的取舍

在多模块缓存同步场景中，选择哪种数据一致性模型直接影响系统的吞吐量、延迟和用户体验。不同模块对一致性的敏感度不同——订单模块要求严格一致，而商品推荐模块可以容忍短暂不一致。本章从原理、流程和实现代价三个维度剖析三种主流一致性模型，并给出模块边界内的取舍策略。

3.1 三种模型的核心定义

3.2 模型取舍的底层逻辑

选择一致性模型本质是在 可用性 (A)、延迟 (L) 和 一致性 (C) 之间做三角权衡。根据 CAP 与 PACELC 理论，在分区发生时，系统必须在一致性和可用性之间选择；在正常运行时，需要在延迟和一致性之间权衡。

• 最终一致性：优先保证可用性和低延迟，异步复制，适合对时效性不敏感的批量读场景。
• 读己之写：在最终一致性基础上，通过会话粘性（Session Stickiness）或版本戳为同一客户端提供“读写因果”保证，牺牲少量全局一致性换取用户体验。
• 强同步：所有写入必须同步到所有副本或法定数量副本后才返回，线性一致性最高，但可用性受副本数量和网络延迟影响。

3.3 三种模型数据流对比

下面的 SVG 展示了从“客户端写请求”到“客户端读返回”的完整数据流，突出同步阶段的核心差异。

3.4 决策矩阵：模块场景 → 模型映射

下表从 写入频次、读写比例、容忍延迟 和 一致性敏感度 四个维度给出选择建议：

3.5 代码实现对比：三种模型的写入逻辑

以下三段伪代码展示了在同一个缓存抽象层中，通过切换同步策略实现不同一致性模型。

最终一致性写入：

// EventualConsistencyCache.java
public CompletableFuture<Boolean> set(String key, Object value) {
    // 1. 写入主节点（本地内存或 Redis 主节点）
    primaryCache.put(key, value);
    
    // 2. 发送异步同步事件，不等待副本确认
    asyncSyncQueue.publish(new CacheSyncEvent(key, value, version));
    
    // 3. 立即返回成功
    return CompletableFuture.completedFuture(true);
}

读己之写写入：

// ReadYourWritesCache.java
public boolean set(String key, Object value, String sessionId) {
    // 1. 写入主缓存
    primaryCache.put(key, value);
    
    // 2. 在会话存储中记录本次写入的版本时间戳
    sessionVersionStore.put(sessionId, key, System.nanoTime());
    
    // 3. 同步到副本（异步），但读己之写保证由会话标记兜底
    asyncSyncQueue.publish(new CacheSyncEvent(key, value, version));
    
    return true;
}

// 读取时检查会话版本，决定从主节点还是副本读取
public Object get(String key, String sessionId) {
    Long writeVersion = sessionVersionStore.get(sessionId, key);
    if (writeVersion != null) {
        // 该会话有未同步的写入，直接从主节点读取
        return primaryCache.get(key);
    } else {
        // 没有归属写入，从副本读取降低主节点压力
        return replicaCache.get(key);
    }
}

强同步写入：

// StrongConsistencyCache.java
public boolean set(String key, Object value, int quorum) {
    // 1. 写入主节点
    primaryCache.put(key, value);
    
    // 2. 并行写入所有副本，收集确认
    AtomicInteger ackCount = new AtomicInteger(1); // 主节点自身算 1 个确认
    CountDownLatch latch = new CountDownLatch(replicas.size());
    
    for (CacheReplica replica : replicas) {
        executor.submit(() -> {
            if (replica.put(key, value)) {
                ackCount.incrementAndGet();
            }
            latch.countDown();
        });
    }
    
    // 3. 等待法定数量确认（超时时间 500ms）
    boolean finished = latch.await(500, TimeUnit.MILLISECONDS);
    if (ackCount.get() >= quorum) {
        return true;   // 写入成功，所有后续读都能看到
    } else {
        // 回滚或标记失败
        primaryCache.delete(key);
        return false;  // 未达到法定确认，告知调用方失败
    }
}

3.6 模块边界隔离与模型选择

在多模块架构中，每个模块应独立选择其缓存一致性模型，并通过明确的模块边界 API 文档对外暴露保证等级。以下是一个模块边界描述的例子：

// ============================================================
// 模块: InventoryService (库存服务)
// 缓存一致性保证: 强同步
// 对外契约:
//   - deStock(itemId, quantity) 返回 true 表示库存已扣减，
//     所有后续读库存请求（包括跨模块）均能看到最新库存。
//   - 返回 false 表示扣减失败，库存未变更。
// 降级策略:
//   - 当强同步超时 > 200ms 时，自动切换为读己之写模式，
//     并在响应头中附加 X-Consistency: read-your-writes 标记。
// ============================================================

这种方式让调用方（其他模块）明确知道当前返回的数据一致性等级，避免因缓存不一致导致跨模块数据错误。

3.7 常见错误与避坑清单

• 误用最终一致性处理支付回调： 支付状态变更后，库存和订单模块必须立即读到最新状态，应使用强同步或至少读己之写，否则会导致超卖。
• 忽略会话粘性丢失： 读己之写依赖会话标记，如果客户端请求在模块间轮询（例如网关层负载均衡切换节点），会话标记丢失会导致读到旧数据。解决方案：将会话标记存入全局缓存（如 Redis）而非本地内存。
• 强同步的写放大： 每次写入等待所有副本确认，写入吞吐量随副本数增加而下降。当副本数 > 3 时，考虑使用多数派 quorum 而非全量确认。
• 混淆“最终一致性”与“无一致性”： 最终一致性要求副本最终达到一致，需要引入版本向量或 CRDT 来解决冲突，而不是简单地丢弃冲突。

3.8 性能指标参考

测试条件： 3 节点 Redis 集群，主节点写 + 2 副本同步，千兆网络，value 大小 1KB，客户端连接池 50。

以上数据表明，强同步的写入代价远高于其他两种模型，且随副本数量增加近似线性上升。在模块边界设计时，应将高频写入的 key 尽量分配到最终一致性或读己之写模型，仅在数据一致性出现争议时（如支付、库存）才使用强同步。