大家好，今天想和大家一起聊聊分布式事務。
今天主要說主要内容如下：
* 分布式事務TCC
我們知道布式式事物TCC代表Try、Confirm、Cancel，就是嘗試、确認、取消。這個是網際網路上比較常見的分布式事務。首先它的運作邏輯如下圖。
執行步驟是這樣的：
- 提供兩個服務，服務A和服務B
- 每個服務裡邊需要行提供try、conform、cancel的方法用于執行。
- 當業務發起分布式事物調用之後，先記錄到日志中，然後執行try操作，如果沒有問題的話執行confirm操作。
- 如果其中某個過程出現了問題此時需要執行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的邏輯，這樣業務代碼量也會相對不少，但是由于可以處理高并發量的請求，也深受很多大廠的喜歡。