这些缓存策略要求我们根据特定的业务场景选择更合适的。
缓存模式是一种缓存读取和写作模式，通常使用更多，它更适合阅读请求。CACHEBEAFER DATECT的服务器需要同时维护DB和缓存，并且基于DB的结果。
让我们看一下此策略模式下的缓存阅读步骤。
只需画一张图片即可帮助每个人理解写作步骤。
只需画一张图片即可帮助每个人理解步骤。
您只是了解上述内容还不够，我们必须了解原则。
例如，访调员可能会问：“在编写数据的过程中，您可以先删除缓存，然后更新DB？”
答：这不行！因为这可能会导致数据库（db）和缓存（缓存）数据的不一致。该过程可以简要描述为：
请求1删除缓存中的数据 - >请求2从db-> request 1读取数据，然后在db中更新a数据。
当您以这种方式回答时，面试官可能会跟进并问：“在编写数据的过程中，首先更新数据库，然后删除缓存，没有问题吗？”
答案：从理论上讲，可能仍然存在数据不一致，但是概率很小，因为缓存写作速度比数据库编写速度快得多！
例如，请求1读取数据，请求2以后再写数据，如果不在缓存中，则数据A也可能导致数据不一致。该过程可以简要地描述为：
请求1读取数据a->请求2以将更新数据a写入数据库，并将删除缓存1中的A数据删除到缓存中。
现在，让我们分析缓存模式的缺陷。
死亡1：第一个请求数据不得在缓存中
解决方案：您可以提前将热数据放入缓存。
缺陷2：如果写作操作更频繁，则缓存中的数据将经常删除，这将影响缓存命中率。
解决方案：
通过模式的服务器读取/写入/写入缓存是主要数据存储，从其中读取数据并将数据写入其中。高速缓存服务负责读取和写入此数据中的数据库，从而减少了应用程序的职责。
这个缓存阅读策略合作伙伴还应该发现，在开发过程中它非常罕见。投掷性能的影响是因为我们经常使用的分布式缓存REDIS并不能提供将数据写入DB的功能。
只需画一张图片即可帮助每个人理解写作步骤。
只需画一张图片即可帮助每个人理解步骤。
在缓存模式上实际上封装了读取模式。在缓存模式下，读取请求时，如果缓存中没有相应的数据，则客户端负责将数据写入缓存，并仔细阅读模式由缓存编写以编写缓存本身。这对客户是透明的。
就像缓存模式一样，读取模式也存在一个问题，即第一个请求数据必须不再是缓存。对于热数据，您可以提前将其放入缓存中。
在模式后写入和通过模式读/写入非常相似。他们俩都负责缓存服务的缓存和DB的读写。
但是，两者非常不同：通过读/写入是缓存和数据库的同步更新，而在缓存后写入仅更新缓存，而不是直接更新DB，而是更新DB异步批次。
显然，这种方法给数据一致性带来了更大的挑战。例如，如果无法异步更新缓存数据，则缓存服务可能会挂起。
在我们通常的开发过程中，这种策略也非常非常罕见，但这并不意味着其应用方案很小。例如，消息队列中该消息的异步写入磁盘和MySQL的InnoDB缓冲池机制都使用此策略。
DB在图案背后写的DB的写作表现非常高。它非常适合某些数据经常更改并且数据一致性不那么高的场景，例如视图和喜欢。