5种常用缓存策略 5 Common Caching Patterns

date

Oct 25, 2023

slug

5-Common-Caching-Patterns

status

Published

缓存端模式（延迟加载） Cache Aside Pattern (Lazy Loading)

缓存端模式（也称为延迟加载）遵循一个简单的工作流程：

The Cache Aside Pattern, also known as lazy loading, follows a straightforward workflow:

从缓存中读取数据。

如果在缓存中找不到数据（缓存未命中），请从数据库中检索它。

将获取的数据写入缓存。

将数据返回到应用程序。

此模式的一个显着特征是缓存不直接与数据库交互;应用程序会处理这一点。优点包括易于实施和更精细地控制缓存的数据，只关注经常访问的信息。但是，由于多次跳闸，它可能会遭受延迟降级，并可能引入潜在的数据不一致。

另一个优点在于缓存中的数据模型可以与数据库中的数据模型不同。例如，多个查询产生的响应可以存储在某个请求id上。

当使用cache-aside时，最常见的写策略是直接将数据写到数据库中。当这种情况发生时，缓存可能与数据库不一致。为了解决这个问题，开发人员通常会引入TTL，并继续提供陈旧的数据，直到TTL过期。如果必须保证数据的新鲜度，开发人员要么使缓存条目无效，要么使用适当的写策略

使用场景：

通用缓存

读取密集型工作负载。

Write Through策略

Write Through策略 采用不同的方法：

将数据写入缓存，然后写入数据库。缓存与数据库保持一致，写操作总是通过缓存到达主数据库。

就其本身而言，write-through缓存似乎没有多大作用，实际上，它们引入了额外的写延迟，因为数据先写到缓存，然后写到主数据库。但是，当与read-through结合使用时，我们获得了read-through的所有好处，还获得了数据一致性保证，使我们不必使用缓存失效技术。

DynamoDB Accelerator (DAX)是write-through / read-through cache的一个很好的例子。它与DynamoDB和应用程序内联。对DynamoDB的读写可以通过DAX完成。(附注：如果您计划使用DAX，请确保熟悉它的数据一致性模型以及它如何与DynamoDB交互。)

此模式提供低读取延迟，因为缓存始终包含最新数据。但是，它可能会引入高写入延迟，并可能导致许多缓存数据永远不会被读取。

使用场景：

预期写入次数较少的情况。

数据新鲜度至关重要的地方

Read Through 策略

与缓存端模式有相似之处，但有一个关键的区别：

从缓存中读取数据。

将检索到的数据写入缓存。

返回数据。

与“Cache Aside”一样，应用程序处理数据库交互，而不是缓存。优点包括频繁访问的数据的低读取延迟和改进的读取可扩展性。但是，潜在的数据不一致和缓存未命中时的高延迟是缺点。

当多次请求相同的数据时，read-through缓存最适合于读量较大的工作负载。例如，一个新闻故事。缺点是，当第一次请求数据时，它总是导致缓存丢失，并导致额外的数据加载到缓存的代价。

开发人员通过手动发出查询来“预热”或“预热”缓存来处理这个问题。就像cache-aside一样，数据也可能在缓存和数据库之间变得不一致

适用场景：

Read-heavy workloads.

读取密集型工作负载。

Acceptable high cache miss rates.

可接受的高缓存未命中率。

Write-Back or Write-Behind 策略

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

一些开发人员使用Redis时，同时采用了cache-aside和write-back两种策略，以便更好地吸收峰值负载期间的峰值。主要缺点是，如果缓存失效，数据可能会永久丢失。大多数关系数据库存储引擎(例如InnoDB)的内部都默认启用了回写缓存。查询首先写入内存，最后刷新到磁盘。

适用场景：

写入繁重的工作负载

当数据持久性不是重中之重时

Write-Around策略

这种策略下，数据直接写入数据库，只有读取的数据才能进入缓存。Write-around可以与read-through结合使用，并在数据只写一次、读取次数较少或从不读的情况下提供良好的性能。例如，实时日志或聊天室消息。同样，这个模式也可以与cache-aside组合使用。

它的独特之处在于它遵循以下工作流：

Write data directly to the database. 将数据直接写入数据库。

Read data from the cache 从缓存中读取数据。

On a cache miss, retrieve the data from the database and write it to the cache 在缓存未命中时，从数据库中检索数据并将其写入缓存。

This approach reduces the risk of data loss and prevents cache pollution with infrequently accessed data. However, it can introduce high read latency and lead to a high cache miss rate. 此方法可降低数据丢失的风险，并防止不常访问的数据造成缓存污染。但是，它可能会引入高读取延迟并导致高缓存未命中率。

使用场景：

预计没有数据更新的方案

预期读取次数较少的情况。

Summary 总结

In this post, we explored different caching strategies and their pros and cons. In practice, carefully evaluate your goals, understand data access (read/write) patterns and choose the best strategy or a combination.

在这篇文章中，我们探讨了不同的缓存策略及其优缺点。在实践中，请仔细评估您的目标，了解数据访问（读/写）模式并选择最佳策略或组合。

What happens if you choose wrong? One that doesn’t match your goals or access patterns? You may introduce additional latency, or at the very least, not see the full benefits. For example, if you choose write-through/read-through when you actually should be using write-around/read-through (written data is accessed less frequently), you’ll have useless junk in your cache. Arguably, if the cache is big enough, it may be fine. But in many real-world, high-throughput systems, when memory is never big enough and server costs are a concern, the right strategy, matters.

如果你选择错了怎么办？与您的目标或访问模式不匹配？您可能会引入额外的延迟，或者至少看不到全部好处。例如，如果您在实际应该使用绕写/通读（访问写入数据的频率较低）时选择直写/通读，则缓存中将有无用的垃圾。可以说，如果缓存足够大，它可能没问题。但是在许多现实世界的高吞吐量系统中，当内存永远不够大并且服务器成本是一个问题时，正确的策略很重要。

文章引用和参考了以下网址和原文：

https://www.linkedin.com/pulse/caching-patterns-guide-efficient-data-storage-siddharth-padhi

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/