我试图设计一个分布式的JBoss应用程序，今天下午我听到一些同事在谈论CAP定理，特别是它的“P”（分区）部分。他们正在讨论它如何应用于各种分区类型，即集群分区，网络分区和虚拟分区。网络，集群和虚拟分区
我的了解是一个网络分区的一个有意设计，将网络分割成2+个孤立的部分，以便它可以处理一个或多个单独片段的中断。集群分区如何适合这个模型（并因此与CAP关联）以及什么是“虚拟”分区？
我想知道在集成我的JBoss应用程序时是否需要考虑这些因素，如果是这样，从哪里开始考虑。提前致谢！
根据CAP定理，你不能在同一时刻实现所有三个C onsistency，A vailability和P artition宽容的。
我的解释是，这并不意味着你的应用必然失去A永远如果你选择C+P。应用程序可以设计为在任何时刻都有任何一对CAP。而且你必须决定你想要哪一对CAP。
在JBoss集群环境中，您可以在升级/维护工作期间设置独立的备用分区来替换主分区。这样你主要有C+A没有P因为你在主要时间没有使用这两个分区。现在您决定是时候升级您的应用了，您有哪些选择？您可以暂时更改C或A的P。也就是说，您可以交换分区（丢失C）或者将整个集群关闭（丢失A）。
当然，您可以选择主要时间为CAP的其他组合。这取决于您的应用可以使用哪种SLA。更流行的是C+A和A+P。
CAP定理中的分区容差是一个理论概念，而不是一个具体的概念。它指的是整个系统处理通信故障的能力。它并不是指任何故意的节点分离。
CAP theorem itself says, from a web service perspective：
在网络受到通信故障，这是不可能的任何web服务实现的原子读/写共享存储器，保证对每个请求的响应。
请注意，对于由数据库支持的Web服务，您实际上不需要担心CAP定理，因为您并未试图实现任何共享内存;数据库为你做。如果您在应用程序中维持任何活动状态，则您需要担心CAP定理，因为该状态表示您想要自动维护（c持续）的某些读/写内存，可靠地（a可变），以及面对面的节点之间的网络故障（p准许宽容）。
如果您在多个节点上拥有数据库支持，数据库本身必须处理CAP定理。部署的任何HA解决方案都会进行不同的折衷以处理通信故障。例如，MongoDB副本集通过强制任何未连接到大多数节点的节点放弃其主节点状态来折衷可用性。确保您了解数据库在不利条件下的性能，并确保它们符合您的应用程序的要求。