最近在研究分布式系統(tǒng)的一些理論概念,例如關(guān)于分布式系統(tǒng)一致性的討論,看了一些文章我有一些不解。大多數(shù)對分布式系統(tǒng)一致性的劃分是將其分為三類:強一致性,順序一致性以及弱一致性。強一致性(Strict Consistency)也稱為:原子一致性(Atomic Consistency)、線性一致性(Linearizable Consistency)。
10多年的社旗網(wǎng)站建設(shè)經(jīng)驗,針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù),響應(yīng)快,48小時及時工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同,自動調(diào)整社旗建站的顯示方式,使網(wǎng)站能夠適用不同顯示終端,在瀏覽器中調(diào)整網(wǎng)站的寬度,無論在任何一種瀏覽器上瀏覽網(wǎng)站,都能展現(xiàn)優(yōu)雅布局與設(shè)計,從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)公司從事“社旗網(wǎng)站設(shè)計”,“社旗網(wǎng)站推廣”以來,每個客戶項目都認真落實執(zhí)行。
在談到Zookeeper的一致性是哪種級別的一致性問題,以及CAP原則中的C是哪一種一致性級別時有些疑惑。
下面是大多數(shù)文章中提到的一致性級別
一致性(Consistency)是指多副本(Replications)問題中的數(shù)據(jù)一致性。可以分為強一致性、順序一致性與弱一致性。
也稱為:原子一致性(Atomic Consistency)**線性一致性(Linearizable Consistency)**
強一致性有兩個要求:
簡言之,在任意時刻,所有節(jié)點中的數(shù)據(jù)都是一樣的。
例如,對于關(guān)系型數(shù)據(jù)庫,要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到,這是強一致性。
the result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program. - - Lamport
兩個要求:
舉個例子:
Write(x, 4):寫入x=4?
Read(x, 0):讀出x=0
1)圖a是滿足順序一致性,但是不滿足強一致性的。原因在于,從全局時鐘的觀點來看,P2進程對變量X的讀操作在P1進程對變量X的寫操作之后,然而讀出來的卻是舊的數(shù)據(jù)。但是這個圖卻是滿足順序一致性的,因為兩個進程P1,P2的一致性并沒有沖突。從這兩個進程的角度來看,順序應(yīng)該是這樣的:Write(y,2) , Read(x,0) , Write(x,4), Read(y,2),每個進程內(nèi)部的讀寫順序都是合理的,但是這個順序與全局時鐘下看到的順序并不一樣。
2)圖b滿足強一致性,因為每個讀操作都讀到了該變量的最新寫的結(jié)果,同時兩個進程看到的操作順序與全局時鐘的順序一樣,都是Write(y,2) ,Write(x,4), Read(x,4) ,? Read(y,2)。
3)圖c不滿足順序一致性,當然也就不滿足強一致性了。因為從進程P1的角度看,它對變量Y的讀操作返回了結(jié)果0。那么就是說,P1進程的對變量Y的讀操作在P2進程對變量Y的寫操作之前,這意味著它認為的順序是這樣的:Write(x,4) , Read(y,0) , Write(y,2), Read(x,0),顯然這個順序又是不能被滿足的,因為最后一個對變量x的讀操作讀出來也是舊的數(shù)據(jù)。因此這個順序是有沖突的,不滿足順序一致性。
數(shù)據(jù)更新后,如果能容忍后續(xù)的訪問只能訪問到部分或者全部訪問不到,則是弱一致性。
最終一致性就屬于弱一致性。
不保證在任意時刻任意節(jié)點上的同一份數(shù)據(jù)都是相同的,但是隨著時間的遷移,不同節(jié)點上的同一份數(shù)據(jù)總是在向趨同的方向變化。
簡單說,就是在一段時間后,節(jié)點間的數(shù)據(jù)會最終達到一致狀態(tài)。
最終一致性根據(jù)更新數(shù)據(jù)后各進程訪問到數(shù)據(jù)的時間和方式的不同,又可以區(qū)分為:
因果一致性(Casual Consistency)。如果進程A通知進程B它已更新了一個數(shù)據(jù)項,那么進程B的后續(xù)訪問將返回更新后的值,且一次寫入將保證取代前一次寫入。與進程A無因果關(guān)系的進程C的訪問,遵守一般的最終一致性規(guī)則。
“讀己之所寫(read-your-writes)”一致性。當進程A自己更新一個數(shù)據(jù)項之后,它總是訪問到更新過的值,絕不會看到舊值。這是因果一致性模型的一個特例。
會話(Session)一致性。這是上一個模型的實用版本,它把訪問存儲系統(tǒng)的進程放到會話的上下文中。只要會話還存在,系統(tǒng)就保證“讀己之所寫”一致性。如果由于某些失敗情形令會話終止,就要建立新的會話,而且系統(tǒng)的保證不會延續(xù)到新的會話。
單調(diào)(Monotonic)讀一致性。如果進程已經(jīng)看到過數(shù)據(jù)對象的某個值,那么任何后續(xù)訪問都不會返回在那個值之前的值。
單調(diào)寫一致性。系統(tǒng)保證來自同一個進程的寫操作順序執(zhí)行。要是系統(tǒng)不能保證這種程度的一致性,就非常難以編程了。
另外一種劃分一致性級別的:
一致性是指從系統(tǒng)外部讀取系統(tǒng)內(nèi)部的數(shù)據(jù)時,在一定約束條件下相同,即數(shù)據(jù)變動在系統(tǒng)內(nèi)部各節(jié)點應(yīng)該是同步的。根據(jù)一致性的強弱程度不同,可以將一致性級別分為如下幾種:
①強一致性(strong consistency)。任何時刻,任何用戶都能讀取到最近一次成功更新的數(shù)據(jù)。
②單調(diào)一致性(monotonic consistency)。任何時刻,任何用戶一旦讀到某個數(shù)據(jù)在某次更新后的值,那么就不會再讀到比這個值更舊的值。也就是說,獲取的數(shù)據(jù)順序必是單調(diào)遞增的。
?、?/strong>會話一致性(session consistency)。任何用戶在某次會話中,一旦讀到某個數(shù)據(jù)在某次更新后的值,那么在本次會話中就不會再讀到比這值更舊的值。會話一致性是在單調(diào)一致性的基礎(chǔ)上進一步放松約束,只保證單個用戶單個會話內(nèi)的單調(diào)性,在不同用戶或同一用戶不同會話間則沒有保障。示例case:php的session概念。
?、?/strong>?最終一致性(eventual consistency)。用戶只能讀到某次更新后的值,但系統(tǒng)保證數(shù)據(jù)將最終達到完全一致的狀態(tài),只是所需時間不能保障。
?、?/strong>弱一致性(weak consistency)。用戶無法在確定時間內(nèi)讀到最新更新的值。
共識問題中所有的節(jié)點要最終達成共識,由于最終目標是所有節(jié)點都要達成一致,所以根本不存在一致性強弱之分。
例如,Paxos是共識(Consensus)算法而不是強一致性(Consistency)協(xié)議。共識算法沒有一致性級別的區(qū)分。
讀寫操作的線性化與術(shù)語“原子一致性”同義,并且是Gilbert和Lynch?對CAP定理的證明中的?“C”或“一致性”?。我們說線性化是可組合的?(或“本地”),因為如果系統(tǒng)中每個對象的操作是可線性化的,那么系統(tǒng)中的所有操作都是可線性化的。
可串行性是ACID中的傳統(tǒng)“I”或隔離。如果用戶的事務(wù)各自保持應(yīng)用程序的正確性(ACID中的“C”或一致性),則可序列化執(zhí)行也保持正確性。因此,可串行化是一種保證數(shù)據(jù)庫正確性的機制。
與線性化不同,可串行化本身不會對事務(wù)的排序施加任何實時約束??尚蛄谢彩遣豢山M合的??纱谢⒉灰馕吨魏晤愋偷拇_定性順序 - 它只需要存在一些等效的串行執(zhí)行。
這些定義如此混亂的原因之一是線性化來自分布式系統(tǒng)和并發(fā)編程社區(qū),可串行化來自數(shù)據(jù)庫社區(qū)。如今,幾乎每個人都使用分布式系統(tǒng)和數(shù)據(jù)庫,這往往會導致過載的術(shù)語(例如,“一致性”,“原子”)。
很多文章和博客里提到,zookeeper是一種提供強一致性的服務(wù),在分區(qū)容錯性和可用性上做了一定折中,這和CAP理論是吻合的。但實際上Zookeeper提供的只是單調(diào)一致性。
原因:
1. 假設(shè)有2n+1個server,在同步流程中,leader向follower同步數(shù)據(jù),當同步完成的follower數(shù)量大于 n+1時同步流程結(jié)束,系統(tǒng)可接受client的連接請求。如果client連接的并非同步完成的follower,那么得到的并非最新數(shù)據(jù),但可以保證單調(diào)性,也就是說,可獲取的數(shù)據(jù)順序是單調(diào)遞增的。
2. 假設(shè)是follower接收到的寫請求,則會轉(zhuǎn)發(fā)給leader處理;leader完成兩階段提交的機制。向所有server發(fā)起提案,當提案獲得超過半數(shù)(n+1)的server的ACK后,將對整個集群進行同步,超過半數(shù)(n+1)的server同步完成后,該寫請求完成。如果client連接的并非同步完成follower,那么得到的并非最新數(shù)據(jù),但可以保證單調(diào)性,也就是說,可獲取的數(shù)據(jù)順序是單調(diào)遞增的。
用分布式系統(tǒng)的CAP原則來分析Zookeeper:
(1)C: Zookeeper保證了最終一致性,在十幾秒可以Sync到各個節(jié)點
(2)A: Zookeeper保證了可用性,數(shù)據(jù)總是可用的,沒有鎖.并且有一大半的節(jié)點所擁有的數(shù)據(jù)是最新的,實時的. 如果想保證取得是數(shù)據(jù)一定是最新的,需要手工調(diào)用Sync()
(3)P: 有2點需要分析的
可以的出的結(jié)論是Zookeeper的一致性保證的是單調(diào)一致性,CAP原則中的C是強一致性。