分佈式系統（distributed system）正變得越來越重要，大型網站幾乎都是分佈式的。
分佈式系統的最大難點，就是各個節點的狀態如何同步。CAP 定理是這方面的基本定理，也是理解分佈式系統的起點。
>CAP定理
1998年，加州大學的計算機科學家 Eric Brewer 提出，分佈式系統有三個指標。
- Consistency
- Availability
- Partition tolerance
它們的第一個字母分別是 C、A、P。
Eric Brewer 說，這三個指標不可能同時做到。這個結論就叫做 CAP 定理。
>Partition tolerance
大多數分佈式系統都分佈在多個子網絡。每個子網絡就叫做一個區（partition）。分區容錯的意思是，區間通信可能失敗。比如，一臺服務器放在中國，另一臺服務器放在美國，這就是兩個區，它們之間可能無法通信。
分區容錯對於分佈式系統來說幾乎是不可避免地，因此可以認爲 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到。
>Consistency
問題是，用戶有可能向 G2 發起讀操作，由於 G2 的值沒有發生變化，因此返回的是 v0。G1 和 G2 讀操作的結果不一致，這就不滿足一致性了。
爲了讓 G2 也能變爲 v1，就要在 G1 寫操作的時候，讓 G1 向 G2 發送一條消息，要求 G2 也改成 v1。
這樣的話，用戶向 G2 發起讀操作，也能得到 v1。
>Availability
Availability 中文叫做"可用性"，意思是隻要收到用戶的請求，服務器就必須給出迴應。
用戶可以選擇向 G1 或 G2 發起讀操作。不管是哪臺服務器，只要收到請求，就必須告訴用戶，到底是 v0 還是 v1，否則就不滿足可用性。
>C&A爲什麼不能同時成立：
一致性和可用性，爲什麼不可能同時成立？答案很簡單，因爲可能通信失敗（即出現分區容錯）。
如果保證 G2 的一致性，那麼 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。只有數據同步後，才能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可用性不。
如果保證 G2 的可用性，那麼勢必不能鎖定 G2，所以一致性不成立。
綜上所述，G2 無法同時做到一致性和可用性。系統設計時只能選擇一個目標。如果追求一致性，那麼無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一致性。
>BASE：基本可用（BA)、軟狀態（S）、最終一致性（E）
1.基本可用（Basically Available）:
NoSQL允許分佈式系統中某些部分出現故障，那麼系統的其餘部分依然可用。它不會像ACID那樣，在系統出現故障時，進行強制拒絕，允許繼續部分訪問。
2.軟狀態（Soft State）:
NoSQL在數據處理過程中，允許這個過程，存在數據狀態暫時不一致的情況。但經過糾錯處理，最終會一致的。
3.最終一致性（Eventually Consistent）：
NoSQL的軟狀態允許數據處理過程的暫時不一致，但是最終處理結果將是一致的，說明NoSQL對數據處理過程可以有短暫的時間間隔，也允許分更細的步驟一個一個地處理，最好數據達到一致即可。這在互聯網上進行分佈式應用具有其明顯的優勢。