4. 缓存一致性模型：强一致性、最终一致性、读写一致性模型对比与选择策略

在分布式系统中，缓存与后端数据库（如 MySQL、PostgreSQL）之间的数据一致性是影响业务正确性与系统性能的核心矛盾。不同的缓存一致性模型在数据准确度、延迟、可用性之间做出不同的权衡。本章将深入对比三种主流模型，并给出在 CI/CD 管道与微服务架构中的选择策略。

4.1 三种核心一致性模型定义

模型 核心定义 典型延迟 适用场景
强一致性 写操作完成后，任何后续读操作都能立即读到最新写入的值。所有副本必须同步更新。 高（同步等待所有副本确认） 金融交易、库存扣减、分布式锁
最终一致性 写操作完成后，不保证立即读到最新值，但经过一段时间（窗口期）后，所有副本最终会收敛到一致状态。 低（异步复制，无等待） 社交动态、内容推荐、日志聚合
读写一致性 保证“读-改-写”操作的原子性，通常通过锁或乐观并发控制实现。写后读在同一会话内保证看到最新值。 中（取决于锁粒度） 会话状态、购物车、计数器
关键认知： 强一致性不等于“绝对正确”，它只保证线性一致性（Linearizability）。最终一致性不等于“最终会错”，它通过版本向量或 CRDT 保证无冲突的收敛。

4.2 模型对比：延迟、吞吐与可用性

以下对比基于典型的分布式缓存架构（如 Redis Cluster + 异步复制）：

维度 强一致性 最终一致性 读写一致性
写延迟 高（需多数派确认） 低（本地写入即返回） 中（需获取锁）
读延迟 低（直接读主副本） 低（可能读到旧数据） 低（锁释放后）
吞吐量 低（串行化写入） 高（并行写入） 中（锁竞争限制）
可用性（网络分区） 低（CP 系统，分区时可能不可用） 高（AP 系统，分区时仍可写入） 中（依赖锁服务可用性）
实现复杂度 高（需 Paxos/Raft） 低（异步复制 + 冲突解决） 中（分布式锁 + 版本号）
常见陷阱： 不要将“强一致性”与“事务”混为一谈。强一致性只保证单个对象的读写顺序，不保证跨对象的事务隔离。跨缓存与数据库的事务仍需分布式事务（如 TCC、Saga）。

4.3 分布式系统中的选择策略

选择一致性模型时，应遵循以下决策树：

  1. 业务是否允许短暂的不一致？
    • 是 → 优先选择 最终一致性（高吞吐、高可用）。
    • 否 → 进入下一步。
  2. 是否需要跨会话的读写原子性？
    • 是 → 选择 读写一致性（如 Redis + Redlock）。
    • 否 → 进入下一步。
  3. 系统是否可接受写延迟增加？
    • 是 → 选择 强一致性（如 etcd、ZooKeeper）。
    • 否 → 考虑 读写一致性 + 最终一致性混合（如写主库、读从库 + 版本校验）。
CI/CD 管道中的典型选择：
  • 构建缓存（Maven/Gradle 依赖）： 最终一致性。构建节点从缓存读取依赖，即使读到旧版本，下次构建也会触发重新下载。
  • 部署状态记录（数据库）： 强一致性。部署状态必须精确，避免重复部署或漏部署。
  • 配置中心（如 Apollo、Nacos）： 读写一致性。配置变更后，客户端必须立即看到最新配置，否则可能导致服务异常。

4.4 一致性模型选择与缓存架构图

下图展示了在分布式缓存系统中，不同一致性模型对应的架构组件与数据流路径：

分布式缓存一致性模型架构选择 客户端 写入请求 强一致性 最终一致性 读写一致性 分布式存储（Redis Cluster / etcd） 选择说明： • 强一致性（紫）：写操作同步到所有副本后才返回，适用于金融、库存等场景。 • 最终一致性（绿）：写操作异步复制，适用于高吞吐、可容忍短暂不一致的场景。 • 读写一致性（橙）：通过锁或版本号保证写后读的原子性，适用于会话状态。

4.5 混合策略：读写一致性 + 最终一致性

在实际系统中，单一模型往往无法满足所有需求。常见的混合策略是：

  • 写操作： 使用读写一致性（如 Redis + Redlock）保证写后读的原子性。
  • 读操作： 使用最终一致性（如从 Redis 从库读取）降低延迟。
  • 补偿机制： 通过异步消息队列（如 Kafka）同步缓存与数据库的最终状态。
CI/CD 管道中的混合策略示例： 
# 部署状态更新（强一致性）
redis-cli SET deploy:app1:status "deploying" NX
# 构建日志写入（最终一致性）
redis-cli RPUSH build:app1:logs "step1 complete"
# 配置变更（读写一致性）
redis-cli WATCH config:app1
redis-cli MULTI
redis-cli SET config:app1 "new_value"
redis-cli EXEC

4.6 选择策略总结矩阵

业务场景 推荐模型 缓存技术选型 注意事项
金融交易、库存扣减 强一致性 etcd、ZooKeeper、Redis Redlock 写延迟敏感，需监控 P99 延迟
社交动态、内容推荐 最终一致性 Redis Cluster、Memcached 设置合理的 TTL 和版本号
会话状态、购物车 读写一致性 Redis + Redlock、MySQL 行锁 锁超时时间需合理配置
配置中心、服务发现 读写一致性 etcd、Consul、Nacos 监听机制（Watch）保证实时性
日志聚合、监控指标 最终一致性 Redis Streams、Kafka 允许数据丢失或重复
性能验证建议： 在 CI/CD 管道中，使用 redis-benchmark 或 memtier_benchmark 对不同一致性模型进行压测，重点关注 P99 延迟和吞吐量。强一致性模型下，建议将写请求的 P99 延迟控制在 10ms 以内。
← 上一章 📖 返回目录 下一章 →