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

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

咱们都知道，提升系统性能的最简单也最流行的方法之一其实就是使用缓存。咱们引入缓存，至关于对数据进行了复制。每当系统数据更新时，保持缓存和数据源（如 MySQL 数据库）同步相当重要，固然，这也取决于系统自己的要求，看系统是否容许必定的数据延迟。

在这篇文章里，我想给大家介绍最多见的几种缓存策略、它们的优缺点以及使用场景，分别是：

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

请跟随我一块儿来看看吧。

Cache-Aside 策略

Cache-Aside 多是最经常使用的缓存策略。在这种策略下，应用程序(Application)会与缓存(Cache)和数据源(Data Source)进行通讯，应用程序会在命中数据源以前先检查缓存。以下图所示：

咱们来看一次请求数据的过程：

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

Cache-Aside 策略特别适合“读多”的应用场景。使用 Cache Aside 策略的系统能够在必定程度上抵抗缓存故障。若是缓存服务发生故障，系统仍然能够经过直接访问数据库进行操做。

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

Read-Through 策略

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

在进行大量读取时，Read-Through 能够减小数据源上的负载，也对缓存服务的故障具有必定的弹性。若是缓存服务挂了，则缓存提供程序仍然能够经过直接转到数据源来进行操做。

然而，首次请求数据时，老是会致使缓存未命中，并须要额外的时间来将数据加载到缓存中，相信你们都知道怎么处理了吧，仍是“缓存预热”的老套路。

Read-Through 适用于屡次请求相同数据的场景。这与 Cache-Aside 策略很是类似，可是两者仍是存在一些差异，这里再次强调一下：

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

Write-Through 策略

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

实际上，因为须要将数据同步写入缓存和数据源，所以数据写入速度较慢。可是，当与 Read-Through 配合使用时，咱们将得到 Read-Through 的全部好处，而且还能够得到数据一致性保证，从而使咱们免于使用缓存失效技术。

Write-Behind 策略

若是没有强一致性要求，咱们能够简单地使缓存的更新请求入队，而且按期将其 flush 刷新到数据存储中。

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

它能够抵抗数据源故障，并能够容忍某些数据源停机时间。若是支持批处理或合并，则能够减小对数据源的整体写入，从而减小了负载并下降了成本。

可是，一旦更新后的缓存数据还未被写入数据源时，出现系统断电的状况，数据将没法找回。

怎么样，是否是对缓存策略有了进一步认识？