定義
在一個分布式系統（指系統中的節點互相連接并共享資料）中，當涉及讀寫操作時，只能保證一致性 (Consistency)、可用性 (Availability)、磁區容錯性 (Partition Tolerance)三者中的兩個，另外一個必須被犧牲，
- 一致性：CAP中的C和ACID 中的C不是一個含義，ACID 中的C是指資料庫中的資料滿足一定的約束條件，而CAP中的C是指線性一致性，即：客戶端向系統寫入什么，那么讀出來的也會是什么，也就是要保證客戶端讀取到的資料一定是上次寫入的最新資料，
- 可用性：指系統中的部分節點出現故障后，系統能否還能對外提供完全可用的服務；
- 磁區容錯性：指是否允許系統中的節點之間無法通信，也就是無法互相連接；
適用場景
那么什么樣的分布式系統是節點之間互聯并共享資料呢？
典型的場景就是資料庫的主從集群，一個資料庫集群有一個主，多個從，主從之間會進行資料復制，所以適用于CAP原理，
那么如果我現在是一個Redis的集群，集群中每臺機器存盤不同的資料，集群中每臺機器不需要復制和傳遞資料，那么就不屬于CAP原理的討論范圍，同理，如果是A,B兩個不同的業務系統，比如招行賬號A給工行賬號B轉賬100元，由于招行和工行是兩個不同的業務系統，業務上隔離，且他們之間也沒有共享的資料，從而也不屬于CAP原理的討論范圍，
場景方案選擇
- 傳統資料庫主從集群：如果當前是一個現在是一個主從復制的資料庫集群，同一條資料會在主從資料庫上都存盤，那么當存在主從資料庫之間網路斷開時，我們確實只能要么選擇A放棄C，要么選擇C放棄A，選擇A放棄C，就是客戶端讀取到的可能不是最新的資料，但是系統持續可用；選擇C放棄A，就是讓系統服務不可用，客戶端自然就不會認為資料不一致了，
- 分布式資料庫，如阿里的OceanBase，這種資料庫也是一個主從的集群，但是主從節點往往使用Paxos/Raft等副本一致性協議，做到整個資料庫系統，在部分節點發生故障時，也能在很短的時間內自動重新選主，選出一個新的主從集群的資料庫系統，在重新選主的程序中，系統不可用，相當于放棄了A，而一旦選出新的主之后，系統又繼續可用，且資料對外是線性一致的，相比傳統的資料庫主從集群，分布式資料庫由于可以在遇到網路磁區導致資料庫主從節點之間無法互聯時，可以快速選出新的主，然后快速恢復，所以架構設計上和用戶體驗上，要好很多，但是系統設計的復雜度也非常高，
分布式事務
通過上面的分析，我們知道CAP中的資料一致性，本質上是為了維護同一個資料的不同副本之間的一致性，而更多的時候，我們要解決的是不同業務系統之間的資料一致性，即資料之間總是應該滿足規定的業務規則，典型的場景比如有跨行轉賬、訂單和減庫存，這種場景，由于沒有資料共享的特征，所以不適用于CAP，比如A銀行的賬戶給B銀行的賬戶轉賬100元，那么轉賬前后，兩個賬戶的錢加起來應該不變，也就是A扣款了，B就必須加款，那么這種場景如何解決呢？一般的做法是采用分布式事務，常見的分布式事務的解決方案有：2PC\3PC、TCC、基于分布式MQ+本地訊息、分布式MQ事務訊息、Sagas，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/22703.html
標籤：架構設計
上一篇：復雜系統架構設計<1>
下一篇：實施微服務架構，有哪些關鍵步驟？