3. 数据一致性模型：强一致性、最终一致性、弱一致性在缓存场景下的选择

在缓存与数据库并存的架构中，数据一致性模型决定了系统在面对写入与读取并发时的行为边界。选择错误的模型会导致业务逻辑错误或性能灾难。本节从缓存场景出发，剖析三种一致性模型的核心差异、适用条件与实现代价。

3.1 三种一致性模型的定义与缓存语义

3.2 强一致性：缓存穿透与同步写策略

强一致性要求缓存与数据库在任何时刻都保持同步。实现路径通常有两种：

1. 同步双写 + 分布式锁： 写操作先获取锁，同时更新数据库和缓存，释放锁后其他读请求才能访问缓存。
2. 缓存穿透读： 每次读取都绕过缓存直接查询数据库，或读取缓存后立即与数据库版本号比对，不一致则回源。

以下 SVG 展示了强一致性模式下写入与读取的完整流程：

3.3 最终一致性：异步更新与补偿机制

最终一致性是缓存场景中最常用的模型。它允许缓存短暂过期，但保证在可接受的时间窗口内（通常毫秒到秒级）达到一致。实现方式包括：

• Cache-Aside + 异步淘汰： 写操作只更新数据库，通过消息队列异步淘汰或更新缓存。
• Read-Through + TTL： 缓存自带过期时间，过期后自动回源加载最新数据。
• Binlog 监听： 监听数据库变更日志（如 MySQL Binlog），异步同步到缓存。

以下 SVG 展示了最终一致性模式下典型的异步更新流程：

3.4 弱一致性：无校验的极致性能

弱一致性在缓存场景中几乎不做任何一致性保证。缓存可能长期与数据库不一致，直到被手动刷新或 TTL 过期。这种模型通常用于：

• 静态数据： 如国家列表、字典表、枚举值，几乎不变。
• 非关键计数： 如文章阅读数、点赞数，允许一定误差。
• 预加载数据： 启动时加载到缓存，运行期间不更新。

3.5 三种模型的对比与选择决策树

选择决策树：

1. 业务是否允许缓存数据在短时间内（1-5 秒）过期？
   → 是：选择 最终一致性，这是 80% 场景的最优解。
   → 否：进入下一步。
2. 数据是否几乎不变（静态数据）？
   → 是：选择 弱一致性，极致性能。
   → 否：进入下一步。
3. 是否必须保证每次读取都是最新数据（如支付、库存）？
   → 是：选择 强一致性，接受性能代价。
   → 否：重新评估业务需求，通常最终一致性已足够。