後端技能樹修煉:CAP 定理

近年來,CAP 定理已經成爲分佈式系統設計的基本準則之一,CAP 定理表明,任何分佈式計算機系統只能同時滿足一致性(Consistency),可用性(Availability)和分區容錯性(Partition Tolerance)三者中的任意兩個。

那麼這三者的具體含義是什麼呢?

一致性

當數據在多個節點上分區存儲時,所有節點在某個指定時間將會看到相同的數據,並且在所有時間點都應該看到相同的數據

當客戶端查詢時,每個節點將返回最新的數據,否則系統將直接出錯提示

一致性的保證是通過在更新多個節點數據時,同時禁止讀取數據的方式來實現的

可用性

在任何時間點,對系統發起的每個請求都會產生一個有效的響應

當然,這並不意味着系統的每個請求都會收到包含最新數據的響應,可用性是通過在不同服務器節點間進行數據複製實現的

分區容錯性

即使發生網絡故障或者數據丟失,系統也能夠連續運行

可以通過在節點和網絡集羣間充分的複製數據和系統功能來實現分區容錯。通過這種方式引入的冗餘能夠確保即使在一個或者多個節點間不能互相通信的情況下,系統整體也能夠持續運行

由於任何分佈式系統任何時候只能同時滿足 CAP 定理中的兩個屬性,因此,我們可以根據這一點將分佈式系統分爲三類:

CA 系統:數據在所有節點之間是一致的,我們也可以從系統的任意節點中進行讀和寫,但節點間通信網絡不能出故障

CP 系統:數據在所有節點之間是一致的,而且能夠容忍分區出錯並防止數據不同步

AP 系統:系統中所有節點總是在線的,但無法保證獲取到的是最新數據,但只要網絡正常,節點間就會進行同步

在真實的分佈式系統網絡環境中,網絡分區是不可避免的,因此,通常需要保證即使在發生網絡分區的情況下,系統作爲整體仍然能夠正常運行並提供服務,也就是滿足分區容錯性。因此,留給大多數分佈式系統的選擇也就只剩下到底是保證系統一致性還是可用性了。

在進行系統設計時,我們要根據具體的業務場景需求來進行選擇。例如你設計的是一個類似微博這樣的系統,那麼肯定要保證系統的高可用,而用戶發表一條微博後,其他用戶要過一小段時間才能查看到,這並不會產生多大的影響,此時可用性相對一致性而言就重要的多了。

那麼常見的中間件存儲系統都是什麼類型的呢?如下圖所示:


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

給大家推薦一個程序員學習交流羣:863621962。羣裏有分享的視頻,還有思維導圖

羣公告有視頻,都是乾貨的,你可以下載來看。主要分享分佈式架構、高可擴展、高性能、高併發、性能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分佈式項目實戰學習架構師視頻。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章