因爲微服務的原因，我們把服務進行了分佈式，隨着各個數據庫也隨着變成分佈式每個數據庫不一定存在相同的物理機中。
那麼這個時候單個數據庫的 ACID 已經不能適應這種情況，而在這種集羣中想去保證集羣的 ACID 幾乎很難達到，或者即使能達到那麼效率和性能會大幅下降，最爲關鍵的是再很難擴展新的分區了。
這個時候如果再追求集羣的 ACID 會導致我們的系統變得很差，這時我們就需要引入一個新的理論原則來適應這種集羣的情況，就是 CAP。
CAP定理
CAP 必須滿足以下的 3 個屬性：
- 一致性（Consistency）：在分佈式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
- 可用性（Availability）：在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
- 分區容錯性（Partition tolerance）：大多數分佈式系統都分佈在多個子網絡。每個子網絡就叫做一個區（partition）。分區容錯的意思是，區間通信可能失敗。比如，一臺服務器放在中國，另一臺服務器放在美國，這就是兩個區，它們之間可能無法通信。即G1 和 G2 是兩臺跨區的服務器。G1 向 G2 發送一條消息，G2 可能無法收到。系統設計的時候，必須考慮到這種情況。
一般來說，分區容錯無法避免，因此可以認爲 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到。
Consistency 和 Availability 的矛盾
一致性和可用性，爲什麼不可能同時成立？答案很簡單，因爲可能通信失敗（即出現分區容錯）。
如果保證 G2 的一致性，那麼 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。只有數據同步後，才能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可用性不。
如果保證 G2 的可用性，那麼勢必不能鎖定 G2，所以一致性不成立。
綜上所述，G2 無法同時做到一致性和可用性。系統設計時只能選擇一個目標。如果追求一致性，那麼無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一致性。