首頁 > 軟體

淺談Java實現分散式事務的三種方案

2021-06-11 19:00:09

一、問題描述

使用者支付完成會將支付狀態及訂單狀態儲存在訂單資料庫中,由訂單服務去維護訂單資料庫。由庫存服務去維護庫存資料庫的資訊。下圖是系統結構圖:

如何實現兩個分散式服務(訂單服務、庫存服務)共同完成一件事即訂單支付成功自動減庫存,這裡的關鍵是如何保證兩個分散式服務的事務的一致性。

嘗試解決上邊的需求,在訂單服務中遠端呼叫減庫存介面,虛擬碼如下:

訂單支付結果通知方法{

​ 更新支付表中支付狀態為「成功」。
​ 遠端呼叫減庫存介面減庫存。

上邊的邏輯說明:

1、更新支付表狀態為本地資料庫操作。
2、遠端呼叫減庫存介面為網路遠端呼叫請求。
3、為儲存事務上邊兩步操作由spring控制事務,當遇到Exception異常則回滾本地資料庫操作。

問題如下:

1、如果更新支付表失敗則丟擲異常,不再執行遠端呼叫,此設想沒有問題。
2、如果更新支付表成功,網路遠端呼叫超時會拉長本地資料庫事務時間,影響資料庫效能。
3、如果更新支付表成功,遠端呼叫減庫存成功(減庫存資料庫commit成功),最後更新支付表commit失敗,此時出現操作不一致。

上邊的問題涉及到分散式事務控制。

二、分散式事務

2.1、什麼是分散式系統

部署在不同結點上的系統通過網路互動來完成協同工作的系統。

比如:充值加積分的業務,使用者在充值系統向自己的賬戶充錢,在積分系統中自己積分相應的增加。充值系統和積分系統是兩個不同的系統,一次充值加積分的業務就需要這兩個系統協同工作來完成。

2.2、什麼是事務

事務是指由一組操作組成的一個工作單元,這個工作單元具有原子性(atomicity)、一致性(consistency)、隔離性(isolation)和永續性(durability)。

原子性:執行單元中的操作要麼全部執行成功,要麼全部失敗。如果有一部分成功一部分失敗那麼成功的操作要全部回滾到執行前的狀態。

一致性:執行一次事務會使用資料從一個正確的狀態轉換到另一個正確的狀態,執行前後資料都是完整的。

隔離性:在該事務執行的過程中,任何資料的改變只存在於該事務之中,對外界沒有影響,事務與事務之間是完全的隔離的。只有事務提交後其它事務才可以查詢到最新的資料。

永續性:事務完成後對資料的改變會永久性的儲存起來,即使發生斷電宕機資料依然在。

2.3、什麼是本地事務

本地事務就是用關聯式資料庫來控制事務,關聯式資料庫通常都具有ACID特性,傳統的單體應用通常會將資料全部儲存在一個資料庫中,會藉助關聯式資料庫來完成事務控制。

2.4、什麼是分散式事務

在分散式系統中一次操作由多個系統協同完成,這種一次事務操作涉及多個系統通過網路協同完成的過程稱為分散式事務。這裡強調的是多個系統通過網路協同完成一個事務的過程,並不強調多個系統存取了不同的資料庫,即使多個系統存取的是同一個資料庫也是分散式事務,如下圖:

另外一種分散式事務的表現是,一個應用程式使用了多個資料來源連線了不同的資料庫,當一次事務需要操作多個資料來源,此時也屬於分散式事務,當系統作了資料庫拆分後會出現此種情況。

分散式事務有哪些應用場景:

電商系統中的下單扣庫存

電商系統中,訂單系統和庫存系統是兩個系統,一次下單的操作由兩個系統協同完成

2)金融系統中的銀行卡充值
在金融系統中通過銀行卡向平臺充值需要通過銀行系統和金融系統協同完成。

3)教育系統中下單選課業務
線上教育系統中,使用者購買課程,下單支付成功後學生選課成功,此事務由訂單系統和選課系統協同完成。

4) SNS系統的訊息傳送
在社交系統中傳送站內訊息同時傳送手機簡訊,一次訊息傳送由站內訊息系統和手機通訊系統協同完成。

三、如何進行分散式事務控制

3.1、CAP理論

CAP理論是分散式事務處理的理論基礎:分散式系統在設計時只能在一致性(Consistency)、可用性(Availability)、分割區容忍性(PartitionTolerance)中滿足兩種,無法兼顧三種。

一致性(Consistency):服務A、B、C三個結點都儲存了使用者資料, 三個結點的資料需要保持同一時刻資料一致性。

可用性(Availability):服務A、B、C三個結點,其中一個結點宕機不影響整個叢集對外提供服務,如果只有服務A結點,當服務A宕機整個系統將無法提供服務,增加服務B、C是為了保證系統的可用性。

分割區容忍性(Partition Tolerance):分割區容忍性就是允許系統通過網路協同工作,分割區容忍性要解決由於網路分割區導致資料的不完整及無法存取等問題。

分散式系統不可避免的出現了多個系統通過網路協同工作的場景,結點之間難免會出現網路中斷、網延延遲等現象,這種現象一旦出現就導致資料被分散在不同的結點上,這就是網路分割區

3.2、分散式系統如果兼顧CAP

在保證分割區容忍性的前提下一致性和可用性無法兼顧,如果要提高系統的可用性就要增加多個結點,如果要保證資料的一致性就要實現每個結點的資料一致,結點越多可用性越好,但是資料一致性越差。

所以,在進行分散式系統設計時,同時滿足「一致性」、「可用性」和「分割區容忍性」三者是幾乎不可能的。

CAP有哪些組合方式?

1.CA:放棄分割區容忍性,加強一致性和可用性,關聯式資料庫按照CA進行設計。

2.AP:放棄一致性,加強可用性和分割區容忍性,追求最終一致性,很多NoSQL資料庫按照AP進行設計。
說明:這裡放棄一致性是指放棄強一致性,強一致性就是寫入成功立刻要查詢出最新資料。追求最終一致性是指允許暫時的資料不一致,只要最終在使用者接受的時間內資料 一致即可。

3.CP:放棄可用性,加強一致性和分割區容忍性,一些強一致性要求的系統按CP進行設計,比如跨行轉賬,一次轉賬請求要等待雙方銀行系統都完成整個事務才算完成。說明:由於網路問題的存在CP系統可能會出現待等待超時,如果沒有處理超時問題則整理系統會出現阻塞。

總結

​ 在分散式系統設計中AP的應用較多,即保證分割區容忍性和可用性,犧牲資料的強一致性(寫操作後立刻讀取到最新資料),保證資料最終一致性。比如:訂單退款,今日退款成功,明日賬戶到賬,只要在預定的使用者可以接受的時間內退款事務走完即可。

四、分散式事務一致性解決方案

4.1、兩階段提交協定(2PC)

​ 為解決分散式系統的資料一致性問題出現了兩階段提交協定(2 Phase Commitment Protocol),兩階段提交由協調者和參與者組成,共經過兩個階段和三個操作,部分關聯式資料庫如Oracle、MySQL支援兩階段提交協定,本節講解關聯式資料庫兩階段提交協定。

參考:

2PC:https://en.wikipedia.org/wiki/Two-phase_commit_protocol

2PC協定流程圖

1)第一階段:準備階段(prepare)
協調者通知參與者準備提交訂單,參與者開始投票。
參與者完成準備工作向協調者回應Yes|NO。

2)第二階段:提交(commit)/回滾(rollback)階段
協調者根據參與者的投票結果發起最終的提交指令。
如果有參與者沒有準備好則發起回滾指令。

一個下單減庫存的例子:

1、應用程式連線兩個資料來源。

2、應用程式通過事務協調器向兩個庫發起prepare,兩個資料庫收到訊息分別執行本地事務(記錄紀錄檔),但不提交,如果執行成功則回覆yes,否則回覆no。

3、事務協調器收到回覆,只要有一方回覆no則分別向參與者發起回滾事務,參與者開始回滾事務。

4、事務協調器收到回覆,全部回覆yes,此時向參與者發起提交事務。如果參與者有一方提交事務失敗則由事務協調器發起回滾事務。

2PC的優點:實現強一致性,部分關聯式資料庫支援(Oracle、MySQL等)。

缺點:整個事務的執行需要由協調者在多個節點之間去協調,增加了事務的執行時間,效能低下。

解決方案有:springboot+Atomikos or Bitronix

3PC主要是解決協調者與參與者通訊阻塞問題而產生的,它比2PC傳遞的訊息還要多,效能不高。

詳細參考3PC:

https://en.wikipedia.org/wiki/Three-phase_commit_protocol

4.2、事務補償 TCC

TCC事務補償是基於2PC實現的業務層事務控制方案,它是Try、Confirm和Cancel三個單詞的首字母,含義如下:

1、Try 檢查及預留業務資源完成提交事務前的檢查,並預留好資源。
2、Confirm確定執行業務操作對try階段預留的資源正式執行。
3、Cancel取消執行業務操作對try階段預留的資源釋放。

下邊用一個下單減庫存的業務為例來說明:

1、Try

下單業務由訂單服務和庫存服務協同完成,在try階段訂單服務和庫存服務完成檢查和預留資源。
訂單服務檢查當前是否滿足提交訂單的條件(比如:當前存在未完成訂單的不允許提交新訂單)。
庫存服務檢查當前是否有充足的庫存,並鎖定資源。

2、Confirm

訂單服務和庫存服務成功完成Try後開始正式執行資源操作。
訂單服務向訂單寫一條訂單資訊。
庫存服務減去庫存。

3、Cancel

如果訂單服務和庫存服務有一方出現失敗則全部取消操作。
訂單服務需要刪除新增的訂單資訊。
庫存服務將減去的庫存再還原。
優點:最終保證資料的一致性,在業務層實現事務控制,靈活性好。
缺點:開發成本高,每個事務操作每個參與者都需要實現try/confirm/cancel三個介面。

注意:TCC的try/confirm/cancel介面都要實現冪等性,在為在try、confirm、cancel失敗後要不斷重試。

什麼是冪等性?

冪等性是指同一個操作無論請求多少次,其結果都相同。
冪等操作實現方式有:

1、操作之前在業務方法進行判斷如果執行過了就不再執行。
2、快取所有請求和處理的結果,已經處理的請求則直接返回結果。
3、在資料庫表中加一個狀態列位(未處理,已處理),資料操作時判斷未處理時再處理。

4.3、訊息佇列實現最終一致性

本方案是將分散式事務拆分成多個本地事務來完成,並且由訊息佇列非同步協調完成,如下圖:
下邊以下單減少庫存為例來說明:

可以把MQ去掉不使用MQ

1、訂單服務和庫存服務完成檢查和預留資源。
2、訂單服務在本地事務中完成新增訂單表記錄和新增「減少庫存任務訊息」。
3、由定時任務根據訊息表的記錄傳送給MQ通知庫存服務執行減庫存操作。
4、庫存服務執行減少庫存,並且記錄執行訊息狀態(為避免重複執行訊息,在執行減庫存之前查詢是否執行過此訊息)。
5、庫存服務向MQ傳送完成減少庫存的訊息。
6、訂單服務接收到完成庫存減少的訊息後刪除原來新增的「減少庫存任務訊息」。
實現最終事務一致要求:預留資源成功理論上要求正式執行成功,如果執行失敗會進行重試,要求業務執行方法實現冪等。

優點 :

由MQ按非同步的方式協調完成事務,效能較高。
不用實現try/confirm/cancel介面,開發成本比TCC低。

缺點:

此方式基於關聯式資料庫本地事務來實現,會出現頻繁讀寫資料庫記錄,浪費資料庫資源,另外對於高並行操作不是最佳方案。

以上就是淺談Java實現分散式事務的三種方案的詳細內容,更多關於Java 分散式事務的資料請關注it145.com其它相關文章!


IT145.com E-mail:sddin#qq.com