CAP原理

定義

在一個分佈式系統(指系統中的節點互相鏈接並共享數據)中,當涉及讀寫操做時,只能保證一致性 (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。架構設計

相關文章
相關標籤/搜索