我試圖設計一個分佈式的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副本集通過強制任何未連接到大多數節點的節點放棄其主節點狀態來折衷可用性。確保您瞭解數據庫在不利條件下的性能，並確保它們符合您的應用程序的要求。