分布式系统：图解缓存与数据库一致性问题

引言：一致性问题的本质

在分布式系统中，缓存（Cache）与数据库（Database）的协同工作是提升系统性能的核心手段。然而，当数据在缓存和数据库之间同步时，由于网络延迟、节点故障或并发操作，两者可能短暂或长期处于不一致状态。这种不一致性会导致业务逻辑错误、数据混乱甚至系统崩溃。本文通过图解方式，系统解析缓存与数据库一致性的核心机制、常见问题及解决方案。

一、一致性问题的核心场景

1.1 缓存穿透（Cache Penetration）

定义：当查询一个数据库中不存在的数据时，缓存未命中，请求直接穿透到数据库，导致数据库压力激增。
图解：

用户请求 → 缓存查询（未命中） → 数据库查询（无数据） → 返回空结果

问题：恶意攻击或高频查询不存在的数据时，数据库可能被压垮。
解决方案：

• 布隆过滤器（Bloom Filter）：预过滤不存在的Key，减少无效查询。
• 空值缓存：将查询结果为空的Key缓存为null，设置短过期时间（如5分钟）。

1.2 缓存击穿（Cache Breakdown）

定义：某个热点Key在缓存过期瞬间被大量请求访问，导致所有请求直接打到数据库。
图解：

缓存过期 → 并发请求 → 同时查询数据库 → 数据库压力激增

问题：热点数据过期时，数据库可能因瞬时高并发而崩溃。
解决方案：

• 互斥锁（Mutex Lock）：在更新缓存时加锁，确保只有一个请求访问数据库。

  public String getData(String key) {
      String value = cache.get(key);
      if (value == null) {
          synchronized (key) { // 互斥锁
              value = cache.get(key); // 双重检查
              if (value == null) {
                  value = db.query(key); // 查询数据库
                  cache.set(key, value, 3600); // 更新缓存
              }
          }
      }
      return value;
  }

• 逻辑过期：缓存中存储数据和过期时间，后台线程异步更新缓存，而非依赖TTL。

1.3 缓存雪崩（Cache Avalanche）

定义：大量缓存Key同时过期，导致所有请求直接访问数据库。
图解：

多个缓存Key同时过期 → 大量请求 → 数据库崩溃

问题：系统可用性急剧下降，甚至完全不可用。
解决方案：

• 随机过期时间：为缓存Key设置随机过期时间（如3600±600秒），避免集中过期。
• 多级缓存：使用本地缓存（如Caffeine）和分布式缓存（如Redis）分层存储，分散请求压力。

二、一致性协议与策略

2.1 Cache-Aside模式（旁路缓存）

流程：

1. 读操作：先查缓存，未命中则查数据库，并更新缓存。
2. 写操作：先更新数据库，再删除缓存（或更新缓存，但删除更安全）。
   图解：

   读：缓存 → 数据库 → 更新缓存  
   写：数据库 → 删除缓存

   优点：实现简单，适合读多写少的场景。
   缺点：写操作后删除缓存与后续读操作可能存在竞态条件。

2.2 Read/Write Through模式

定义：应用层仅与缓存交互，由缓存负责与数据库同步。

• Read Through：缓存未命中时，缓存自动从数据库加载数据。
• Write Through：写操作时，缓存同步更新数据库后再返回成功。
  图解：

  应用 → 缓存（Read Through：自动加载）  
  应用 → 缓存（Write Through：同步更新数据库）

  优点：应用层无需关心数据库，一致性高。
  缺点：写操作延迟增加，性能较低。

2.3 Write Behind模式（异步缓存）

定义：写操作先更新缓存，再异步批量更新数据库。
图解：

应用 → 缓存（立即返回） → 异步线程 → 批量更新数据库

优点：写性能极高，适合写密集型场景。
缺点：一致性风险高，缓存崩溃可能导致数据丢失。

三、分布式环境下的强一致性方案

3.1 分布式锁（如Redis Redlock）

场景：多个节点同时更新缓存和数据库时，需保证原子性。
实现：

// 使用Redlock获取分布式锁
RLock lock = redissonClient.getLock("resource_key");
lock.lock();
try {
    // 执行业务逻辑（更新数据库+删除缓存）
} finally {
    lock.unlock();
}

优点：确保同一时间只有一个节点操作数据。
缺点：性能开销大，需处理锁超时和重试。

3.2 事务消息（如RocketMQ）

场景：跨服务更新缓存和数据库时，需保证最终一致性。
流程：

1. 本地事务提交前发送事务消息到MQ。
2. MQ确认消息后，本地事务提交。
3. 消费者监听消息并更新缓存。
   图解：

   服务A → 发送事务消息 → MQ → 确认后提交事务 → 服务B更新缓存

   优点：解耦服务，保证最终一致性。
   缺点：实现复杂，需处理消息重复和幂等性。

四、最佳实践与建议

1. 缓存策略选择：
   • 读多写少：Cache-Aside + 随机过期。
   • 写密集型：Write Behind + 异步补偿。
2. 监控与告警：
   • 监控缓存命中率、数据库负载，及时发现雪崩或击穿。
3. 降级方案：
   • 缓存服务不可用时，直接访问数据库并限流。
4. 数据分片：
   • 按业务分片缓存，减少单点压力。

结论

缓存与数据库的一致性是分布式系统的核心挑战之一。通过理解穿透、击穿、雪崩等典型问题，结合Cache-Aside、读写穿透等模式，以及分布式锁、事务消息等强一致性方案，开发者可以构建高效且稳定的系统。实际场景中，需根据业务特点（如读写比例、延迟敏感度）权衡一致性与性能，选择最适合的方案。