分布式系統的一致性級別劃分及Zookeeper一致性級別分析,大佬帶你看源碼

程序員ioms 2021-09-20 02:57:45 阅读数:343

分布式 分布 一致性 一致 zookeeper

不保證在任意時刻任意節點上的同一份數據都是相同的,但是隨著時間的遷移,不同節點上的同一份數據總是在向趨同的方向變化。

簡單說,就是在一段時間後,節點間的數據會最終達到一致狀態。

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

因果一致性(Casual Consistency)。如果進程A通知進程B它已更新了一個數據項,那麼進程B的後續訪問將返回更新後的值,且一次寫入將保證取代前一次寫入。與進程A無因果關系的進程C的訪問,遵守一般的最終一致性規則。

**“讀己之所寫(read-your-writes)”一致性。**當進程A自己更新一個數據項之後,它總是訪問到更新過的值,絕不會看到舊值。這是因果一致性模型的一個特例。

**會話(Session)一致性。**這是上一個模型的實用版本,它把訪問存儲系統的進程放到會話的上下文中。只要會話還存在,系統就保證“讀己之所寫”一致性。如果由於某些失敗情形令會話終止,就要建立新的會話,而且系統的保證不會延續到新的會話。

**單調(Monotonic)讀一致性。**如果進程已經看到過數據對象的某個值,那麼任何後續訪問都不會返回在那個值之前的值。

**單調寫一致性。**系統保證來自同一個進程的寫操作順序執行。要是系統不能保證這種程度的一致性,就非常難以編程了。


另外一種劃分一致性級別的:

一致性是指從系統外部讀取系統內部的數據時,在一定約束條件下相同,即數據變動在系統內部各節點應該是同步的。根據一致性的强弱程度不同,可以將一致性級別分為如下幾種:

** ①强一致性(strong consistency)。任何時刻,任何用戶都能讀取到最近一次成功更新的數據。
** ②
單調一致性(monotonic consistency)。任何時刻,任何用戶一旦讀到某個數據在某次更新後的值,那麼就不會再讀到比這個值更舊的值。也就是說,獲取的數據順序必是單調遞增的。
** ③會話一致性(session consistency)。任何用戶在某次會話中,一旦讀到某個數據在某次更新後的值,那麼在本次會話中就不會再讀到比這值更舊的值。會話一致性是在單調一致性的基礎上進一步放松約束,只保證單個用戶單個會話內的單調性,在不同用戶或同一用戶不同會話間則沒有保障。示例case:php的session概念。
** ④
?最終一致性(eventual consistency)。用戶只能讀到某次更新後的值,但系統保證數據將最終達到完全一致的狀態,只是所需時間不能保障。
** ⑤**弱一致性(weak consistency)。用戶無法在確定時間內讀到最新更新的值。

2. 共識(Consensus)

共識問題中所有的節點要最終達成共識,由於最終目標是所有節點都要達成一致,所以根本不存在一致性强弱之分。

例如,Paxos是共識(Consensus)算法而不是强一致性(Consistency)協議。共識算法沒有一致性級別的區分。


3.線性化和可串行化的區別

讀寫操作的線性化與術語“原子一致性”同義,並且是Gilbert和Lynch?對CAP定理的證明中的?“C”或“一致性”?。我們說線性化是可組合的?(或“本地”),因為如果系統中每個對象的操作是可線性化的,那麼系統中的所有操作都是可線性化的。

可串行性是ACID中的傳統“I”或隔離。如果用戶的事務各自保持應用程序的正確性(ACID中的“C”或一致性),則可序列化執行也保持正確性。因此,可串行化是一種保證數據庫正確性的機制。

與線性化不同,可串行化本身不會對事務的排序施加任何實時約束。可序列化也是不可組合的。可串行化並不意味著任何類型的確定性順序 - 它只需要存在一些等效的串行執行。

這些定義如此混亂的原因之一是線性化來自分布式系統和並發編程社區,可串行化來自數據庫社區。如今,幾乎每個人都使用分布式系統和數據庫,這往往會導致過載的術語(例如,“一致性”,“原子”)。

4、zookeeper的一致性分析-單調一致性

很多文章和博客裏提到,zookeeper是一種提供强一致性的服務,在分區容錯性和可用性上做了一定折中,這和CAP理論是吻合的。但實際上Zookeeper提供的只是單調一致性。
原因
1. 假設有2n+1個server,在同步流程中,leader向follower同步數據,當同步完成的follower數量大於 n+1時同步流程結束,系統可接受client的連接請求。如果client連接的並非同步完成的follower,那麼得到的並非最新數據,但可以保證單調性,也就是說,可獲取的數據順序是單調遞增的。
2. 假設是follower接收到的寫請求,則會轉發給leader處理;leader完成兩階段提交的機制。向所有server發起提案,當提案獲得超過半數(n+1)的server的ACK後,將對整個集群進行同步,超過半數(n+1)的server同步完成後,該寫請求完成。如果client連接的並非同步完成follower,那麼得到的並非最新數據,但可以保證單調性,也就是說,可獲取的數據順序是單調遞增的。

用分布式系統的CAP原則來分析Zookeeper
(1)C: Zookeeper保證了最終一致性,在十幾秒可以Sync到各個節點
(2)A: Zookeeper保證了可用性,數據總是可用的,沒有鎖.並且有一大半的節點所擁有的數據是最新的,實時的. 如果想保證取得是數據一定是最新的,需要手工調用Sync()
(3)P: 有2點需要分析的

  • 節點多了會導致寫數據延時非常大,因為需要多個節點同步.

最後

針對以上面試題,小編已經把面試題+答案整理好了

 CodeChina開源項目:【一線大廠Java面試題解析+核心總結學習筆記+最新講解視頻】

分布式系統的一致性級別劃分及Zookeeper一致性級別分析,大佬帶你看源碼_後端

分布式系統的一致性級別劃分及Zookeeper一致性級別分析,大佬帶你看源碼_後端_02

分布式系統的一致性級別劃分及Zookeeper一致性級別分析,大佬帶你看源碼_後端_03

面試專題

分布式系統的一致性級別劃分及Zookeeper一致性級別分析,大佬帶你看源碼_後端_04

除了以上面試題+答案,小編同時還整理了微服務相關的實戰文檔也可以分享給大家學習

分布式系統的一致性級別劃分及Zookeeper一致性級別分析,大佬帶你看源碼_程序員_05

分布式系統的一致性級別劃分及Zookeeper一致性級別分析,大佬帶你看源碼_後端_06

?分布式系統的一致性級別劃分及Zookeeper一致性級別分析,大佬帶你看源碼_程序員_07

版权声明:本文为[程序員ioms]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/09/20210920025744519H.html