2016年6月26日 星期日

最近對CAP theorem的一些體會

前言

在摸索分散式系統的途中,一定會發現CAP理論是一個會在各式文章或論文中會被作者拿出來參考的一個主題,過去自己看待CAP理論也一直有一種「就這樣」的感覺,直到最近開始接觸到Cassandra才有比較深刻的體會。


簡介

CAP Theorem是由UC Berkeley的Eric Brewer於2000年時所提出,並在兩年後的2002年由MIT的Nancy Lynch 與 Seth Gilbert這兩位學者所證明,自此成為一個理論。

CAP Theorem指的是沒有一個分散式的系統可以同時滿足一致性(Consistence)、可用性(Availability)與分區容忍性(Partition Tolerance)三項,最多只能同時滿足兩項需求。



  • 一致性(Consistence)指的是:在同個時間內,任何節點的資料皆相同(all nodes see the same data at the same time)
  • 可用性(Availability)指的是:每個對系統的請求不論成功或失敗都可以獲得回應(a guarantee that every request receives a response about whether it success of failed)
  • 分區容忍性(Partition Tolerance):不論是任何信息遺失或是某節點的系統故障都不會影響到系統的運作(the system continues to operate despite arbitrary message lose or failure of part of the system)

思考


最近重新看到這張圖,上面標示的MongoDB 屬於CP(consistence+partition tolerance),而 Cassandra 屬於AP(availability+partition tolerance)

WHY??

對於這種分類法的想法是

MongoDB對資料的處理方法為採用Primary與Secondary這種分級制的系統,用戶在的所有操作皆會導向Primary,只會由Primary存取資料,正因為如此,大家都可以看到相同的資料(一致性),假如Primary這個節點出問題,系統會自動由Secondary中選出新的Primary,再選出來新的Primary前,系統可能無法正確的給予回應(可用性較低),因此被列為CP。

Cassandra之所以為AP是因為他是使用環狀結構(Ring),在Ring中的每個節點都是平等的,存取時會隨機選擇一個節點來進行存取,因此不會出現像是MongoDB這種由於Primary出問題會造成的極短時間的無法存取,但是資料需要在每個節點間進行同步,同步完成前不能保證資料的一致性,依此將Cassandra列為AP。


結論

以上只是個人對CAP理論的一點點想法,但是坦白說我認為CAP理論這種三選二的說法實在太過狹隘,隨著技術的演進,已經可以漸漸地去彌補掉自己"相對"弱勢的地方,而且可能可以依據用戶需求選擇需要的方案,而不是只有一種作法,因此我認為,最多只能說自己的系統偏向CP或是偏向AP罷了,如果有其他的想法歡迎討論。

沒有留言:

張貼留言