3. 强一致性 vs 最终一致性：定义、业务场景选择、一致性级别对系统的影响

在缓存与数据库协同工作的架构中，一致性模型的选择直接决定了系统的正确性、可用性与性能。本章深入剖析强一致性与最终一致性的核心定义、适用场景以及不同一致性级别对系统架构产生的深远影响。

3.1 核心定义与对比

3.2 业务场景选择指南

选择哪种一致性模型，取决于业务对数据准确性和系统响应速度的容忍度。以下场景分类可作为决策参考：

• 强一致性优先场景：
  • 金融交易：账户余额扣减、转账操作，必须保证读到的余额是最新的，否则会导致资金错乱。
  • 库存扣减：电商秒杀场景，超卖会直接造成经济损失，需要强一致性保证库存不超卖。
  • 分布式锁：Redis 的 Redlock 或 ZooKeeper 的临时顺序节点，必须保证锁的唯一性。
  • 配置中心：服务配置的变更必须立即生效，否则可能导致服务行为不一致。
• 最终一致性可接受场景：
  • 社交动态：用户发布朋友圈，允许其他用户几秒后才看到，不影响核心体验。
  • 阅读计数：文章阅读量、点赞数，允许短暂偏差，最终汇总正确即可。
  • 用户资料缓存：用户修改昵称后，允许 CDN 或本地缓存延迟更新。
  • 日志收集：系统日志允许丢失少量或延迟到达，不影响业务主流程。

3.3 一致性级别对系统的影响

一致性级别从强到弱，对系统的性能、可用性、复杂度和数据正确性产生不同影响。下表总结了常见一致性级别及其影响：

3.4 一致性模型选择决策流程

以下 SVG 流程图展示了在实际项目中如何根据业务需求选择合适的一致性模型：

3.5 一致性级别对系统架构的深层影响

选择不同的一致性级别，不仅影响数据正确性，还会重塑系统的架构形态和运维策略：

• 强一致性架构影响：
  • 需要引入分布式协调服务（如 ZooKeeper、Etcd）或分布式事务框架（如 Seata）。
  • 数据库写入必须等待所有副本确认，导致写入延迟随副本数线性增长。
  • 网络分区时，系统可能牺牲可用性（CP 系统），拒绝写入以保持一致性。
  • 缓存策略必须采用“先更新数据库，再删除缓存”或“分布式锁”来避免脏读。
• 最终一致性架构影响：
  • 可以采用异步复制、消息队列（如 Kafka、RabbitMQ）进行数据同步。
  • 系统可用性高，网络分区时仍可继续服务（AP 系统）。
  • 需要引入补偿机制（如定时校对、读修复）来处理不一致窗口。
  • 缓存策略可以采用“先更新缓存，再异步更新数据库”或“缓存过期+回源”模式。

3.6 一致性级别与 CAP 理论的关联

一致性级别的选择本质上是 CAP 理论在工程中的具体体现。以下 SVG 图展示了不同一致性级别在 CAP 三角中的位置：

3.7 一致性级别测试验证要点

在测试缓存与数据库一致性时，需要针对不同一致性级别设计不同的验证策略：