关于数据库缓存的说明
Clarification on database caching
如果我错了请纠正我，但根据我的理解，"database caches" 通常使用 Web 服务器本地的内存数据库实现（与 Web 服务器在同一台机器上）。此外，这些 "database caches" 存储查询的实际结果。我还阅读了多种缓存策略，例如 - Cache Aside、Read Through、Write Through、Write Behind、Write Around。
在某些情况下，直写策略如下所示：
Cache Aside 策略如下所示：
我认为 "Application" 指的是具有 REST API 的后端服务器。
我的第一个问题是，在Write Through策略中（应用程序写入缓存，缓存然后写入数据库），这是如何工作的？据我了解，最常用的数据库缓存是 Redis 或 Memcached——它们只是键值存储。假设你有一个关系数据库作为主数据库，这些键值存储将如何写回关系数据库？这些策略是否仅在您的主数据库也是键值存储时才适用？
在直写（或直读）策略中，缓存位于应用程序和数据库之间。那是如何工作的？你如何让缓存与数据库服务器对话？根据我的理解，Web 服务器（应用程序）始终是促进缓存与主数据库之间通信的服务器——这基本上是一种缓存备用策略。除非 Redis 有某种允许它与另一个数据库对话的功能，否则我不太明白它是如何工作的。
是否可以混合搭配缓存策略？在我看来，Cache Aside 和 Read Through 是针对应用程序读取（用户想要读取数据）的缓存策略，而 Write Through 和 Write Behind 是针对应用程序写入（用户想要写入数据）的缓存策略。你不能有一个同时使用 Cache Aside 和 Write Through 的策略吗？为什么大多数文章似乎总是把它们描绘成独立的策略？
如果你有一个网络服务器集群会怎样？他们每个人都有自己的本地内存数据库作为缓存吗？
您可以使用普通（非内存）数据库实现缓存吗？我想这仍然有点用处，因为您不需要对数据库服务器进行额外的网络跳转（因为缓存与 Web 服务器位于同一台机器上）？
介绍与说明
我猜你有一个误解，缓存并没有明确地存储在与网络服务器相同的服务器上。有时，甚至连数据库都没有从网络服务器分离到它自己的服务器上。如果你想到 APIs，比如 HTTP REST APIs，你可以使用缓存来避免在数据库连接和查询上花费太多资源。通常，您希望使用尽可能少的数据库连接和查询。现在想象以下设置：
您有一个为您的应用程序提供服务的网络服务器和一个 REST API，网络服务器使用它来处理某些资源。这些资源来自数据库（可以说是关系数据库），该数据库也存储在同一台服务器上。现在有一个端点服务于例如posts 的列表（如博客文章）。每个用户都可以获取所有帖子（在这个例子中为了简单起见）。现在我们有一种情况可以说这个 API 请求可以被缓存，而不是让所有用户总是触发数据库，只是为了一遍又一遍地查询相同的资源（通过 REST API）再次。 缓存来了。 Redis 是众多可用于缓存的工具之一。由于 Redis 是一个简单的内存中键值存储，您可以在第一次数据库查询后将所有帖子（记住 REST API）放入缓存中。所有对帖子列表的未来请求将首先检查帖子是否已经缓存。如果是，API 将 return 此特定请求的缓存内容。
这是一个简单的例子，用来展示缓存可以用来做什么。
您问题的答案
My first question is, why would you ever write to a cache?
减少数据库连接和查询的数量。
how is writing to these key-value stores going to help with updating the relational database?
它不会帮助您更新，而是帮助您减少资源消耗。它还可以在 "temporary backing up" 一些数据方面为您提供帮助 - 但这只是一个非常小的副作用。为此，有更多有吸引力的解决方案（因为默认情况下 redis 也不是持久的。But it supports persistence.）
Do these cache writing strategies only apply if your main database is also a key-value store?
不，使用哪个数据库并不重要。无论是 NoSQL 还是 SQL 数据库。这在很大程度上取决于您要缓存的内容以及数据库及其表的设置方式。您的资源是否经常更改？资源是手动更新还是仅在用户启动操作时更新？这些问题会引导您找到正确的缓存实现。
Isn't it possible to mix and match caching strategies?
我不是缓存策略方面的专家，但让我试试：
我想这是可能的，但它也很大程度上取决于您在数据库中所做的事情以及您拥有的应用程序类型。我想如果你发现你正在构建什么类型的应用程序，那么你就会知道，你必须使用什么策略 - 我想也不建议将这些策略混合起来，因为这些策略与您的应用程序类型相关 - 换句话说：它不会很好地工作。
What happens if you have a cluster of webs servers? Do they each have their own local in-memory database that acts as a cache?
我想两者都有可能。通常你有一个数据库，可能是集群的或与副本同步的，你的网络服务器（例如 REST APIs）向它发出请求。那么你们每个 API 服务器是否都有自己的缓存，根本不查询数据库（在基于云的应用程序中，您的数据库也可能在另一个单独的服务器上 - 所以另一个 "hop"联网）。或者（我也可以想象）你在你的 APIs（集群）和你的数据库（可能也集群）之间有另一个中间件 - 但我想由于网络流量，没有人会这样做。这会导致更长的响应时间，这是您通常希望避免的。
Could you implement a cache using a normal (not in-memory) database?
是的，你可以，但它会慢得多。一台机器可以更快地访问内存中的数据，然后建立另一个（本地）数据库连接并查询您的缓存条目。此外，因为您的数据库必须将条目写入您计算机上的文件中，才能持久保存数据。
结论
总而言之，这一切都是为了加快响应时间并防止大量网络流量。希望能帮到你一点点。
如果我错了请纠正我，但根据我的理解，"database caches" 通常使用 Web 服务器本地的内存数据库实现（与 Web 服务器在同一台机器上）。此外，这些 "database caches" 存储查询的实际结果。我还阅读了多种缓存策略，例如 - Cache Aside、Read Through、Write Through、Write Behind、Write Around。
在某些情况下，直写策略如下所示：
我认为 "Application" 指的是具有 REST API 的后端服务器。
我的第一个问题是，在Write Through策略中（应用程序写入缓存，缓存然后写入数据库），这是如何工作的？据我了解，最常用的数据库缓存是 Redis 或 Memcached——它们只是键值存储。假设你有一个关系数据库作为主数据库，这些键值存储将如何写回关系数据库？这些策略是否仅在您的主数据库也是键值存储时才适用？
在直写（或直读）策略中，缓存位于应用程序和数据库之间。那是如何工作的？你如何让缓存与数据库服务器对话？根据我的理解，Web 服务器（应用程序）始终是促进缓存与主数据库之间通信的服务器——这基本上是一种缓存备用策略。除非 Redis 有某种允许它与另一个数据库对话的功能，否则我不太明白它是如何工作的。
是否可以混合搭配缓存策略？在我看来，Cache Aside 和 Read Through 是针对应用程序读取（用户想要读取数据）的缓存策略，而 Write Through 和 Write Behind 是针对应用程序写入（用户想要写入数据）的缓存策略。你不能有一个同时使用 Cache Aside 和 Write Through 的策略吗？为什么大多数文章似乎总是把它们描绘成独立的策略？
如果你有一个网络服务器集群会怎样？他们每个人都有自己的本地内存数据库作为缓存吗？
您可以使用普通（非内存）数据库实现缓存吗？我想这仍然有点用处，因为您不需要对数据库服务器进行额外的网络跳转（因为缓存与 Web 服务器位于同一台机器上）？
介绍与说明
我猜你有一个误解，缓存并没有明确地存储在与网络服务器相同的服务器上。有时，甚至连数据库都没有从网络服务器分离到它自己的服务器上。如果你想到 APIs，比如 HTTP REST APIs，你可以使用缓存来避免在数据库连接和查询上花费太多资源。通常，您希望使用尽可能少的数据库连接和查询。现在想象以下设置：
您有一个为您的应用程序提供服务的网络服务器和一个 REST API，网络服务器使用它来处理某些资源。这些资源来自数据库（可以说是关系数据库），该数据库也存储在同一台服务器上。现在有一个端点服务于例如posts 的列表（如博客文章）。每个用户都可以获取所有帖子（在这个例子中为了简单起见）。现在我们有一种情况可以说这个 API 请求可以被缓存，而不是让所有用户总是触发数据库，只是为了一遍又一遍地查询相同的资源（通过 REST API）再次。 缓存来了。 Redis 是众多可用于缓存的工具之一。由于 Redis 是一个简单的内存中键值存储，您可以在第一次数据库查询后将所有帖子（记住 REST API）放入缓存中。所有对帖子列表的未来请求将首先检查帖子是否已经缓存。如果是，API 将 return 此特定请求的缓存内容。
这是一个简单的例子，用来展示缓存可以用来做什么。
您问题的答案
My first question is, why would you ever write to a cache?
减少数据库连接和查询的数量。
how is writing to these key-value stores going to help with updating the relational database?
它不会帮助您更新，而是帮助您减少资源消耗。它还可以在 "temporary backing up" 一些数据方面为您提供帮助 - 但这只是一个非常小的副作用。为此，有更多有吸引力的解决方案（因为默认情况下 redis 也不是持久的。But it supports persistence.）
Do these cache writing strategies only apply if your main database is also a key-value store?
不，使用哪个数据库并不重要。无论是 NoSQL 还是 SQL 数据库。这在很大程度上取决于您要缓存的内容以及数据库及其表的设置方式。您的资源是否经常更改？资源是手动更新还是仅在用户启动操作时更新？这些问题会引导您找到正确的缓存实现。
Isn't it possible to mix and match caching strategies?
我不是缓存策略方面的专家，但让我试试： 我想这是可能的，但它也很大程度上取决于您在数据库中所做的事情以及您拥有的应用程序类型。我想如果你发现你正在构建什么类型的应用程序，那么你就会知道，你必须使用什么策略 - 我想也不建议将这些策略混合起来，因为这些策略与您的应用程序类型相关 - 换句话说：它不会很好地工作。
What happens if you have a cluster of webs servers? Do they each have their own local in-memory database that acts as a cache?
我想两者都有可能。通常你有一个数据库，可能是集群的或与副本同步的，你的网络服务器（例如 REST APIs）向它发出请求。那么你们每个 API 服务器是否都有自己的缓存，根本不查询数据库（在基于云的应用程序中，您的数据库也可能在另一个单独的服务器上 - 所以另一个 "hop"联网）。或者（我也可以想象）你在你的 APIs（集群）和你的数据库（可能也集群）之间有另一个中间件 - 但我想由于网络流量，没有人会这样做。这会导致更长的响应时间，这是您通常希望避免的。
Could you implement a cache using a normal (not in-memory) database?
是的，你可以，但它会慢得多。一台机器可以更快地访问内存中的数据，然后建立另一个（本地）数据库连接并查询您的缓存条目。此外，因为您的数据库必须将条目写入您计算机上的文件中，才能持久保存数据。
结论
总而言之，这一切都是为了加快响应时间并防止大量网络流量。希望能帮到你一点点。