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