1

我正在尝试设计一个分布式 JBoss 应用程序，今天下午我无意中听到一些同事谈论 CAP 定理，特别是其中的“P”（分区）部分。他们正在讨论它如何应用于各种分区类型，即集群分区、网络分区和虚拟分区。

我对网络分区的理解是，它有意将网络分成 2 个以上的独立部分，以便它可以处理一个或多个单独片段的中断。集群分区如何适应这个模型（并因此与 CAP 相关联），什么是“虚拟”分区？！？

我想知道在集群我的 JBoss 应用程序时是否需要考虑这些因素，如果需要，从哪里开始考虑这些因素。提前致谢！

4

2 回答 2

1

根据定理，你CAP不能同时实现持久性C、A可用性和P艺术容忍性这三者。

我的解释是，这并不意味着A如果您选择C+P. 一个应用程序可以设计为CAP在不同的时刻拥有任意一对。你必须决定CAP你最想拥有哪一对。

在 JBoss 集群的上下文中，您可以在升级/维护工作期间设置一个隔离的备用辅助分区来交换它，而不是您的主分区。这种方式你大多C+A没有，P因为你在主要时间没有使用两个分区。现在您决定是时候升级您的应用程序了，您有哪些选择？您可以临时更改C或A。P也就是说，您可以交换分区（丢失C）或关闭整个集群（丢失A）。

当然，你可以选择其他的CAP主时间组合。这取决于什么 SLA 适合您的应用程序。更受欢迎的是C+A和A+P。

于 2013-03-09T18:15:51.827 回答
0

CAP 定理中的分区容差是一个理论概念，而不是具体概念。它是指整个系统处理通信故障的能力。它不是指任何故意的节点分离。

从 Web 服务的角度来看，CAP 定理本身说：

在遭受通信故障的网络中，任何 Web 服务都不可能实现原子读/写共享内存来保证对每个请求的响应。

请注意，对于由数据库支持的 Web 服务，您实际上不需要担心 CAP 定理，因为您没有尝试实现任何共享内存；数据库为您完成。如果您在应用程序中维护任何实时状态，则确实需要担心 CAP 定理，因为该状态表示您希望以原子方式（c持续地）、可靠地（a有效地）维护一些读/写内存，并且面对之间的网络故障节点（p分区容忍）。

如果您由多个节点上的数据库支持，则数据库本身必须处理 CAP 定理。部署的任何 HA 解决方案都会做出不同的权衡以处理通信故障。例如，MongoDB 副本通过强制任何未连接到大多数节点的节点放弃其主节点状态来权衡可用性。确保您了解数据库在不利条件下的作用，并确保它们与您的应用程序的要求相匹配。

于 2013-03-11T23:34:38.193 回答