posts - 110, comments - 101, trackbacks - 0, articles - 7
            BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

          CAP原理與最終一致性 強一致性 透析

          Posted on 2012-04-27 10:23 云云 閱讀(17366) 評論(2)  編輯  收藏

          在足球比賽里,一個球員在一場比賽中進三個球,稱之為帽子戲法(Hat-trick)。在分布式數(shù)據(jù)系統(tǒng)中,也有一個帽子原理(CAP Theorem),不過此帽子非彼帽子。CAP原理中,有三個要素:

          • 一致性(Consistency)
          • 可用性(Availability)
          • 分區(qū)容忍性(Partition tolerance)

          CAP原理指的是,這三個要素最多只能同時實現(xiàn)兩點,不可能三者兼顧。因此在進行分布式架構設計時,必須做出取舍。而對于分布式數(shù)據(jù)系統(tǒng),分區(qū)容忍性是基本要求,否則就失去了價值。因此設計分布式數(shù)據(jù)系統(tǒng),就是在一致性和可用性之間取一個平衡。對于大多數(shù)web應用,其實并不需要強一致性,因此犧牲一致性而換取高可用性,是目前多數(shù)分布式數(shù)據(jù)庫產(chǎn)品的方向。

          當然,犧牲一致性,并不是完全不管數(shù)據(jù)的一致性,否則數(shù)據(jù)是混亂的,那么系統(tǒng)可用性再高分布式再好也沒有了價值。犧牲一致性,只是不再要求關系型數(shù)據(jù)庫中的強一致性,而是只要系統(tǒng)能達到最終一致性即可,考慮到客戶體驗,這個最終一致的時間窗口,要盡可能的對用戶透明,也就是需要保障“用戶感知到的一致性”。通常是通過數(shù)據(jù)的多份異步復制來實現(xiàn)系統(tǒng)的高可用和數(shù)據(jù)的最終一致性的,“用戶感知到的一致性”的時間窗口則取決于數(shù)據(jù)復制到一致狀態(tài)的時間。

          最終一致性(eventually consistent)

          對于一致性,可以分為從客戶端和服務端兩個不同的視角。從客戶端來看,一致性主要指的是多并發(fā)訪問時更新過的數(shù)據(jù)如何獲取的問題。從服務端來看,則是更新如何復制分布到整個系統(tǒng),以保證數(shù)據(jù)最終一致。一致性是因為有并發(fā)讀寫才有的問題,因此在理解一致性的問題時,一定要注意結合考慮并發(fā)讀寫的場景。

          從客戶端角度,多進程并發(fā)訪問時,更新過的數(shù)據(jù)在不同進程如何獲取的不同策略,決定了不同的一致性。對于關系型數(shù)據(jù)庫,要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到,這是強一致性。如果能容忍后續(xù)的部分或者全部訪問不到,則是弱一致性。如果經(jīng)過一段時間后要求能訪問到更新后的數(shù)據(jù),則是最終一致性。

          最終一致性根據(jù)更新數(shù)據(jù)后各進程訪問到數(shù)據(jù)的時間和方式的不同,又可以區(qū)分為:

          • 因果一致性。如果進程A通知進程B它已更新了一個數(shù)據(jù)項,那么進程B的后續(xù)訪問將返回更新后的值,且一次寫入將保證取代前一次寫入。與進程A無因果關系的進程C的訪問遵守一般的最終一致性規(guī)則。
          • “讀己之所寫(read-your-writes)”一致性。當進程A自己更新一個數(shù)據(jù)項之后,它總是訪問到更新過的值,絕不會看到舊值。這是因果一致性模型的一個特例。
          • 會話(Session)一致性。這是上一個模型的實用版本,它把訪問存儲系統(tǒng)的進程放到會話的上下文中。只要會話還存在,系統(tǒng)就保證“讀己之所寫”一致性。如果由于某些失敗情形令會話終止,就要建立新的會話,而且系統(tǒng)的保證不會延續(xù)到新的會話。
          • 單調(Monotonic)讀一致性。如果進程已經(jīng)看到過數(shù)據(jù)對象的某個值,那么任何后續(xù)訪問都不會返回在那個值之前的值。
          • 單調寫一致性。系統(tǒng)保證來自同一個進程的寫操作順序執(zhí)行。要是系統(tǒng)不能保證這種程度的一致性,就非常難以編程了。

          上述最終一致性的不同方式可以進行組合,例如單調讀一致性和讀己之所寫一致性就可以組合實現(xiàn)。并且從實踐的角度來看,這兩者的組合,讀取自己更新的數(shù)據(jù),和一旦讀取到最新的版本不會再讀取舊版本,對于此架構上的程序開發(fā)來說,會少很多額外的煩惱。

          從服務端角度,如何盡快將更新后的數(shù)據(jù)分布到整個系統(tǒng),降低達到最終一致性的時間窗口,是提高系統(tǒng)的可用度和用戶體驗非常重要的方面。對于分布式數(shù)據(jù)系統(tǒng):

          • N — 數(shù)據(jù)復制的份數(shù)
          • W — 更新數(shù)據(jù)是需要保證寫完成的節(jié)點數(shù)
          • R — 讀取數(shù)據(jù)的時候需要讀取的節(jié)點數(shù)

          如果W+R>N,寫的節(jié)點和讀的節(jié)點重疊,則是強一致性。例如對于典型的一主一備同步復制的關系型數(shù)據(jù)庫,N=2,W=2,R=1,則不管讀的是主庫還是備庫的數(shù)據(jù),都是一致的。

          如果W+R<=N,則是弱一致性。例如對于一主一備異步復制的關系型數(shù)據(jù)庫,N=2,W=1,R=1,則如果讀的是備庫,就可能無法讀取主庫已經(jīng)更新過的數(shù)據(jù),所以是弱一致性。

          對于分布式系統(tǒng),為了保證高可用性,一般設置N>=3。不同的N,W,R組合,是在可用性和一致性之間取一個平衡,以適應不同的應用場景。

          • 如果N=W,R=1,任何一個寫節(jié)點失效,都會導致寫失敗,因此可用性會降低,但是由于數(shù)據(jù)分布的N個節(jié)點是同步寫入的,因此可以保證強一致性。
          • 如果N=R,W=1,只需要一個節(jié)點寫入成功即可,寫性能和可用性都比較高。但是讀取其他節(jié)點的進程可能不能獲取更新后的數(shù)據(jù),因此是弱一致性。這種情況下,如果W<(N+1)/2,并且寫入的節(jié)點不重疊的話,則會存在寫沖突  

          評論

          # re: CAP原理與最終一致性 強一致性 透析  回復  更多評論   

          2016-04-17 21:31 by 王海龍
          能否表明出處?百度百科cap 內容同此,但不支持原始出處

          # re: CAP原理與最終一致性 強一致性 透析  回復  更多評論   

          2019-09-15 10:09 by NewSea
          學習。

          只有注冊用戶登錄后才能發(fā)表評論。


          網(wǎng)站導航:
           
          主站蜘蛛池模板: 沽源县| 永善县| 当涂县| 威远县| 那曲县| 永州市| 祁门县| 星子县| 聂荣县| 礼泉县| 汽车| 巴彦淖尔市| 阳春市| 石渠县| 孝昌县| 寻乌县| 漠河县| 浮山县| 定西市| 翁源县| 海原县| 湟中县| 乳山市| 梅河口市| 鄂托克旗| 通道| 利川市| 德惠市| 武山县| 项城市| 阿尔山市| 武邑县| 双牌县| 威信县| 兰州市| 宜兰市| 同江市| 本溪市| 阿鲁科尔沁旗| 嘉荫县| 河北省|