2. 缓存一致性模型：强一致性、弱一致性、最终一致性、读写一致性模型对比

在分布式系统与缓存治理中，一致性模型决定了缓存与数据源之间允许的偏差程度。选择错误的模型会导致业务逻辑错误或性能灾难。本节从一致性强度与性能代价两个维度，对比四种核心模型。

2.1 一致性模型全景对比

2.2 强一致性模型

强一致性要求缓存与数据库之间保持线性一致性：任何读操作必须返回最近一次写操作的结果。实现方式通常为同步双写或分布式事务。

• 实现路径： 写操作先锁数据库 → 更新数据库 → 失效或更新缓存 → 释放锁；读操作必须从主副本读取。
• 性能代价： 每次写操作增加 1~2 次 RTT（往返时延），并发写时锁竞争导致吞吐下降 50%~80%。
• 治理策略： 仅在关键路径使用，如支付状态、库存扣减；非关键字段降级为最终一致性。

2.3 弱一致性与最终一致性

弱一致性不提供任何写后读保证；最终一致性是弱一致性的一个子集，保证在没有新写入时，所有副本最终达到相同状态。

• 最终一致性实现： 异步复制、消息队列、定期全量同步。
• 窗口期： 从写入到所有副本一致的时间称为“不一致窗口”，通常为毫秒到秒级。
• 性能优势： 写操作无需等待副本确认，吞吐可提升 5~20 倍。

2.4 读写一致性模型

读写一致性（Read-Your-Writes Consistency）保证：写入者自己后续的读操作一定能看到自己的写入，但其他用户可能看到旧值。这是用户体验与性能的最佳折中。

• 实现方式： 写操作后，在会话或请求上下文中标记“已写”标识；读操作先检查标识，若命中则强制读数据库或主缓存。
• 典型应用： 用户修改个人资料后刷新页面、提交订单后查看订单详情。
• 性能特征： 仅影响写入者自身，不影响其他用户；写后第一次读增加一次验证开销，后续读恢复正常。

2.5 模型选择决策流程

以下 SVG 图展示了从业务需求到一致性模型选择的决策路径：

2.6 模型性能代价量化对比

以下表格基于典型 Redis + MySQL 架构，对比不同一致性模型在读写混合场景下的性能指标：

2.7 读写一致性实现示例

以下代码展示基于会话标记的读写一致性实现：

// 写操作：更新用户资料后标记会话
public void updateUserProfile(String userId, UserProfile profile) {
    // 1. 更新数据库
    userDao.update(profile);
    // 2. 失效缓存
    cache.delete("user:" + userId);
    // 3. 标记当前会话：该用户有未同步的写入
    CurrentSession.setAttribute("write_flag:" + userId, true);
}

// 读操作：检查会话标记决定读取源
public UserProfile getUserProfile(String userId) {
    // 1. 检查当前会话是否有写标记
    boolean hasWritten = CurrentSession.getAttribute("write_flag:" + userId);
    if (hasWritten) {
        // 2. 强制读数据库并回填缓存
        UserProfile profile = userDao.getById(userId);
        cache.set("user:" + userId, profile, 300);
        CurrentSession.removeAttribute("write_flag:" + userId);
        return profile;
    }
    // 3. 正常读缓存
    UserProfile profile = cache.get("user:" + userId);
    if (profile == null) {
        profile = userDao.getById(userId);
        cache.set("user:" + userId, profile, 300);
    }
    return profile;
}

2.8 模型选择与性能调优原则

• 原则一： 按数据维度拆分，而非按接口维度。同一接口的不同字段可以混合使用不同模型。
• 原则二： 读写一致性作为默认模型，覆盖 90% 的用户操作场景。
• 原则三： 强一致性仅用于“写后立即读且影响后续决策”的关键数据，如支付状态、库存扣减。
• 原则四： 最终一致性用于“读多写少、可容忍短暂不一致”的数据，如用户昵称、商品描述。
• 原则五： 弱一致性仅用于日志、监控、推荐等非关键路径，且必须设置 TTL 兜底。