據(jù)說60%的Java程序員不明白分布式一致性?這次徹底搞懂!

前言

專注于為中小企業(yè)提供成都網(wǎng)站制作、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)偃師免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動了1000多家企業(yè)的穩(wěn)健成長,幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

在計算機科學領(lǐng)域,分布式一致性是一個相當重要且被廣泛探索與論證問題,首先來看三種業(yè)務(wù)場景。

據(jù)說60%的Java程序員不明白分布式一致性?這次徹底搞懂!

1、火車站售票

假如說我們的終端用戶是一位經(jīng)常坐火車的旅行家,通常他是去車站的售票處購買車票,然后拿著車票去檢票口,再坐上火車,開始一段美好的旅行----一切似乎都是那么和諧。

想象一下,如果他選擇的目的地是杭州,而某一趟開往杭州的火車只剩下最后一張車票,可能在同一時刻,不同售票窗口的另一位乘客也購買了同一張車票。假如說售票系統(tǒng)沒有進行一致性的保障,兩人都購票成功了。而在檢票口檢票的時候,其中一位乘客會被告知他的車票無效……

當然,現(xiàn)代的中國鐵路售票系統(tǒng)已經(jīng)很少出現(xiàn)這樣的問題了。但在這個例子中我們可以看出,終端用戶對于系統(tǒng)的需求非常簡單:

"請售票給我,如果沒有余票了,請在售票的時候就告訴我票是無效的"

這就對購票系統(tǒng)提出了嚴格的一致性要求----系統(tǒng)的數(shù)據(jù)(本例中指的就是那趟開往杭州的火車的余票數(shù))無論在哪個售票窗口,每時每刻都必須是準確無誤的!

2、銀行轉(zhuǎn)賬

假如我們的終端用戶是一位剛畢業(yè)的大學生,通常在拿到第一個月工資的時候,都會選擇向家里匯款。當他來到銀行柜臺,完成轉(zhuǎn)賬操作后,銀行的柜臺服務(wù)員會友善地提醒他:"您的轉(zhuǎn)賬將在N個工作日后到賬!"。

此時這名畢業(yè)生有一定的沮喪,會對那名柜臺服務(wù)員叮囑:"好吧,多久沒關(guān)系,錢不要少就好了!"……

這也成為了幾乎所有用戶對于現(xiàn)代銀行系統(tǒng)最基本的需求

3、網(wǎng)上購物

假如說我們的終端用戶是一位網(wǎng)購達人,當他看見一件庫存量為5的心儀商品,會迅速地確認購買,寫下收貨地址,然后下單……

然而,在下單的那個瞬間,系統(tǒng)可能會告知該用戶:"庫存量不足!"。此時絕大部分消費者都會抱怨自己動作太慢,使得心愛的商品被其他人搶走了。

但其實有過網(wǎng)購系統(tǒng)開發(fā)經(jīng)驗的工程師一定明白,在商品詳情頁上顯示的那個庫存量,通常不是該商品的真實庫存量,只有在真正下單購買的時候,系統(tǒng)才會檢查該商品的真實庫存量。但是,誰在意呢?

據(jù)說60%的Java程序員不明白分布式一致性?這次徹底搞懂!

問題的解讀

對于上面三個例子,相信大家一定看出來了,我們的終端用戶在使用不同的計算機產(chǎn)品時對于數(shù)據(jù)一致性的需求是不一樣的:

1、有些系統(tǒng),既要快速地響應(yīng)用戶,同時還要保證系統(tǒng)的數(shù)據(jù)對于任意客戶端都是真實可靠的,就像火車站售票系統(tǒng)

2、有些系統(tǒng),需要為用戶保證絕對可靠的數(shù)據(jù)安全,雖然在數(shù)據(jù)一致性上存在延時,但最終務(wù)必保證嚴格的一致性,就像銀行的轉(zhuǎn)賬系統(tǒng)

3、有些系統(tǒng),雖然向用戶展示了一些可以說是"錯誤"的數(shù)據(jù),但是在整個系統(tǒng)使用過程中,一定會在某一個流程上對系統(tǒng)數(shù)據(jù)進行準確無誤的檢查,從而避免用戶發(fā)生不必要的損失,就像網(wǎng)購系統(tǒng)

分布式一致性的提出

在分布式系統(tǒng)中要解決的一個重要問題就是數(shù)據(jù)的復(fù)制。

在我們的日常開發(fā)經(jīng)驗中,相信很多開發(fā)人員都遇到過這樣的問題:假設(shè)客戶端C1將系統(tǒng)中的一個值K由V1更新為V2,但客戶端C2無法立即讀取到K的最新值,需要在一段時間之后才能讀取到。

這很正常,因為數(shù)據(jù)庫復(fù)制之間存在延時。

分布式系統(tǒng)對于數(shù)據(jù)的復(fù)制需求一般都來自于以下兩個原因:

1、為了增加系統(tǒng)的可用性,以防止單點故障引起的系統(tǒng)不可用

2、提高系統(tǒng)的整體性能,通過

沒錯,這似乎能解決問題,而且有一些系統(tǒng)的架構(gòu)也確實直接使用了這個思路。但這個思路在解決一致性問題的同時,又帶來了新的問題:寫入的性能。

如果你的應(yīng)用場景有非常多的寫請求,那么使用這個思路之后,后續(xù)的寫請求都將會阻塞在前一個請求的寫操作上,導(dǎo)致系統(tǒng)整體性能急劇下降。

總得來說,我們無法找到一種能夠滿足分布式系統(tǒng)所有系統(tǒng)屬性的分布式一致性解決方案。因此,如何既保證數(shù)據(jù)的一致性,同時又不影響系統(tǒng)運行的性能,是每一個分布式系統(tǒng)都需要重點考慮和權(quán)衡的。于是,一致性級別由此誕生:

1、強一致性

這種一致性級別是最符合用戶直覺的,它要求系統(tǒng)寫入什么,讀出來的也會是什么,用戶體驗好,但實現(xiàn)起來往往對系統(tǒng)的性能影響大

2、弱一致性

這種一致性級別約束了系統(tǒng)在寫入成功后,不承諾立即可以讀到寫入的值,也不久承諾多久之后數(shù)據(jù)能夠達到一致,但會盡可能地保證到某個時間級別(比如秒級別)后,數(shù)據(jù)能夠達到一致狀態(tài)

3、最終一致性

最終一致性是弱一致性的一個特例,系統(tǒng)會保證在一定時間內(nèi),能夠達到一個數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨提出來,是因為它是弱一致性中非常推崇的一種一致性模型,也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型

歡迎大家關(guān)注我的公種浩【程序員追風】,文章都會在里面更新,整理的資料也會放在里面。

據(jù)說60%的Java程序員不明白分布式一致性?這次徹底搞懂!

分布式環(huán)境的各種問題

分布式系統(tǒng)體系結(jié)構(gòu)從其出現(xiàn)之初就伴隨著諸多的難題和挑戰(zhàn):

1、通信異常

從集中式向分布式演變的過程中,必然引入網(wǎng)絡(luò)因素,由于網(wǎng)絡(luò)本身的不可靠性,因此也引入了額外的問題。

分布式系統(tǒng)需要在各個節(jié)點之間進行網(wǎng)絡(luò)通信,因此每次網(wǎng)絡(luò)通信都會伴隨著網(wǎng)絡(luò)不可用的風險,網(wǎng)絡(luò)光纖、路由器或是DNS等硬件設(shè)備或是系統(tǒng)不可用都會導(dǎo)致最終分布式系統(tǒng)無法順利完成一次網(wǎng)絡(luò)通信。

另外,即使分布式系統(tǒng)各個節(jié)點之間的網(wǎng)絡(luò)通信能夠正常進行,其延時也會大于單機操作。

通常我們認為現(xiàn)代計算機體系結(jié)構(gòu)中,單機內(nèi)存訪問的延時在納秒數(shù)量級(通常是10ns),而正常的一次網(wǎng)絡(luò)通信的延遲在0.1~1ms左右(相當于內(nèi)存訪問延時的105倍),如此巨大的延時差別,也會影響到消息的收發(fā)過程,因此消息丟失和消息延遲變得非常普遍。

2、網(wǎng)絡(luò)分區(qū)

當網(wǎng)絡(luò)由于發(fā)生異常情況,導(dǎo)致分布式系統(tǒng)中部分節(jié)點之間的網(wǎng)絡(luò)延時不斷增大,最終導(dǎo)致組成分布式系統(tǒng)的所有節(jié)點中,只有部分節(jié)點之間能夠正常通信,而另一些節(jié)點則不能----我們將這個現(xiàn)象稱為網(wǎng)絡(luò)分區(qū)。

當網(wǎng)絡(luò)分區(qū)出現(xiàn)時,分布式系統(tǒng)會出現(xiàn)局部小集群,在極端情況下,這些局部小集群會獨立完成原本需要整個分布式系統(tǒng)才能完成的功能,包括對數(shù)據(jù)的事物處理,這就對分布式一致性提出了非常大的挑戰(zhàn)。

3、三態(tài)

上面兩點,我們已經(jīng)了解到在分布式環(huán)境下,網(wǎng)絡(luò)可能會出現(xiàn)各式各樣的問題,因此分布式系統(tǒng)的每一次請求與響應(yīng),存在特有的三態(tài)概念,即成功、失敗、超時。

在傳統(tǒng)的單機系統(tǒng)中,應(yīng)用程序在調(diào)用一個函數(shù)之后,能夠得到一個非常明確的響應(yīng):成功或失敗。而在分布式系統(tǒng)中,由于網(wǎng)絡(luò)是不可靠的,雖然在絕大部分情況下,網(wǎng)絡(luò)通信也能夠接受到成功或失敗的響應(yīng),當時當網(wǎng)絡(luò)出現(xiàn)異常的情況下,就可能會出現(xiàn)超時現(xiàn)象,通常有以下兩種情況:

(1)由于網(wǎng)絡(luò)原因,該請求并沒有被成功地發(fā)送到接收方,而是在發(fā)送過程中就發(fā)生了消息丟失現(xiàn)象

(2)該請求成功地被接收方接收后,進行了處理,但是在將響應(yīng)反饋給發(fā)送方的過程中,發(fā)生了消息丟失現(xiàn)象

當出現(xiàn)這樣的超時現(xiàn)象時,網(wǎng)絡(luò)通信的發(fā)起方是無法確定當前請求是否被成功處理的

4、節(jié)點故障

節(jié)點故障則是分布式環(huán)境下另一個比較常見的問題,指的是組成分布式系統(tǒng)的

據(jù)說60%的Java程序員不明白分布式一致性?這次徹底搞懂!

分布式事務(wù)

隨著分布式計算的發(fā)展,事物在分布式計算領(lǐng)域也得到了廣泛的應(yīng)用。

在單機數(shù)據(jù)庫中,我們很容易能夠?qū)崿F(xiàn)一套滿足ACID特性的事物處理系統(tǒng),但在分布式數(shù)據(jù)庫中,數(shù)據(jù)分散在各臺不同的機器上,如何對這些數(shù)據(jù)進行分布式的事物處理具有非常大的挑戰(zhàn)。

分布式事物是指事物的參與者、支持事物的服務(wù)器、資源服務(wù)器以及事物管理器分別位于分布式系統(tǒng)的不同節(jié)點上,通常一個分布式事物中會涉及對多個數(shù)據(jù)源或業(yè)務(wù)系統(tǒng)的操作。

可以設(shè)想一個最典型的分布式事物場景:一個跨銀行的轉(zhuǎn)賬操作涉及調(diào)用兩個異地的銀行服務(wù),其中一個是本地銀行提供的取款服務(wù),另一個則是目標銀行提供的存款服務(wù),這兩個服務(wù)本身是無狀態(tài)并且相互獨立的,共同構(gòu)成了一個完整的分布式事物。

如果從本地銀行取款成功,但是因為某種原因存款服務(wù)失敗了,那么就必須回滾到取款之前的狀態(tài),否則用戶可能會發(fā)現(xiàn)自己的錢不翼而飛了。

從這個例子可以看到,一個分布式事務(wù)可以看做是多個分布式的操作序列組成的,例如上面例子的取款服務(wù)和存款服務(wù),通??梢园堰@一系列分布式的操作序列稱為子事物。

因此,分布式事務(wù)也可以被定義為一種嵌套型的事物,同時也就具有了ACID事物特性。但由于在分布式事務(wù)中,各個子事物的執(zhí)行是分布式的,因此要實現(xiàn)一種能夠保證ACID特性的分布式事物處理系統(tǒng)就顯得格外復(fù)雜。

CAP理論

一個經(jīng)典的分布式系統(tǒng)理論。CAP理論告訴我們:一個分布式系統(tǒng)不可能同時滿足一致性(C:Consistency)、可用性(A:Availability)和分區(qū)容錯性(P:Partition tolerance)這三個基本需求,最多只能同時滿足其中兩項。

1、一致性

在分布式環(huán)境下,一致性是指數(shù)據(jù)在多個副本之間能否保持一致的特性。在一致性的需求下,當一個系統(tǒng)在數(shù)據(jù)一致的狀態(tài)下執(zhí)行更新操作后,應(yīng)該保證系統(tǒng)的數(shù)據(jù)仍然處于一直的狀態(tài)。

對于一個將數(shù)據(jù)副本分布在不同分布式節(jié)點上的系統(tǒng)來說,如果對第一個節(jié)點的數(shù)據(jù)進行了更新操作并且更新成功后,卻沒有使得第二個節(jié)點上的數(shù)據(jù)得到相應(yīng)的更新,于是在對第二個節(jié)點的數(shù)據(jù)進行讀取操作時,獲取的依然是老數(shù)據(jù)(或稱為臟數(shù)據(jù)),這就是典型的分布式數(shù)據(jù)不一致的情況。

在分布式系統(tǒng)中,如果能夠做到針對一個數(shù)據(jù)項的更新操作執(zhí)行成功后,所有的用戶都可以讀取到其最新的值,那么這樣的系統(tǒng)就被認為具有強一致性

2、可用性

可用性是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài),對于用戶的每一個操作請求總是能夠在有限的時間內(nèi)返回結(jié)果。這里的重點是"有限時間內(nèi)"和"返回結(jié)果"。

"有限時間內(nèi)"是指,對于用戶的一個操作請求,系統(tǒng)必須能夠在指定的時間內(nèi)返回對應(yīng)的處理結(jié)果,如果超過了這個時間范圍,那么系統(tǒng)就被認為是不可用的。

另外,"有限的時間內(nèi)"是指系統(tǒng)設(shè)計之初就設(shè)計好的運行指標,通常不同系統(tǒng)之間有很大的不同,無論如何,對于用戶請求,系統(tǒng)必須存在一個合理的響應(yīng)時間,否則用戶便會對系統(tǒng)感到失望。

"返回結(jié)果"是可用性的另一個非常重要的指標,它要求系統(tǒng)在完成對用戶請求的處理后,返回一個正常的響應(yīng)結(jié)果。正常的響應(yīng)結(jié)果通常能夠明確地反映出隊請求的處理結(jié)果,即成功或失敗,而不是一個讓用戶感到困惑的返回結(jié)果。

3、分區(qū)容錯性

分區(qū)容錯性約束了一個分布式系統(tǒng)具有如下特性:分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時候,仍然需要能夠保證對外提供滿足一致性和可用性的服務(wù),除非是整個網(wǎng)絡(luò)環(huán)境都發(fā)生了故障。

網(wǎng)絡(luò)分區(qū)是指在分布式系統(tǒng)中,不同的節(jié)點分布在不同的子網(wǎng)絡(luò)(機房或異地網(wǎng)絡(luò))中,由于一些特殊的原因?qū)е逻@些子網(wǎng)絡(luò)出現(xiàn)網(wǎng)絡(luò)不連通的狀況,但各個子網(wǎng)絡(luò)的內(nèi)部網(wǎng)絡(luò)是正常的,從而導(dǎo)致整個系統(tǒng)的網(wǎng)絡(luò)環(huán)境被切分成了若干個孤立的區(qū)域。

需要注意的是,組成一個分布式系統(tǒng)的每個節(jié)點的加入與退出都可以看作是一個特殊的網(wǎng)絡(luò)分區(qū)。

既然一個分布式系統(tǒng)無法同時滿足一致性、可用性、分區(qū)容錯性三個特點,所以我們就需要拋棄一樣:

據(jù)說60%的Java程序員不明白分布式一致性?這次徹底搞懂!

用一張表格說明一下:

據(jù)說60%的Java程序員不明白分布式一致性?這次徹底搞懂!

需要明確的一點是,對于一個分布式系統(tǒng)而言,分區(qū)容錯性是一個最基本的要求。因為既然是一個分布式系統(tǒng),那么分布式系統(tǒng)中的組件必然需要被部署到不同的節(jié)點,否則也就無所謂分布式系統(tǒng)了,因此必然出現(xiàn)子網(wǎng)絡(luò)。

而對于分布式系統(tǒng)而言,網(wǎng)絡(luò)問題又是一個必定會出現(xiàn)的異常情況,因此分區(qū)容錯性也就成為了一個分布式系統(tǒng)必然需要面對和解決的問題。因此系統(tǒng)架構(gòu)師往往需要把精力花在如何根據(jù)業(yè)務(wù)特點在C(一致性)和A(可用性)之間尋求平衡。

BASE理論

BASE是Basically Available(基本可用)、Soft state(軟狀態(tài))和Eventually consistent(最終一致性)三個短語的縮寫。BASE理論是對CAP中一致性和可用性權(quán)衡的結(jié)果,其來源于對大規(guī)?;ヂ?lián)網(wǎng)系統(tǒng)分布式實踐的總結(jié),是基于CAP定理逐步演化而來的。

BASE理論的核心思想是:即使無法做到強一致性,但每個應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點,采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。接下來看一下BASE中的三要素:

1、基本可用

基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時候,允許損失部分可用性----注意,這絕不等價于系統(tǒng)不可用。比如:

(1)響應(yīng)時間上的損失。正常情況下,一個在線搜索引擎需要在0.5秒之內(nèi)返回給用戶相應(yīng)的查詢結(jié)果,但由于出現(xiàn)故障,查詢結(jié)果的響應(yīng)時間增加了1~2秒

(2)系統(tǒng)功能上的損失:正常情況下,在一個電子商務(wù)網(wǎng)站上進行購物的時候,消費者幾乎能夠順利完成每一筆訂單,但是在一些節(jié)日大促購物高峰的時候,由于消費者的購物行為激增,為了保護購物系統(tǒng)的穩(wěn)定性,部分消費者可能會被引導(dǎo)到一個降級頁面

2、軟狀態(tài)

軟狀態(tài)指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài),并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性,即允許系統(tǒng)在不同節(jié)點的數(shù)據(jù)副本之間進行數(shù)據(jù)同步的過程存在延時

3、最終一致性

最終一致性強調(diào)的是所有的數(shù)據(jù)副本,在經(jīng)過一段時間的同步之后,最終都能夠達到一個一致的狀態(tài)。因此,最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致,而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性。

總的來說,BASE理論面向的是大型高可用可擴展的分布式系統(tǒng),和傳統(tǒng)的事物ACID特性是相反的,它完全不同于ACID的強一致性模型,而是通過犧牲強一致性來獲得可用性,并允許數(shù)據(jù)在一段時間內(nèi)是不一致的,但最終達到一致狀態(tài)。

但同時,在實際的分布式場景中,不同業(yè)務(wù)單元和組件對數(shù)據(jù)一致性的要求是不同的,因此在具體的分布式系統(tǒng)架構(gòu)設(shè)計過程中,ACID特性和BASE理論往往又會結(jié)合在一起。

最后

歡迎大家一起交流,喜歡文章記得點個贊喲,感謝支持!

當前題目:據(jù)說60%的Java程序員不明白分布式一致性?這次徹底搞懂!
當前路徑:http://muchs.cn/article12/jchigc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供標簽優(yōu)化、定制開發(fā)營銷型網(wǎng)站建設(shè)、網(wǎng)站收錄、網(wǎng)站建設(shè)、動態(tài)網(wǎng)站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)

小程序開發(fā)