2

我今天在思考这个问题。Web 应用程序中数据库上下文中的LRU 缓存有助于确保快速数据查找的可用性，而不依赖于持续访问数据库。

但是，LRU 缓存如何在实践中保持新鲜？据我了解，不能保证一致性和可用性。一个经常使用的项目，因此不会从 LRU 缓存中过期，如何处理修改？这是一个例子，在需要C over A的系统中，LRU 缓存不是一个好的选择吗？

4

1 回答 1

2

首先，缓存太小而无法保存所有数据（可能会发生驱逐并且 LRU 部分是相关的）不是 CAP 定理的一个好例子，因为即使不考虑一致性，它甚至无法传递分区同时容忍和可用性。如果客户端请求的数据不在缓存中，而网络分区阻止缓存及时从主库获取数据，那么它根本无法及时给客户端任何答复。

如果我们只讨论缓存中实际存在的数据，我们可能会有些尴尬地将 CAP 定理仅应用于该数据。然后它取决于该缓存的使用方式。

大量缓存发生在具有权威数据的同一台机器上。例如，您的数据库管理系统（比如 PostgreSql 或其他）可能会在 RAM 中缓存大量数据并从那里而不是从磁盘上的持久数据中回答查询。即使这样，缓存失效也是一个棘手的问题。基本上即使没有网络，您有时也可以使用过时的信息（基本上会牺牲一致性），或者缓存系统需要了解数据更改并对其采取行动，这可能会变得非常复杂。尽管如此，CAP 定理根本不适用，因为没有分布。或者，如果您想非常迂腐地看待它（不是通常的放置方式），一台计算机的各个部分用于通信的总线不是p分区容错（CAP 定理的第三条腿）。更简单地说：如果您的计算机的各个部分无法相互通信，计算机就会崩溃。

因此，从 CAP 角度来看，有趣的案例是将主数据库和缓存放在由不可靠网络连接的不同机器上。在这种情况下，有两种基本的可能性：（1）缓存服务器可能会在不询问主数据库的数据是否仍然有效的情况下响应请求，或者（2）它可能会在每次请求时检查主数据库。(1) 意味着牺牲了一致性。如果是（2），那么缓存的设计必须处理一个问题：如果缓存没有及时得到主数据库的响应（由于分区，这是一些网络问题），缓存应该告诉客户端什么？在这种情况下，基本上只有两种可能性：它可能仍然响应缓存的数据，冒着可能变得无效的风险。这是牺牲一致性。或者它可能会告诉客户它可以' 现在不回答。那就是牺牲可用性。

所以总而言之

  • 如果一切都发生在一台机器上，则 CAP 定理不适用
  • 如果数据和缓存是通过不可靠的网络连接的，那么这不是 CAP 定理的一个很好的例子，因为即使没有 C，你甚至不会得到 A&P。
  • 尽管如此，CAP 定理意味着您必须牺牲 C 甚至更多的 A&P，而不是缓存一开始就无法提供的部分。
  • 您最终牺牲的具体内容取决于缓存的使用方式。
于 2019-02-24T20:50:55.937 回答