一文带你搞懂“缓存策略”

9,493 阅读4分钟

本文由 yanglbme 原创,首发于公众号“Doocs开源社区”,欢迎转载。

我们都知道,提高系统性能的最简单也最流行的方法之一其实就是使用缓存。我们引入缓存,相当于对数据进行了复制。每当系统数据更新时,保持缓存和数据源(如 MySQL 数据库)同步至关重要,当然,这也取决于系统本身的要求,看系统是否允许一定的数据延迟。

在这篇文章里,我想给你们介绍最常见的几种缓存策略、它们的优缺点以及使用场景,分别是:

  • Cache-Aside
  • Read-Through
  • Write-Through
  • Write-Behind

请跟随我一起来看看吧。

Cache-Aside 策略

Cache-Aside 可能是最常用的缓存策略。在这种策略下,应用程序(Application)会与缓存(Cache)和数据源(Data Source)进行通信,应用程序会在命中数据源之前先检查缓存。如下图所示:

Cache-Aside

我们来看一次请求数据的过程:

  • 首先,应用程序先确定数据是否保留在缓存中;
  • 如果数据在缓存中,也即 Cache hit ,称作“缓存命中”。数据直接从缓存中读取并返回给客户端应用程序;
  • 如果数据不在缓存中,也即 Cache miss,称作“缓存未命中”。应用程序会从数据存储的地方,如 MySQL 数据源中读取该数据,并将数据存储在缓存中,然后将其返回给客户端。

Cache-Aside 策略特别适合“读多”的应用场景。使用 Cache Aside 策略的系统可以在一定程度上抵抗缓存故障。如果缓存服务发生故障,系统仍然可以通过直接访问数据库进行操作。

然而,这种策略并不能保证数据存储和缓存之间的一致性,需要配合使用其它策略来更新或使缓存无效。另外,首次请求数据时,总是会导致缓存未命中,这种情况下需要额外的时间来将数据加载到缓存中。为了解决这个问题,开发人员可以通过手动触发查询操作来对数据进行“预热”。

Read-Through 策略

在上面的 Cache-Aside 策略中,应用程序需要与缓存和数据源“打交道”,而在 Read-Through 策略下,应用程序无需管理数据源和缓存,只需要将数据源的同步委托给缓存提供程序 Cache Provider 即可。所有数据交互都是通过抽象缓存层完成的。

Read-through

在进行大量读取时,Read-Through 可以减少数据源上的负载,也对缓存服务的故障具备一定的弹性。如果缓存服务挂了,则缓存提供程序仍然可以通过直接转到数据源来进行操作。

然而,首次请求数据时,总是会导致缓存未命中,并需要额外的时间来将数据加载到缓存中,相信大家都知道怎么处理了吧,还是“缓存预热”的老套路。

Read-Through 适用于多次请求相同数据的场景。这与 Cache-Aside 策略非常相似,但是二者还是存在一些差别,这里再次强调一下:

  • Cache-Aside 中,应用程序负责从数据源中获取数据并更新到缓存。
  • 而在 Read-Through 中,此逻辑通常是由独立的缓存提供程序支持。

Write-Through 策略

Write-Through 策略下,当发生数据更新(Write)时,缓存提供程序 Cache Provider 负责更新底层数据源和缓存。缓存与数据源保持一致,并且写入时始终通过抽象缓存层到达数据源。

Write-Through

实际上,由于需要将数据同步写入缓存和数据源,因此数据写入速度较慢。但是,当与 Read-Through 配合使用时,我们将获得 Read-Through 的所有好处,并且还可以获得数据一致性保证,从而使我们免于使用缓存失效技术。

Write-Behind 策略

如果没有强一致性要求,我们可以简单地使缓存的更新请求入队,并且定期将其 flush 刷新到数据存储中。

Write-Behind

也就是说,Write-Behind 在数据更新时,只写入缓存。优点是数据写入速度快,适用于繁重的写工作负载。与 Read-Through 配合使用,可以很好地用于混合工作负载,最近更新和访问的数据总是在缓存中可用。

它可以抵抗数据源故障,并可以容忍某些数据源停机时间。如果支持批处理或合并,则可以减少对数据源的总体写入,从而减少了负载并降低了成本。

但是,一旦更新后的缓存数据还未被写入数据源时,出现系统断电的情况,数据将无法找回。

怎么样,是不是对缓存策略有了进一步认识?

欢迎关注我的微信公众号“Doocs开源社区”,原创技术文章第一时间推送。