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

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

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

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

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

          最終一致性(eventually consistent)

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

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

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

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

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

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

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

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

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

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

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

          評論

          # re: CAP原理與最終一致性 強(qiáng)一致性 透析  回復(fù)  更多評論   

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

          # re: CAP原理與最終一致性 強(qiáng)一致性 透析  回復(fù)  更多評論   

          2019-09-15 10:09 by NewSea
          學(xué)習(xí)。

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


          網(wǎng)站導(dǎo)航:
           
          主站蜘蛛池模板: 忻州市| 东光县| 治县。| 建昌县| 黄石市| 襄城县| 辽阳市| 海林市| 十堰市| 永登县| 砀山县| 河东区| 承德市| 吴川市| 岳普湖县| 钦州市| 游戏| 德清县| 法库县| 杭锦旗| 江城| 年辖:市辖区| 漯河市| 津南区| 丹棱县| 汤阴县| 延庆县| 凌云县| 南开区| 麻江县| 安庆市| 中山市| 吴堡县| 临沭县| 桃源县| 留坝县| 东阳市| 宝山区| 贵溪市| 宜昌市| 公安县|