缓存和数据库双写的四种策略分析

 概述

        缓存是提升系统性能的极为简便的手段之一。相较而言，数据库（或者 NoSQL 数据库）的运行速度较为迟缓，然而速度在很多时候却是决胜的关键要素。采用缓存能够降低响应时间、减轻数据库负载并且节约成本。 正因如此，往往需要同时对数据库和缓存进行写入操作，不同的缓存策略在处理读写操作、确保数据一致性以及优化系统性能等方面均具备各自的特性与适用场景。选择恰当的缓存策略乃是提升性能的关键所在。

        本文梳理了几种常见的缓存策略，例如 Cache Aside、Read/Write Through、Write-Around 以及 Write Back 等，剖析了它们的工作原理、优点与缺点，以及在实际应用中的考量要点，助力您在开发过程中作出明智的抉择，从而构建出高效且可靠的系统。

一、CacheAside策略

        CacheAside，即旁路缓存，是业界应用最为广泛的缓存业务代理方式。通过 Facebook 的论文《Scaling Memcache at Facebook》能够了解到，Facebook 公司内部同样采用了这一策略。

查询流程：首先于缓存中进行查询，如果命中缓存，则直接返回结果；倘若未命中，则前往数据库获取数据，获取成功后，再将数据存入缓存。
新增操作：将数据新增至数据库，缓存不进行任何操作。
更新操作：把数据更新至数据库，成功之后，使缓存失效。
删除操作：在数据库中删除数据，成功之后，令缓存失效。

CacheAside会有什么问题吗？

假设存在两个请求，一个请求 A 执行查询操作，另一个请求 B 执行更新操作，那么可能会出现如下情况。
缓存不存在。
请求 A 从数据库查询获取旧值。
请求 B 将新值更新至数据库。
请求 B 删除缓存。
请求 A 将查询到的旧值写入缓存。

不过发生上述情况有一个先天条件：

1、进行读操作时，缓存中没有数据，这样他才会去数据提供方获取数据

2、在进行读操作的同时，存在一个写操作

3、读操作在数据提供方读取数据所耗费的时长大于写操作，这种情况较为罕见。

4、在在读写操作并发时，读取到的是旧值。

单独论及一条，正常情况下，读操作要比写操作迅速得多，所以上述四条同时满足的概率极低。

那么，要解决上述问题有什么办法呢？是有的，那便是采用延迟双删方案：
        延迟双删是一种用于保障数据一致性的常见策略，其基本理念在于更新数据库之后，先删除缓存，接着等待一段时间，然后再次删除缓存。这样做的目的是为了避免在数据库和缓存主从同步的过程中，有其他请求查询到旧的缓存数据，并重新写回到缓存中。具体流程如下：

1、删除缓存数据

2、更新数据库数据

3、休眠一段时间，时间依据数据的读取耗费的时间而定。

4、再次删除缓存数据

二、Read/WriteThrough策略

       在 Cache Aside 中，尽管出现数据不一致的概率极低，我们也采用了延迟双删，但依旧较为复杂。不过，若要规避缓存不一致的情况也较为简单，即在进行写入操作时，直接将结果写入缓存，然后从缓存同步写入到数据提供方。等到写入数据提供方的操作完成之后，才返回写入操作的结果。这便是 Read/Write Through 写入机制。
        在这种机制下，调用方仅需与缓存进行交互，无需关注缓存后方的数据提供方。而由缓存来确保自身数据与数据提供方的一致性。读操作仅与缓存打交道，直接读取缓存的结果；写操作的话，调用方写入缓存，再由缓存同步写入数据提供方。

与 Cache-Aside 的区别：
        在 Cache Aside 机制中，数据写入缓存的操作，是由调用方的查询结果触发的。
而在 Read/WriteThrough 机制中，则要求缓存在启动时，自身完成将所有数据从数据提供方读入缓存的过程（在项目启动时，倘若真正初始化时一无所有，也没有需要读取的内容，后续有修改，缓存便是新的数据，也就无需读取）。
比较一下 Cache Aside 和 Read/WriteThrough 机制。在 Cache Aside 中，缓存仅仅是一个辅助的角色，即便缓存不工作，调用方也能够通过数据提供方完成所有的读写操作，正如其名称所示，缓存在一旁。
        然而在 Read/write through 中，缓存直接与调用方对接，屏蔽了数据提供方，这意味着缓存系统不可或缺，且要求极为可靠。

三、Write-Around策略

        在这种策略下，数据直接写入数据库，只有被读取的数据才能够进入缓存。Write-around 能够与 read-through 结合运用，并在数据只写一次、读取次数较少或者从不读取的情况下展现出良好的性能。同样，这个模式也能够与 cache-aside 组合使用。

四、WriteBack策略

        Write-back方法与write-through非常相似，只是数据库写调用是异步的。在这种策略下，应用程序将数据写入缓存，缓存会立即确认，并在延迟一段时间后将数据写入数据库。有时这种策略也被称为 write-behind。

优缺点

        Write-back缓存提高了写性能，对于写工作量大的工作负载非常有用。当与read-through相结合的时候，它对于混合工作负载非常有效，最近更新和访问的数据总是在缓存中可用。它对数据库故障具有很大程度上的弹性，可以容忍一些数据库的宕机。如果支持批处理或合并，则可以减少对数据库的总体写操作，这将减少负载并降低成本。

主要缺点是，如果缓存失效，数据可能会永久丢失。大多数关系数据库存储引擎(例如InnoDB)的内部都默认启用了回写缓存。查询首先写入内存，最后刷新到磁盘。

总结

        在本文当中，我们探讨了不同的缓存策略以及它们各自的优缺点。在实际应用中，请仔细评估您的目标，理解数据访问（读/写）模式，并选择最为适宜的策略或者组合策略。

        例如，如果在实际应当使用 write-around/read-through 时选择了 write-through/read-through（访问写入数据的频率较低），那么缓存中将会存在无用的垃圾。可以说，如果缓存足够大，或许没有问题。但在众多实际的高吞吐量系统中，当内存永远不够大并且需要考虑服务器成本时，正确的策略至关重要。