分布式事務TCC


大家好,今天想和大家一起聊聊分布式事務。

今天主要說主要內容如下:

* 分布式事務TCC

我們知道布式式事物TCC代表Try、Confirm、Cancel,就是嘗試、確認、取消。這個是互聯網上比較常見的分布式事務。首先它的運行邏輯如下圖。

執行步驟是這樣的

  1. 提供兩個服務,服務A和服務B
  2. 每個服務里邊需要行提供try、conform、cancel的方法用於執行。
  3. 當業務發起分布式事物調用之后,先記錄到日志中,然后執行try操作,如果沒有問題的話執行confirm操作。
  4. 如果其中某個過程出現了問題此時需要執行cancel操作。

舉個例子:
購買一件商品,那么我們有幾個服務,一個是訂單服務,一個是庫存服務,還是一個是貨運的服務,當我們購買了一件商品之后,訂單服務的狀態會變為支付成功,庫存的服務將會減少,貨運會將這商品進行出庫。
此時,我們的try操作就是將這幾個服務做成一個“凍結”狀態,confirm就是將“凍結”的狀態變為“非凍結”,這個時間就是操作成功了,cancel就是將“凍結”狀態進行變為之前的形態。我們直接將這個狀態由結果變為正在進行的狀態,這種好處是可以進行還原,並且設計的時候還能保留結果。

try時各個服務的處理:
訂單服務:將訂單狀態由UNPAID(未支付)變為PAYING(支付中)
庫存服務:設置一個frozen_num, 比如庫存10個,購買2個。庫存數量變為8,frozen_num 變為2,即凍結了2個。
貨運服務:貨運服務將2個購買的做一個貨運單,狀態為PREPARING(備貨中)

confirm時各個服務的處理
訂單服務:將訂單的狀態變為PAIED(支付成功)
庫存服務:將frozen_num由2變為0,說明已經成功賣出去了
貨運服務:貨運單的狀態變為READY(可以發貨)

cancel時各個服務的處理
訂單服務:狀態變為CANCELED(取消)
庫存服務:frozen_num變為0,同時庫存服務由8變為10個
貨運服務:貨運服務將2個商品的貨運單狀態變為CANCELED(取消)

通過這樣的服務設計,我們能夠很好的將服務在各個狀態中轉換。當然,里邊還有很多細節,比如,某個服務出現了問題,庫存服務出現問題了,我們應該怎么辦?

我們可以看到圖版中還有一個事物協調器,當事務執行try調用所有服務成功的同時也需要執行的中間過程數據進行記錄,比如購買庫存數2,它的作用就是當某個服務出現問題時可以進行快速的回滾操作。事物協調器也執行confirm、cancel,假如一個服務confirm失敗后,則它會調用另外兩個服務的cancel方法。

我們執行try成功后,在執行confirm的時候,庫存服務出現了問題,比如服務機器掛了,此時我們應該有一個任務,會不斷的調用這個庫存服務,當然嘗試的次數也是有一定的時間間隔,這個可以由我們自己根據業務進行設計,比如一個指數級重試。如果重試到一定次數的時候,那么就需要進行提醒人工進行處理。cancel也同理,這樣設計的目的是防止出現服務問題導致的數據不一致。

因為TCC是柔性事物架構,所以互聯網大廠使用的也很多。支持的框架也不少,比如tcc-tranaction, ByteTCC, seata都是支持。

使用TCC的時候,我們需要自己大量寫一些try、confirm、cancel的邏輯,這樣業務代碼量也會相對不少,但是由於可以處理高並發量的請求,也深受很多大廠的喜歡。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM