如何在系統設計中使用CAP定理？

什麼是CAP定理？在Consistency一致性, Availability可用性, Partition-tolerance分區容錯性三者之中只能選兩。

CP: 高一致性C和分區容錯性P的系統，放棄可用性A。
AP: 可用性A和分區容錯性P的系統，放棄高一致性C。
AC: 可用性A和高一致性C系統，放棄分區容錯性P。

根據CAP定理，存在網絡分區的狀況下，只能在可用性和一致性之間選擇。

如下面一個簡單案例爲例，寫操做在主節點服務器，讀操做在從節點服務器：

CLient ----> Web-API -----> 分佈式緩存/DB(寫操做在主節點+讀操做在從節點)

假設有一個網絡分區：

CLient ----> Web-API -----> 分佈式緩存/DB(主節點+ 這裏增長了網絡分區 +從節點)

若是由於網絡分區通信出錯，致使主從服務器節點沒法同步數據，寫入主節點的數據，沒法在從節點服務器讀出。

咱們只能作兩件事，在事務完成後發送500錯誤響應給用戶，放棄了可用性，破壞用戶體驗，這是一種悲觀作法，另一個樂觀作法是早點發送200正確響應給用戶，放棄一致性，保住可用性，保住了用戶體驗。

哪一個更好？沒有哪一個更好，徹底取決於場景狀況決定。

那麼誰在兩個方案中作決定呢？若是是開發團隊，也許不太對，任何一種方法選擇須要根據如下因素決定：
1. 實現高一致性C的成本是多少？或者不一致性的成本是多少？
2.達到高可用性有多重要?仍是仍出一個錯誤信息更合適？
3.能夠容忍多長的延遲？接近無窮大∞的高延遲等於沒有可用性。
4.方案複雜性如何？

那麼除了以上方案，有沒有可選的設計思路？

PACELC定理

PACELC定理以下：

If there is Partition,
       how does the system trade-off 
       between Availability and Consistency
Else
       how does the system trade-off
       between Latency and Consistency

若是有分區P，那就是在可用性和一致性之間平衡選擇。
不然，就是在延遲Latency和一致性之間平衡選擇。

高可用性和高一致性是咱們完美的追求，可是存在網絡分區狀況下，魚和熊掌是不可兼得的。

變通方法：放棄一點高一致性，得到一點高可用性(低延遲)，也就是最終一致性方式。

如何針對咱們這個案例實現最終一致性？

1. 針對耗時的API調用使用異步響應給用戶。
2. 在後臺作全部的寫操做工做。
3. 在數據庫集羣和緩存達成共識，同時不讓用戶等待。

這樣作的結果是開發與業務兩個方面共贏。

結論 在系統設計中考慮CAP定理是重要的。必須考慮整個系統的全部故障點。Casandra，Zoo Keeper，Kafka等技術能夠在數據層面實現最終一致性。在AP和CP之間選擇並不容易。在大多數狀況下，它取決於業務要求。