分布式事務

事務是程式執行的邏輯單元，一組操作要麼全部成功，要麼全部失敗

分布式環境下，對系統進行劃分，比如電商專案，會將系統拆分成不同的服務，比如訂單服務，積分服務，庫存服務，尋源服務等等。

訂單生成流程：

修改支付狀態為已支付

呼叫積分服務扣減使用的積分

呼叫庫存服務扣減庫存

呼叫倉儲系統生成物流資訊

訂單生成流程中如果任一步驟失敗，由於在該服務之前其它服務已經完成，就會造成資料不一致。明明沒有扣減庫存，卻使用了積分，並且支付亦顯示完成。

兩階段：準備階段和提交階段

角色：事務的發起者稱協調者，事務的執行者稱參與者

思路：

prepare階段：

commit階段：

兩階段提交實現起來非常簡單，但是：

在分布式網路通訊過程中，很容易造成訊息丟失，延遲

2pc方案缺點：

在2pc基礎上，增加乙個檢查所有參與者健康狀態階段。

cancommit：

precommit：

階段 1 所有參與者均反饋 yes，參與者預執行事務

階段 1 任何乙個參與者反饋 no 或者沒有收到任何反饋（超時或者訊息丟失），中斷事務

do commit：

階段2所有參與者反饋成功資訊

階段2任一參與者反饋no資訊

補償事務：針對每個操作都需要註冊乙個與其對應的回滾（補償）操作

tcc事務是基於二階段的程式設計模型，不過2pc通常都是在跨庫的db層面，而tcc本質上就是乙個應用層面的2pc，需要通過業務邏輯來實現，**侵入性很強

在訂單生成流程中，使用tcc事務：

try階段：

將訂單狀態改為支付中

呼叫積分服務占用積分

呼叫庫存服務預鎖庫存

呼叫倉儲資訊生成預發貨單

try階段如果全部呼叫成功，進入confirm階段進行正式呼叫，如果有乙個服務呼叫失敗，前面其它服務進行回滾。

注：在 tcc 事務機制中認為，如果在 try 階段能正常的預留資源，那 confirm 一定能完整正確的提交。所以confirm 和 cancel 操作必須滿足冪等性，如果失敗的會進行不斷重試直到成功為止

使用tcc分布式框架感知三個階段狀態，我們只需要編寫三個狀態的邏輯**。如果提供服務節點發生宕機，tcc事務框架會記錄一些分布式事務的活動日誌的，可以在磁碟上的日誌檔案裡記錄，也可以在資料庫裡記錄，儲存下來分布式事務執行的各個階段和狀態，節點重啟後會重新進行原來的操作