Distributed computing CAP定理是一条红鲱鱼吗？

我被告知，我必须放弃大型分布式系统中的事务性保证，因为他们说我不能保证

我认为这是错误的，原因如下：

• 互联网路由是惊人的可靠
• CAP定理仅适用于两组活动机器无法通信的网络分区
• 几乎所有真实的网络分区都由灾难性故障或情况组成，其中一个分区非常小，另一个分区非常大，而小的分区可以关闭
• 机器故障本身并不构成网络分区

因此，我可以假设，出于实际目的，如果我试图保证小分区检测到它们断开连接并关闭，或者在连接修复之前以某种降级模式运行，那么我可以拥有事务行为

更正？评论？火焰

---

参考文献：

• 有关CAP定理的概述，请参阅Julian Browne的这篇文章
• 上的CAP定理

---

麻省理工学院实验室的Nancy Lynch等人已经证明了CAP定理
你的假设不好。是的，您可以在分布式系统中进行事务处理，但是您必须等待所有事务。这就是你受可用性影响的时候。因此，您可以具有一致性和部分容差，但不具有可用性
在另一种情况下，您可以有可用性和部分容差，但没有一致性，例如MongoDB或Cassandra（配置了最终一致性）。在这种情况下，您可以有多个DB服务器，但您的数据不会立即在所有服务器上都可用。您会受到一致性的影响，但您会从可用性和部分容忍中获益
最后一种情况是最简单的：您具有一致性和可用性，但没有部分容差。设想一个单一的数据库服务器
关于你的观点：
• 互联网路由是惊人的可靠
无缝可靠
• CAP定理仅适用于两组活动机器无法通信的网络分区
CAP定理适用于任何分布式系统
另外两点实在没有多大意义
还有其他一些教授声称CAP是不完整的，还有更多的，比如延迟。但CAP定理有着完美的意义
还有“基本”定理（基本可用、软状态和最终一致性）。许多NoSQL数据库都支持这个定理

---

请在和上查看我的博客。
我建议您阅读本文：
读了之后，我明白了两件事
首先，Brewer的猜想是关于任何web服务的，而不仅仅是关于分布式的web服务。然后，在这种情况下，可以从三个属性中选择两个。例如，让我们忽略分区容错。在我看来，在这种情况下，您有两种选择：
• 使用单机：如果没有网络，那么我就不担心分区容错，但是整个系统的可用性取决于单机必须在线这一事实
• 使用多台机器，但不使用复制：只需使用每台机器来处理/存储没有强大功能关系的数据。如果某些机器崩溃，其余数据可用且一致 也许，您可以认为还有第三种选择：使用多台机器和复制，而不关心分区容错。让我们假设一下！在这种情况下，如果某些机器或机器之间的连接崩溃，则无法保证一致性或可用性，因为系统将没有恢复其正确数据状态的进程。这里，请注意，添加复制意味着增加分区容忍度
  然后，第二件需要理解的事情是：
  在分布式系统中，我们使用多台机器来扩展计算和数据存储，分区容错是它们的本质属性。我们使用一组机器，就好像它们是一组机器一样，以增加处理和存储资源以及客户端的可用性，而不是CAP可用性。因此，提高客户端可用性的一种方法是支持分区容忍：分布式系统的本质属性

  ---

  总而言之，应用于分布式系统的CAP定理大多是这样说的：在分区容忍的情况下，不可能同时保证一致性和可用性。
  当然，如果忽略一些问题，您可以随意假设。对不起，请展开。忽略哪些问题？“…非常可靠”，除非不是这样（ISP偶尔会遇到路由问题，电缆不时会被撕裂）。“几乎所有…”你从哪里得到的？“机器故障不会…”如果机器是您的核心路由器之一，它会触发对等路由器过载或奇怪的跨越故障，并使数据中心脱机，该怎么办？这些事情发生在现实生活中。我从来没有说过CAP定理是错误的。我只是建议，当您必须围绕它重新构建大型实现时，它的应用是错误的。我重申，CAP定理只处理网络分区的情况，在实践中，这些情况要么是灾难性的，要么是非常轻微的。你不能忽略任何失败，即使是非常轻微或灾难性的。我不同意。你必须忽略某些类型的失败，否则你永远不会真正完成任何事情，因为总有一个失败你没有考虑过。这是哥德尔定理的结果；c）因为存在关于失败的事实，这些事实不能被证明并不意味着我们应该忽略那些已经被证明的事实。我不认为盖帽定理是一个定理。c