数据一致性问题

三种策略

1. 旁路缓存 (Cache-Aside)

• 工作方式：应用程序代码既要操作缓存，也要操作数据库。缓存只是一个在“旁边”的辅助工具。
  • 读：应用先读缓存，没有就自己读数据库，再写回缓存。
  • 写：应用直接更新数据库，再删除缓存。
• 使用场景:
  • 这是最通用、最灵活、最常用的模式，适用于绝大多数互联网应用。
  • 当你使用 Redis、Memcached 这类通用缓存中间件时，基本都是采用这种模式。
  • 适用于读多写少，并且可以接受最终一致性的系统。

2. 读写穿透 (Read/Write-Through)

• 工作方式：应用程序代码只和缓存打交道，把缓存当作唯一的数据源。缓存服务自身负责与数据库的同步。
  • 读：应用只管读缓存，缓存没有时会自己去数据库加载。
  • 写：应用只管写缓存，缓存会立刻、同步地将数据写入数据库。
• 使用场景:
  • 对数据一致性要求极高的场景，比如金融领域的账户余额、电商的库存管理等，绝对不能读到旧数据。
  • 当你想简化应用程序逻辑，将数据持久化的复杂性封装在缓存层时。
  • 缺点是写入性能会因为同步等待数据库而降低。

3. 写回 (Write-Back)

• 工作方式：应用程序也只和缓存打交道，但为了追求极致的写入性能，它将对数据库的写入变成了异步的。
  • 读：和读穿透一样。
  • 写：应用把新数据给缓存，缓存立刻就返回成功，然后在稍后的某个时间点，再异步地把数据写入数据库。
• 使用场景:
  • 写操作极其频繁，对写入性能要求远超对数据可靠性要求的场景。
  • 可以容忍少量数据丢失。因为如果缓存在数据写入数据库前宕机，这部分数据就会永久丢失。
  • 典型例子：高频的网站文章点赞数、阅读数统计，或者监控数据上报。

旁路缓存模式下的具体策略

现在，我们聚焦于最常用的旁路缓存模式。既然应用程序要自己负责写数据，那么“先写数据库”还是“先操作缓存”？这个顺序很重要，由此衍生出几种具体的策略。

策略一：先更新数据库，再删除缓存 (推荐)

• 流程：写请求来了，先去改数据库里的数据，改成功了，再去把缓存里的旧数据删掉。
• 使用场景:
  • 这是旁路缓存模式的 “标准答案”和首选策略。
  • 适用于绝大多数需要加缓存的Web应用，是新项目设计的默认选择。它在实现简单性、性能和数据一致性之间取得了最佳平衡。

策略二：延迟双删

• 流程：先删缓存，再改数据库，然后等一会儿，再把缓存删一次。
• 使用场景:
  • 这是一个 “打补丁”的补偿方案。
  • 当你的系统已经采用了“先删缓存，再更新数据库”这种有缺陷的策略，并且正因此遭受并发数据不一致问题的困扰时，可以用它来快速修复和缓解问题。
  • 不推荐在新项目或架构重构中作为首选设计。

策略三：通过Binlog异步同步

• 流程：你的应用程序只管改数据库。另外有一个独立的“侦探”程序，通过订阅数据库的变更记录（Binlog），来负责删除缓存。
• 使用场景:
  • 这是一个更高级、更可靠的 “企业级”解决方案。
  • 适用于大型、复杂的微服务系统，特别是当一个数据变更需要通知多个下游系统或更新多种缓存时。
  • 当你的团队对系统解耦和高可靠性有强烈追求，并且不介意引入额外组件增加架构复杂度时使用。