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

來源:互聯網
上載者:User

標籤:blog   http   io   ar   sp   java   strong   on   資料   

在足球比賽裡,一個球員在一場比賽中進三個球,稱之為帽子戲法(Hat-trick)。在分布式資料系統中,也有一個帽子原理(CAP Theorem),不過此帽子非彼帽子。CAP原理中,有三個要素:

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

CAP原理指的是,這三個要素最多隻能同時實現兩點,不可能三者兼顧。因此在進行分布式架構設計時,必須做出取捨。而對於分布式資料系統,分區容忍性是基本要求,否則就失去了價值。因此設計分布式資料系統,就是在一致性和可用性之間取一個平衡。對於大多數web應用,其實並不需要強一致性,因此犧牲一致性而換取高可用性,是目前多數分散式資料庫產品的方向。

當然,犧牲一致性,並不是完全不管資料的一致性,否則資料是混亂的,那麼系統可用性再高分布式再好也沒有了價值。犧牲一致性,只是不再要求關係型資料庫中的強一致性,而是只要系統能達到最終一致性即可,考慮到客戶體驗,這個最終一致的時間視窗,要儘可能的對使用者透明,也就是需要保障“使用者感知到的一致性”。通常是通過資料的多份非同步複製來實現系統的高可用和資料的最終一致性的,“使用者感知到的一致性”的時間視窗則取決於資料複製到一致狀態的時間。

最終一致性(eventually consistent)

對於一致性,可以分為從用戶端和服務端兩個不同的視角。從用戶端來看,一致性主要指的是多並發訪問時更新過的資料如何擷取的問題。從服務端來看,則是更新如何複製分布到整個系統,以保證資料最終一致。一致性是因為有並發讀寫才有的問題,因此在理解一致性的問題時,一定要注意結合考慮並發讀寫的情境。

從用戶端角度,多進程並發訪問時,更新過的資料在不同進程如何擷取的不同策略,決定了不同的一致性。對於關係型資料庫,要求更新過的資料能被後續的訪問都能看到,這是強一致性。如果能容忍後續的部分或者全部訪問不到,則是弱一致性。如果經過一段時間後要求能訪問到更新後的資料,則是最終一致性。

最終一致性根據更新資料後各進程訪問到資料的時間和方式的不同,又可以區分為:

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

上述最終一致性的不同方式可以進行組合,例如單調讀一致性和讀己之所寫一致性就可以組合實現。並且從實踐的角度來看,這兩者的組合,讀取自己更新的資料,和一旦讀取到最新的版本不會再讀取舊版本,對於此架構上的程式開發來說,會少很多額外的煩惱。

從服務端角度,如何儘快將更新後的資料分布到整個系統,降低達到最終一致性的時間視窗,是提高系統的可用度和使用者體驗非常重要的方面。對於分布式資料系統:

  • N — 資料複製的份數
  • W — 更新資料是需要保證寫完成的節點數
  • R — 讀取資料的時候需要讀取的節點數

如果W+R>N,寫的節點和讀的節點重疊,則是強一致性。例如對於典型的一主一備同步複製的關係型資料庫,N=2,W=2,R=1,則不管讀的是主庫還是備庫的資料,都是一致的。

如果W+R<=N,則是弱一致性。例如對於一主一備非同步複製的關係型資料庫,N=2,W=1,R=1,則如果讀的是備庫,就可能無法讀取主庫已經更新過的資料,所以是弱一致性。

對於分布式系統,為了保證高可用性,一般設定N>=3。不同的N,W,R組合,是在可用性和一致性之間取一個平衡,以適應不同的應用情境。

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

轉自:http://www.blogjava.net/hello-yun/archive/2012/04/27/376744.html

參見:http://www.infoq.com/cn/news/2008/01/consistency-vs-availability

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

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.