1. 程式人生 > 其它 >base cap 分散式_什麼是分散式事務、CAP、BASE 理論?

base cap 分散式_什麼是分散式事務、CAP、BASE 理論?

技術標籤:base cap 分散式

什麼是分散式事務?

介紹這個之前,先來了解一下這幾個問題

  1. 什麼是事務?
  2. 什麼是本地事務?
  3. 什麼是分散式?
  4. 什麼是分散式事務?

什麼是事務?

完成某件事情,可能有多個參與者需要執行多個步驟,最終多個步驟要麼全部成功,要麼全部失敗。

舉個例子:微信上A給B轉賬100元,A賬戶減少100,B賬戶增加100,這就是一個事務,這個操作中要麼都成功,要麼都失敗。

事務的場景有很多,參與者也是多種多樣

  1. 使用者註冊成功傳送郵件,包含2個操作:db中插入使用者資訊,給使用者傳送郵件,主要的2個參與者:db、郵件伺服器
  2. 使用支付寶充值話費,包含2個操作:支付寶賬戶資金減少,手機餘額增加,主要的2個參與者:支付寶賬戶、手機號服務商賬戶

事務的參與者是多種多樣的,不過本文我們主要以db中的事務來做說明。

什麼是本地事務?

本地事務,通俗點理解:即事務中所有操作發生在同一個資料庫中的情況。

比如A給B轉賬,A和B的賬戶位於同一個資料庫中。

通常我們用的都是關係型資料庫,比如:MySQL、Oracle、SQL Server,這些資料庫預設情況,這些db已經實現了事務的功能,即在一個db中執行一個事務操作,db本身就可以確保這個事務的正確性,而不需要我們自己去考慮如何確保事務的正確性。

資料庫事務的4大特性

一致性(Consistency)

事務操作之後的結果和期望的結果是一致的,A給B轉賬100,事務結束之後,看到A的賬戶應該減少100,B的賬戶應該增加100,不會出現其他情況

原子性(Atomicity)

事務的整個過程如原子操作一樣,最終要麼全部成功,或者全部失敗,這個原子性是從最終結果來看的,從最終結果來看這個過程是不可分割的。

隔離性(Isolation)

一個事務的執行不能被其他事務干擾。即一個事務內部的操作及使用的資料對併發的其他事務是隔離的,併發執行的各個事務之間不能互相干擾。

永續性(Durability)

一個事務一旦提交,他對資料庫中資料的改變就應該是永久性的。當事務提交之後,資料會持久化到硬碟,修改是永久性的。

什麼是分散式?

完成某件事情有多個參與者,多個參與者分佈在不同的機器中,這些機器之間通過網路或者其他方式進行通訊。

比如使用工行卡給支付寶充值,工行卡的賬戶位於工商銀行的db中,而支付寶賬戶位於支付寶的db中,2個db位於不同的地方。

什麼是分散式事務?

分散式、事務這2個概念大家都理解了,那麼分散式事務很容易理解了:事務的多個參與者分佈在不同的地方。

單個db中我們很容易確保事務的正確性,但是當事務的參與者位於多個db中的時候,如何確保事務的正確性呢?

比如:A給B轉賬,A位於DB1中,B位於DB2中

step1.通過網路,給DB1傳送指令:給A賬戶減少100
step2.通過網路,給DB2傳送指令:給B賬戶增加100

step1成功之後,執行step2的時,網路出現故障,導致step2執行失敗,最終:A減少了100,B卻沒有增加100,最終的結果和期望的結果不一致,導致了事務的失敗。

在介紹分散式事務的解決方案之前,我們需要先了解另外2個概念:CAP和Base理論,這2個理論為分散式事務的解決提供了依據。

CAP理論

理解CAP概念

CAP是 Consistency、Availability、Partition tolerance三個詞語的縮寫,分別表示一致性、可用性、分割槽容忍性。

下邊我們分別來解釋:

為了方便對CAP理論的理解,我們結合電商系統中的一些業務場景來理解CAP。

如下圖,是商品資訊管理的執行流程:

70c0a1c6cee590772cdaddc83cfd0384.png

整體執行流程如下:

1、商品服務請求主資料庫寫入商品資訊(新增商品、修改商品、刪除商品)

2、主資料庫向商品服務響應寫入成功。

3、商品服務請求從資料庫讀取商品資訊。

C - Consistency

一致性是指寫操作後的讀操作可以讀取到最新的資料狀態,當資料分佈在多個節點上,從任意結點讀取到的資料都是最新的狀態。

上圖中,商品資訊的讀寫要滿足一致性就是要實現如下目標:

1、商品服務寫入主資料庫成功,則向從資料庫查詢新資料也成功。

2、商品服務寫入主資料庫失敗,則向從資料庫查詢新資料也失敗。

如何實現一致性?

1、寫入主資料庫後要將資料同步到從資料庫。

2、寫入主資料庫後,在向從資料庫同步期間要將從資料庫鎖定,待同步完成後再釋放鎖,以免在新資料寫入從庫的過程中,客戶端向從資料庫查詢到舊的資料。

分散式系統一致性的特點:

1、由於存在資料同步的過程,寫操作的響應會有一定的延遲。

2、為了保證資料一致性會對資源暫時鎖定,待資料同步完成釋放鎖定資源。

3、如果請求資料同步失敗的結點則會返回錯誤資訊,一定不會返回舊資料。

A - Availability

可用性是指任何事務操作都可以得到響應結果,且不會出現響應超時或響應錯誤。

上圖中,商品資訊讀取滿足可用性就是要實現如下目標:

1、從資料庫接收到資料查詢的請求則立即能夠響應資料查詢結果。

2、從資料庫不允許出現響應超時或響應錯誤。

如何實現可用性?

1、寫入主資料庫後要將資料同步到從資料庫。

2、由於要保證從資料庫的可用性,不可將從資料庫中的資源進行鎖定。

3、即使資料還沒有同步過來,從資料庫也要返回要查詢的資料,哪怕是舊資料,如果連舊資料也沒有則可以按照約定返回一個預設資訊,但不能返回錯誤或響應超時。

分散式系統可用性的特點:

1、 所有請求都有響應,且不會出現響應超時或響應錯誤。

P - Partition tolerance

通常分散式系統的各個結點部署在不同的子網,這就是網路分割槽,不可避免的會出現由於網路問題而導致結點之間通訊失敗,此時仍可對外提供服務,這叫分割槽容忍性。

上圖中,商品資訊讀寫滿足分割槽容忍性就是要實現如下目標:

1、主資料庫向從資料庫同步資料失敗不影響讀寫操作。

2、其一個結點掛掉不影響另一個結點對外提供服務。

如何實現分割槽容忍性?

1、儘量使用非同步取代同步操作,例如使用非同步方式將資料從主資料庫同步到從資料,這樣結點之間能有效的實現鬆耦合。

2、新增從資料庫結點,其中一個從結點掛掉其它從結點提供服務。

分散式分割槽容忍性的特點:

1、分割槽容忍性分是布式系統具備的基本能力

CAP組合方式

1、上邊商品管理的例子是否同時具備 CAP呢?

在所有分散式事務場景中不會同時具備CAP三個特性,因為在具備了P的前提下C和A是不能共存的。

比如:

下圖滿足了P即表示實現分割槽容忍:

70c0a1c6cee590772cdaddc83cfd0384.png

本圖分割槽容忍的含義是:

1)主資料庫通過網路向從資料同步資料,可以認為主從資料庫部署在不同的分割槽,通過網路進行互動。

2)當主資料庫和從資料庫之間的網路出現問題不影響主資料庫和從資料庫對外提供服務。

3)其一個結點掛掉不影響另一個結點對外提供服務。

如果要實現C則必須保證資料一致性,在資料同步的時候為防止向從資料庫查詢不一致的資料則需要將從資料庫資料鎖定,待同步完成後解鎖,如果同步失敗從資料庫要返回錯誤資訊或超時資訊。

如果要實現A則必須保證資料可用性,不管任何時候都可以向從資料查詢資料,則不會響應超時或返回錯誤資訊。

通過分析發現在滿足P的前提下C和A存在矛盾性,如下:

主從庫之間網路出現故障的情況下,主庫的資料無法同步給從庫,為了確保外面看到資料是一致的,此時從庫不能讓外部訪問,只能讓主庫對外提供服務,從庫失去了可用性。

主從庫之間網路出現故障的情況下,主庫的資料無法同步給從庫,此時2個庫資料是不一致的,如果此允許2個庫都可以對外提供服務(可用性),那麼2個庫訪問的資料是不一致的。

所以CAP無法同時滿足,通常情況下,在分散式系統中,多個節點分在不同的網路節點中,網路故障是無法完全避免的,所以P是肯定會存在的,此時我們需要考慮P和另外2個如何組合的問題。

2、CAP有哪些組合方式呢?

所以在生產中對分散式事務處理時要根據需求來確定滿足CAP的哪兩個方面。

1)AP:

放棄一致性,追求分割槽容忍性和可用性。這是很多分散式系統設計時的選擇。

例如:

上邊的商品管理,完全可以實現AP,前提是隻要使用者可以接受所查詢的到資料在一定時間內不是最新的即可。

通常實現AP都會保證最終一致性,後面講的BASE理論就是根據AP來擴充套件的,一些業務場景 比如:訂單退款,今日退款成功,明日賬戶到賬,只要使用者可以接受在一定時間內到賬即可。

2)CP:

放棄可用性,追求一致性和分割槽容錯性,我們的zookeeper其實就是追求的強一致。

3)CA:

放棄分割槽容忍性,即不進行分割槽,不考慮由於網路不通或結點掛掉的問題,則可以實現一致性和可用性。

那麼系統將不是一個標準的分散式系統,我們最常用的關係型資料就滿足了CA。

上邊的商品管理,如果要實現CA則架構如下:

1e6eee08abdf4eb1d22cd4422096009c.png

主資料庫和從資料庫中間不再進行資料同步,資料庫可以響應每次的查詢請求,通過事務隔離級別實現每個查詢請求都可以返回最新的資料。

總結

通過上面我們已經學習了CAP理論的相關知識,CAP是一個已經被證實的理論:一個分散式系統最多隻能同時滿足一致性(Consistency)、可用性(Availability)和分割槽容忍性(Partition tolerance)這三項中的兩項。它可以作為我們進行架構設計、技術選型的考量標準。對於多數大型網際網路應用的場景,結點眾多、部署分散,而且現在的叢集規模越來越大,所以節點故障、網路故障是常態,而且要保證服務可用性達到N個9(99.99..%),並要達到良好的響應效能來提高使用者體驗,因此一般都會做出如下選擇:保證P和A,捨棄C強一致,保證最終一致性

Base理論

理解強一致性和最終一致性

CAP理論告訴我們一個分散式系統最多隻能同時滿足一致性(Consistency)、可用性(Availability)和分割槽容忍性(Partition tolerance)這三項中的兩項,其中AP在實際應用中較多,AP即捨棄一致性,保證可用性和分割槽容忍性,但是在實際生產中很多場景都要實現一致性,比如前邊我們舉的例子主資料庫向從資料庫同步資料,即使不要一致性,但是最終也要將資料同步成功來保證資料一致,這種一致性和CAP中的一致性不同,CAP中的一致性要求在任何時間查詢每個結點資料都必須一致,它強調的是強一致性,但是最終一致性是允許可以在一段時間內每個結點的資料不一致,但是經過一段時間每個結點的資料必須一致,它強調的是最終資料的一致性。

Base理論介紹

BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫。BASE理論是對CAP中AP的一個擴充套件,通過犧牲強一致性來獲得可用性,當出現故障允許部分不可用但要保證核心功能可用,允許資料在一段時間內是不一致的,但最終達到一致狀態。滿足BASE理論的事務,我們稱之為“柔性事務”。

基本可用

分散式系統在出現故障時,允許損失部分可用功能,保證核心功能可用。如,電商網站交易付款出現問題了,商品依然可以正常瀏覽。

軟狀態

由於不要求強一致性,所以BASE允許系統中存在中間狀態(也叫軟狀態),這個狀態不影響系統可用性,如訂單的"支付中"、“資料同步中”等狀態,待資料最終一致後狀態改為“成功”狀態。

最終一致

最終一致是指經過一段時間後,所有節點資料都將會達到一致。如訂單的"支付中"狀態,最終會變為“支付成功”或者"支付失敗",使訂單狀態與實際交易結果達成一致,但需要一定時間的延遲、等待

總結

今天講的幾個概念大家消化一下,歡迎留言交流,下一篇介紹分散式事務中常見的一些解決方案。

後面會分享更多架構相關的文章,歡迎關注我!

e720c6605da1f8c8962673a45580e145.png