今天我正在思考这个问题。 Web 应用程序中数据库上下文中的 LRU 缓存有助于确保快速数据查找的可用性，而无需持续访问数据库。
但是，LRU 缓存在实践中如何保持新鲜？据我了解，一个人不能保证一致性和A可用性。经常使用的项(因此不会从 LRU 缓存中过期)如何处理修改？这是一个在需要 C 而不是 A 的系统中的示例，LRU 缓存不是一个好的选择吗？
最佳答案
首先，缓存太小而无法容纳所有数据(可能会发生驱逐并且 LRU 部分相关)并不是 CAP 定理的好例子，因为即使不考虑一致性，它也不能甚至同时提供分区容错性和可用性。如果客户端请求的数据不在缓存中，而网络分区又导致缓存无法及时从主库获取数据，那么它根本无法及时给客户端任何答复。
如果我们只讨论缓存中实际存在的数据，我们可能会有点尴尬地将 CAP 定理仅应用于该数据。那么这取决于缓存的具体使用方式。
大量缓存发生在也拥有权威数据的同一台机器上。例如，您的数据库管理系统(例如 PostgreSql 或其他)可能会在 RAM 中缓存大量数据，并从那里而不是从磁盘上的持久数据回答查询。即便如此cache invalidation是一个棘手的问题。基本上，即使没有网络，您也可以偶尔使用过时的信息(基本上牺牲一致性)，或者缓存系统需要了解数据更改并采取行动，这可能会变得非常复杂。尽管如此，CAP 定理根本不适用，因为不存在分布。或者，如果您想非常迂腐地看待它(不是通常的表达方式)，一台计算机的各个部分用于通信的总线不是p分区容忍的(CAP 定理的第三条腿) )。更简单地说:如果计算机的各个部分无法相互通信，计算机就会崩溃。
因此，从 CAP 角度来看，有趣的情况是主数据库和缓存位于通过不可靠网络连接的不同计算机上。在这种情况下，有两种基本的可能性:(1) 缓存服务器可能会在不询问主数据库其数据是否仍然有效的情况下回答请求，或者 (2) 它可能会在每个请求时与主数据库进行检查。 (1) 意味着牺牲一致性。如果是(2)，那么缓存的设计必须处理一个问题:如果缓存没有按时得到主数据库的答复(由于分区，这是一些网络问题)，缓存应该告诉客户端什么？在这种情况下，基本上只有两种可能性:它可能仍然使用缓存的数据进行响应，冒着它可能变得无效的风险。这会牺牲一致性。或者它可能会告诉客户现在无法答复。这会牺牲可用性。
总结一下
- 如果一切都发生在一台机器上，则 CAP 定理不适用
- 如果数据和缓存通过不可靠的网络连接，那么这不是 CAP 定理的一个很好的例子，因为即使没有 C，你也得不到 A&P。
- 不过，CAP 定理意味着您必须牺牲 C 甚至更多的 A&P，而不是缓存首先无法提供的部分。
- 您最终要牺牲什么取决于缓存的具体使用方式。
关于caching - LRU 缓存如何符合 CAP 定理？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54850769/