對CAP原理的理解
對CAP原理的理解
CAP原理按照定義，指的是C （Consistency）一致性，A （Availability）可用性，P （Partition tolerance）分割槽容錯性在一個完整的計算機系統中三種特性不能同時得到完全滿足。
Consistency（（強）一致性）：指的是在同一時間點，所有的資料狀態是否是一致的。對於一致性的理解，個人認為可以從關係型資料庫的事務概念出發來進行理解。例如：一次銀行賬戶的轉賬，雙方賬戶的金額必須同時增加，和減少。不能出現轉賬賬戶已經扣錢，而被轉賬賬戶未能增加金額的情況。
Availability（（高）可用性）：顧名思義，指的是計算機系統特別的好用，總是能滿足使用者的需求（接受更多請求，響應更快），用形式化的語言描述就是系統擁有非常高的非故障執行時間百分率。這一特性在如今網際網路時代，海量使用者，大併發請求的場景下對於計算機系統顯得尤為重要，畢竟沒有使用者喜歡一到高峰時期就停止響應的系統。
Partition tolerance（分割槽容錯性）：指的是在整個系統擁有兩臺或以上數量的計算機單元提供服務，當其中部分分割槽節點故障時，整個系統依然可以向用戶提供可靠的服務。
CAP定理告訴我們CAP這三種特性不能同時完全滿足,因此存在以下三種取捨情況：
1.選擇CA，放棄P
通常是由一臺非常強大的計算機對外提供服務來保證A（高可用性），所有的資料操作都在同一臺機器上。在上面提到的銀行賬戶轉賬例子中，在資料庫層面上通過本地事務來輕鬆滿足C（（強）一致性）。試想如果此時想要擁有P，即轉賬雙方位於不同分割槽，那麼一旦被轉賬方出現故障，要麼耗費時間等待其重新開始服務（放棄A）；或者暫時僅僅處理轉賬方的業務，等待後續的一致性補償操作（放棄C）。
該方案的缺點：由於目前科學技術上的限制，無法橫向擴容的系統是無法應付海量請求，大併發的場景的，同時也容易導致單點故障出現，因此這裡的A（高可用性）實際上是大打折扣的。
2.選擇CP，放棄A。
意味著系統在提供服務時，一旦出現分割槽故障，為了確保資料的強一致性，所涉及到的服務全部都會停止響應，因此A（高可用性）也就不復存在啦。暫時還沒有想到什麼場景下會採取這種方案。
該方案的缺點：個人認為低可用性本身就是系統的一大缺點。
3.選擇AP，放棄C。這種架構可以說是如今網際網路時代最流行的架構。通過分散式和叢集進行橫向的系統性能拓展，儘可能的捨棄對資料強一致性的需求，同時在遇到不可避免的分散式事務場景時，大牛們也已經提出了各種各樣的方案來滿足最終的資料一致性（（弱）一致性），就不再這裡展開說明了。
該方案的缺點：不適合對資料一致性C（（強）一致性）有極高要求的場景，以及不追求A（高可用性）要求的場景（分割槽總是會帶來額外的麻煩）。
其實，選擇AP而放棄C的設計理念並不僅僅適用於整個系統的整體架構，例如在系統內部，資料庫叢集（可以理解為一個子系統）主從分離的同步延遲造成從庫資料與主庫資料出現數據暫時不一致的情況等等。
除此之外，CAP中的三個元素也並不是完全的互斥，例如選擇AP，其實也不是徹底的放棄了C（一致性），而是進行了一定程度的讓步，同時C（一致性）也能細分為讀一致性，寫一致性等。因此不能機械的將CAP理論理解為完全互斥，三選二，而是在這三個維度上面進行不同程度的取捨。個人認為CAP理論其實是告訴人們天下沒有免費的午餐，也不存在完美無缺的系統設計，需要反覆的斟酌，權衡，才能設計出合理的，符合需求的系統架構。
以上是我對CAP原理的一些理解，存在不少誤區，歡迎交流。