摘要:當發(fā)生網(wǎng)絡分區(qū)時,你將面臨兩個選擇如果堅持保持各節(jié)點之間的數(shù)據(jù)一致性選擇,你需要等待網(wǎng)絡分區(qū)恢復后,將數(shù)據(jù)復制完成,才可以向外部提供服務。期間發(fā)生網(wǎng)絡分區(qū)將不能對外提供服務,因為它保證不了數(shù)據(jù)一致性。則強調(diào)是高可用,對數(shù)據(jù)一致性要求更低。
這篇文章著重點不在于科普,畢竟關(guān)于CAP、BASE的理論的文章,網(wǎng)上很多。所以本文科普篇幅盡量?。ㄖ话拍蠲枋觯V饕獜膸讉€側(cè)面的問題來描述CAP,進而描述ACID、BASE理念。然后加入一點點調(diào)料,如何動態(tài)的切換一致性強度。
本文通過以下幾個問題,從側(cè)面描述。文中個人觀點較多,看官理性對待。
CAP定理科普
CAP定理,指的是在一個分布式系統(tǒng)中,一致性(Consistency)、可用性(Availability)、分區(qū)容錯性(Partition tolerance)。這三個要素最多只能同時實現(xiàn)兩點,不可能三者兼顧。
一致性(C):這里是指強一致性。在分布式系統(tǒng)中的所有數(shù)據(jù)備份,在同一時刻是否同樣的值。并不是指整個系統(tǒng)能提供最新的一致的數(shù)據(jù)。
可用性(A):這里是指100%可用性??蛻舳藷o論訪問到哪個沒有宕機的節(jié)點上,都能在有限的時間內(nèi)返回結(jié)果,并不是指整個系統(tǒng)處于可用狀態(tài)。
分區(qū)容錯性(P):網(wǎng)絡中允許丟失一個節(jié)點發(fā)給另一個節(jié)點的任意多的消息,即對網(wǎng)絡分區(qū)的容忍。在發(fā)生網(wǎng)絡分區(qū)時,能繼續(xù)保持可用性或者一致性。一個系統(tǒng)要求在運行過程中不能發(fā)生網(wǎng)絡分區(qū),那么這個系統(tǒng)就不具備分區(qū)容錯性。
CAP定理中的可用性和一致性與用戶感知的可用性和一致性不是一個概念。我們追求的應該是用戶感知的可用性,CAP中可用性和一致性給我們只是起到指導性的作用。
2017 年,Google 公司的第一代 Spanner 系統(tǒng)已經(jīng)誕生。Brewer 寫了一篇文章講述了 Google 公司的 Spanner 系統(tǒng),并且近一步闡述了按照 CAP 定理 Spanner 是一個什么樣特性的系統(tǒng)。在文中,Brewer 指出 Spanner 系統(tǒng)說是"實際上的 CA"(effectively CA)系統(tǒng)。從架構(gòu)上來講,Spanner 是一個 CP 系統(tǒng),也就是說當出現(xiàn)網(wǎng)絡分區(qū)時,Spanner 選擇的是保證數(shù)據(jù)的一致性,放棄可用性的。但實際上,Spanner 是具有非常高可用性效果的一個系統(tǒng),從架構(gòu)上 Spanner 沒有達到 CAP 定理要求的那種完全可用性,但是也達到非常高的可用性,由于采用多副本的設計,個別副本出現(xiàn)網(wǎng)絡分區(qū),并不影響用戶能感知到的可用性。按 CAP 定理的定義,當這些個別副本出現(xiàn)網(wǎng)絡分區(qū)時,這些節(jié)點是不可用的,也就是系統(tǒng)沒有達到完全可用性。但是此時的用戶請求是可以被其他副本服務的,此時服務是可用的,也就是說用戶仍然感知到 Spanner 是可用的。所以說用戶感知的可用性和 CAP 定理中的可用性不是一個概念。我們追求的應該是用戶感知的可用性。
BASE定理科普
BASE是對一致性和可用性權(quán)衡所得的結(jié)果。其核心思想是:在某些場景中,無需做到強一致性,以保證系統(tǒng)的可用性,同時每個應用可以采用適當?shù)姆绞绞瓜到y(tǒng)數(shù)據(jù)達到最終一致性。
BASE分別是指:Basically Available, Soft State, Eventual Consistency
基本可用(Basically Available):分布式系統(tǒng)在出現(xiàn)故障的時候,允許損失部分可用性,但不等于系統(tǒng)不可用。例如:響應時間的損失,功能上降級。
軟狀態(tài)(Soft State):允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài),并認為該狀態(tài)不會影響系統(tǒng)整體可用性。即允許節(jié)點之間數(shù)據(jù)同步存在延時
最終一致性(Eventually Consistent):本質(zhì)是指系統(tǒng)需要使數(shù)據(jù)最終達到一致性,而不需要實時使數(shù)據(jù)達到一致性
ACID科普
對于ACID中一致性描述,可能理解都不一樣,需要先統(tǒng)一下概念。
ACID中的C(一致性)的定義是:如果事務執(zhí)行前數(shù)據(jù)庫處于一致狀態(tài),那么當事務結(jié)束的時候,數(shù)據(jù)庫也會處于一致性狀態(tài)。這個一致性狀態(tài)包含兩層意思:
第一層意思是指,數(shù)據(jù)庫內(nèi)部的完整性,包含實體完整性、域完整性、參照完整性、用戶自定義完整性。使用外鍵、檢查約束等,來保證事務執(zhí)行中不會產(chǎn)生違背數(shù)據(jù)完整性的數(shù)據(jù)。例如:使用唯一約束的列不會出現(xiàn)兩個一樣的值。A transaction must preserve database consistency - if a transaction is run atomically in isolation starting from a consistent database, the database must again be consistent at the end of the transaction.
第二層意思是對開發(fā)者的要求,數(shù)據(jù)庫中的每一行和每個值必須與其所描述的現(xiàn)實保持一致。例如:銀行轉(zhuǎn)賬,不能只一方扣錢或者一方加錢,我們的代碼應該是,一方加錢一方扣錢。Ensuring consistency for an individual transaction is the responsibility of the application programmer who codes the transaction.
為什么CAP三者不可兼得?
在分布式系統(tǒng)中,各個組建必然部署在不同的節(jié)點上,因此必然出現(xiàn)子網(wǎng)絡,同時網(wǎng)絡本身又是不可靠的,一定存在延遲和數(shù)據(jù)丟失,即網(wǎng)絡分區(qū)是必然存在的。所以P(分區(qū)容錯性)是分布式系統(tǒng)必須要面對和解決的問題(你無法要求在永遠不發(fā)生網(wǎng)絡分區(qū)的環(huán)境下運行分布式系統(tǒng))。
因此CAP三者不可兼得,變成如何在C(一致性)、A(可用性)二者進行抉擇,可以舉個例子來說明:在分布式環(huán)境中,為了確保系統(tǒng)可用性,通常會采用將數(shù)據(jù)復制到多個備份節(jié)點,而復制的過程需要通過網(wǎng)絡交互。當發(fā)生網(wǎng)絡分區(qū)時,你將面臨兩個選擇:
如果堅持保持各節(jié)點之間的數(shù)據(jù)一致性(選擇C),你需要等待網(wǎng)絡分區(qū)恢復后,將數(shù)據(jù)復制完成,才可以向外部提供服務。期間發(fā)生網(wǎng)絡分區(qū)將不能對外提供服務,因為它保證不了數(shù)據(jù)一致性。
如果選擇可用性(選擇A),發(fā)生網(wǎng)絡分區(qū)的節(jié)點,依然需要向外提供服務。但是由于網(wǎng)絡分區(qū),它同步不了最新的數(shù)據(jù),所以它返回數(shù)據(jù),可能不是最新的(與其他節(jié)點不一致的)數(shù)據(jù)。
這里需要強調(diào)一句,CAP三者不可兼得,僅僅是指在發(fā)生網(wǎng)絡分區(qū)情況下,我們才需要在A和C之間進行抉擇,選擇保證數(shù)據(jù)一致還是服務可用。而集群正常運行時,A和C是都可以保證的。
CP架構(gòu)在當發(fā)生網(wǎng)絡分區(qū)時,為了保證返回給客戶端數(shù)據(jù)準確性,為了不破壞一致性,可能會因為無法響應最新數(shù)據(jù),而拒絕響應。在網(wǎng)絡分區(qū)恢復后,完成數(shù)據(jù)同步,才可處理客戶端請求。
AP架構(gòu)在發(fā)生網(wǎng)絡分區(qū)時,發(fā)生分區(qū)的節(jié)點不需要等待數(shù)據(jù)完成同步,便可處理客戶端請求,將盡可能的給用戶返回相對新的數(shù)據(jù)。在網(wǎng)絡分區(qū)恢復后,完成數(shù)據(jù)同步。
ACID與CP、BASE與AP,它們的關(guān)聯(lián)關(guān)系?
根據(jù)上一小節(jié)C、A二者不可兼得的原因,我們可以總結(jié)AP和CP架構(gòu)的特性??梢园l(fā)現(xiàn)CP、AP兩者其實是對ACID、BASE的延伸。是在發(fā)生網(wǎng)絡分區(qū)情況下ACID、BASE的表現(xiàn)。
CP和ACID都是為了保證數(shù)據(jù)準確性(兩者對準確性定義不同,參考前文科普)。但是兩者解決的問題不一樣:CP描述的是在發(fā)生網(wǎng)絡分區(qū)時,保證數(shù)據(jù)準確性。ACID解決的是多個事務并發(fā)下,保證數(shù)據(jù)準確性。
AP和BASE都是對可用性的研究,BASE要求的只是基本可用,而AP對一致性的要求更低,所以能保證的可用性更高。
ACID與CP區(qū)別
ACID解決的問題是數(shù)據(jù)庫系統(tǒng)中并發(fā)執(zhí)行多個事務時的問題,是數(shù)據(jù)庫領(lǐng)域的傳統(tǒng)問題。那么多個事務并發(fā)會存在哪些問題?
臟讀:事務T1讀取了T2更改的x,但是T2在實際存儲數(shù)據(jù)時可能出錯回滾了,這時T1讀取的實際是無效的數(shù)據(jù),這種情況下就是臟讀
不可重復讀:是說在T1讀取x時,由于中間T2更改了x,所以T1前后兩次讀取的x值不相同,這就是所謂的不可重復讀
幻讀:在T1讀取符合某個條件的所有記錄時,T2增加了一條符合該條件的記錄,這就導致T1執(zhí)行過程中前后讀取的記錄可能不一致,即T2之后讀取時會多出一條記錄。
為了解決這些問題,事務提出四種隔離級別來規(guī)避上述問題。而解決的就是ACID中的C(一致性),所以ACID中的C(一致性)可以理解為不出現(xiàn)臟讀、幻讀、不可重復讀的問題??梢园阉Q為“內(nèi)部一致性”,解決的是數(shù)據(jù)庫內(nèi)部的一致性問題。
CP中的C(一致性),相對好理解,我把它理解為“外部一致性”。就分布式系統(tǒng)而言的,針對客戶端的請求,無論訪問那個節(jié)點,都能獲得最新的相同的值。
BASE與AP區(qū)別
BASE強調(diào)的是基本可用,允許損失部分可用性。這里的損失是指:
響應時間上的損失:在發(fā)生故障時,允許在限定時間之外給用戶響應。搜索引擎正常工作0.5秒內(nèi)給用戶返回數(shù)據(jù)。在部分機房故障后,查詢時間增加到1-2秒。
功能上的損失:在請求高峰時,可以選擇一部分請求降級。
AP則強調(diào)是高可用,對數(shù)據(jù)一致性要求更低。eureka作為AP系統(tǒng)的代表,在發(fā)生網(wǎng)絡分區(qū)時,eureka會移除注冊列表中長時間沒有心跳的服務,但是當丟失過多客戶端時,該節(jié)點會進入自我保護,將不會移除過期的服務,并同時接收新服務注冊,但不會同步到其他節(jié)點。在該種模式下,eureka集群剩下最后一個節(jié)點,也可以向外提供服務。
eureka屬于AP系統(tǒng)嗎?它明明沒有放棄一致性???
描述AP和CP時,通常都會以eureka和zookeeper來具體。eureka是AP的代表作,zookeeper則是CP的代表作。二者之所以這樣歸類,是因為:
eureka各節(jié)點互相獨立、平等的,各節(jié)點都提供查詢和注冊服務(讀、寫請求)。當發(fā)生網(wǎng)絡分區(qū),eureka各節(jié)點依舊可以接收和注冊服務。并且當丟失過多客戶端時,節(jié)點會進入自我保護(接收新服務注冊、不刪除過期服務)。在該種模式下,eureka集群剩下最后一個節(jié)點,也可以向外提供服務。盡管向外提供的數(shù)據(jù)可能是過期的數(shù)據(jù)。
zookeeper采用的過半原則,由leader處理寫請求。當發(fā)生網(wǎng)絡分區(qū)時,leader由于丟失過半的follower,從而處理不了客戶端的請求,需要重新選舉新leader,期間服務將不可用。糟糕的是,如果集群中沒有過半的節(jié)點存活,將選舉不出新leader,服務將一直處于不可用狀態(tài)。
回答eureka沒有放棄一致性的問題,還得回顧A、C之間的抉擇。這二者需要二選一的情況下,一定是發(fā)生了網(wǎng)絡分區(qū)的情況。eureka集群正常運行時,各節(jié)點之間可以正常通訊、保持心跳、復制數(shù)據(jù),以此保持數(shù)據(jù)的一致性。但發(fā)生網(wǎng)絡分區(qū)時,eureka確實選擇了可用性,而放棄了一致性。
NWR
NWR是一種在分布式存儲系統(tǒng)中用于控制一致性級別的一種策略。這個三個字母分別代表著:
N:分布式系統(tǒng)中,一個有多少個副本數(shù)據(jù)
W:處理一次寫請求,需要更新多少個副本數(shù)據(jù)
R:處理一次讀請求,需要讀取多少個副本數(shù)據(jù)
NWR分別設置不同的值時,將會產(chǎn)生不同的一致性效果。
W+R>N,整個系統(tǒng)對于客戶端的請求能保證強一致性。因為寫請求和讀請求一定存在一個相交的副本,讀取的時候返回該副本的數(shù)據(jù)即可。
W+R<=N,整個系統(tǒng)對于客戶端的請求則不能保證強一致性。
基于NWR的性質(zhì),我們可以動態(tài)的調(diào)節(jié)系統(tǒng)的一致性效果。還可以根據(jù)業(yè)務場景動態(tài)調(diào)整響應速度。以5節(jié)點集群為例,在保證強一致性的情況下,需要提高讀請求的效率,則可以設置R=2、W=4或者R=1、W=5。當需要提高寫請求效率時,則可以設置W=2、R=4或者W=1、R=5。
W、R的大小,直接影響其對應的處理效率。主要注意,讀寫請求的效率取決于最慢的副本處理速度。
建議閱讀
CAP爭論及歷史:https://blog.csdn.net/chen77716/article/details/30635543
CAP,ACID,我們能做什么:http://hcoona.github.io/Tips/CAP-ACID-what-can-we-do/
理解數(shù)據(jù)庫的事務,ACID,CAP和一致性:https://www.jianshu.com/p/2c30d1fe5c4e
nosql不應該放棄一致性:https://www.infoq.cn/article/rhzs0KI2G*Y2r9PMdeNv
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/125962.html
摘要:對于設計分布式系統(tǒng)來說不僅僅是分布式事務的架構(gòu)師來說,就是你的入門理論。分布式事務解決方案有了上面的理論基礎后,這里介紹開始介紹幾種常見的分布式事務的解決方案。是否真的要分布式事務在說方案之前,首先你一 事務的具體定義:事務提供一種機制將一個活動涉及的所有操作納入到一個不可分割的執(zhí)行單元,組成事務的所有操作只有在所有操作均能正常執(zhí)行的情況下方能提交,只要其中任一操作執(zhí)行失敗,都將導致整...
摘要:分布式事務技術(shù)理論定理。接下來我們看看分布式事務有哪幾種實現(xiàn)方案?;趨f(xié)調(diào)者與參與者的思想設定,分別提出了與實現(xiàn)分布式事務。 這次使用分布式事務框架過程中了學習了一些分布式事務知識,所以本文我們就來聊聊分布式事務那些事。首先我們先回顧下什么是事務。 事務 什么是事務?這個作為后端開發(fā),日常開發(fā)中只要與數(shù)據(jù)庫有交互,肯定就會使用過事務?,F(xiàn)在摘抄一段wiki的解釋,解釋下什么是事務。 是數(shù)...
閱讀 3539·2023-04-25 20:09
閱讀 3740·2022-06-28 19:00
閱讀 3061·2022-06-28 19:00
閱讀 3082·2022-06-28 19:00
閱讀 3176·2022-06-28 19:00
閱讀 2881·2022-06-28 19:00
閱讀 3049·2022-06-28 19:00
閱讀 2638·2022-06-28 19:00