後端技能樹修煉:CAP 定理
近年來,CAP 定理已經成為分散式系統設計的基本準則之一,CAP 定理表明,任何分散式計算機系統只能同時滿足一致性(Consistency),可用性(Availability)和分割槽容錯性(Partition Tolerance)三者中的任意兩個。
那麼這三者的具體含義是什麼呢?
一致性
當資料在多個節點上分割槽儲存時,所有節點在某個指定時間將會看到相同的資料,並且在所有時間點都應該看到相同的資料
當客戶端查詢時,每個節點將返回最新的資料,否則系統將直接出錯提示
一致性的保證是通過在更新多個節點資料時,同時禁止讀取資料的方式來實現的
可用性
在任何時間點,對系統發起的每個請求都會產生一個有效的響應
當然,這並不意味著系統的每個請求都會收到包含最新資料的響應,可用性是通過在不同伺服器節點間進行資料複製實現的
分割槽容錯性
即使發生網路故障或者資料丟失,系統也能夠連續執行
可以通過在節點和網路叢集間充分的複製資料和系統功能來實現分割槽容錯。通過這種方式引入的冗餘能夠確保即使在一個或者多個節點間不能互相通訊的情況下,系統整體也能夠持續執行
由於任何分散式系統任何時候只能同時滿足 CAP 定理中的兩個屬性,因此,我們可以根據這一點將分散式系統分為三類:
CA 系統:資料在所有節點之間是一致的,我們也可以從系統的任意節點中進行讀和寫,但節點間通訊網路不能出故障
CP 系統:資料在所有節點之間是一致的,而且能夠容忍分割槽出錯並防止資料不同步
AP 系統:系統中所有節點總是線上的,但無法保證獲取到的是最新資料,但只要網路正常,節點間就會進行同步
在真實的分散式系統網路環境中,網路分割槽是不可避免的,因此,通常需要保證即使在發生網路分割槽的情況下,系統作為整體仍然能夠正常執行並提供服務,也就是滿足分割槽容錯性。因此,留給大多數分散式系統的選擇也就只剩下到底是保證系統一致性還是可用性了。
在進行系統設計時,我們要根據具體的業務場景需求來進行選擇。例如你設計的是一個類似微博這樣的系統,那麼肯定要保證系統的高可用,而使用者發表一條微博後,其他使用者要過一小段時間才能檢視到,這並不會產生多大的影響,此時可用性相對一致性而言就重要的多了。
那麼常見的中介軟體儲存系統都是什麼型別的呢?如下圖所示:

最後要強調一點,CAP 定理關注的是對資料的讀寫操作,而不是分散式系統的所有功能,它要求分散式系統節點間是互相連線且有資料共享的,例如 Memcache 的叢集中節點相互間沒有連線和資料共享,因此不是 CAP 定理討論的物件,同理 ZooKeeper 的選舉機制也不是 CAP 探討的物件。
