服务器缓存策略的不同类型是什么？

如果有人拥有网站，速度很重要！这意味着如果加载缓慢，它会排斥潜在消费者，并降低转化率。这对企业来说确实是一件大事，因为即使这种情况持续一段时间，它也无法发展。大量流量可能会导致服务器宕机，如果业务已经建立，这可能会花费数千（或数百万）美元。如果以正确的方式完成，服务器缓存有助于处理这一切。它极大地系统化了整个事情。

了解不同类型的服务器缓存策略很重要，以便了解如何选择正确的缓存策略。这是因为每个站点都不同，因此应该准备好为每个请求加载的人提供服务。但是，如果请求数量太大而无法处理怎么办？突然的流量高峰怎么办？它是否应该在特定时间限制后阻止进一步的客户端请求？这甚至可行吗？或者它应该学会在任何给定的时间点以某种方式为每个人服务？后者听起来很有竞争力，不是吗？必须熟悉不同类型的服务器缓存策略，才能选择合适的缓存策略。以下是最常见的：

5 种不同类型的服务器缓存策略

1. 缓存旁白：在这种缓存策略中，缓存在逻辑上放在一边，应用程序直接与缓存和数据库通信，以了解请求的信息是否存在。缓存首先由应用程序检查。如果找到该信息，则将其标记为缓存命中，然后读取并返回给客户端。如果信息不存在，则将其标记为缓存未命中。应用程序查询数据库以读取数据，将读取的数据返回给客户端，然后将其存储在缓存中以备将来缓存命中。

它最适合读取繁重的工作负载。如果缓存服务器宕机，系统仍然通过直接与数据库通信来工作；尽管在峰值负载有时突然出现的情况下，这从来都不是一个长期的解决方案。该缓存服务器需要将尽快修复。缓存和数据库中的数据模型可以不同。

最常见的写入策略是直接写入数据库。这就带来了数据的不一致，为了解决这个问题，开发者一般会使用TTL（time to live），继续服务，直到过期。它还可以与下一段中描述的其他服务器缓存策略协作。

2. 直写缓存：在这种方法中，信息在主存/数据库之前先写入缓存。缓存在逻辑上位于应用程序和数据库之间，客户端通过它进行交互。因此，如果客户端请求任何内容，应用程序不必检查缓存是否可用，因为它已经在那里了。它直接从缓存中检索并为客户端提供服务。

不利的一面是，它增加了写入延迟；但是如果与通读缓存配对（接下来编写的另一种策略），我们可以获得数据一致性的保证。

3. 通读缓存：在这种方法中，缓存位于数据库内。每当出现缓存未命中（意味着请求的数据不在缓存中）时，缺失的数据将从数据库中填充并返回给应用程序，以便为客户端提供服务。

当多次请求同一组信息时，它最适合读取繁重的工作负载。例如，需要许多人在不同设备上反复加载的新闻故事。

它的主要缺点是，如果第一次请求数据，它总是缓存未命中， 从而比正常加载速度太慢。开发人员通过手动发出查询或通过直写缓存来处理它。

4. 回写：在这种服务器缓存策略中，应用程序将信息写入缓存，立即确认更改，并在一段时间后将数据写回数据库。我们也可以称之为write-behind。

对于写入繁重的工作负载来说，这是一个很好的策略，可以提高写入性能。它可以容忍适度的数据库停机时间和不时发生的故障。它适用于read-through cache。如果支持批处理，则可以减少对数据库的整体写入，从而降低负载和成本。

在大多数关系数据库存储引擎中，例如 InnoDB，默认启用回写缓存，其中查询首先写入内存，然后刷新到主磁盘。主要缺点是，如果出现缓存故障，数据可能会永久丢失。

5. 写字：在这种情况下，数据直接写入数据库，只有该数据存储到读取的缓存中。

它可以与read-through cache结合使用。在数据被写入一次并且可以忽略或从不读取的情况下，这是一个不错的选择。例如，当需要实时日志或聊天室消息时。它也可以与cache-aside混合使用。

上述类型的服务器缓存策略中的任何一种都没有必要在实际使用中使用，但也可以结合使用两种或多种以获得最佳效果。如果有人刚开始处理这个问题，他们需要反复试验才能提出最佳解决方案。以前使用的策略以后可能会过时。这就是为什么不能说一种特定的方法总是对每个人都有效的原因。