本文源碼：GitHub·點這里 || GitEE·點這里

一、場景案例簡介

1、場景描述

分布式事務在業(yè)務系統中是十分常見的，最經典的場景就是電商架構中的交易業(yè)務，如圖：

客戶端通過請求訂單服務，執(zhí)行下單操作，實際上從訂單服務上又觸發(fā)了多個服務鏈請求，基本步驟如下：

• 客戶端請求在訂單服務上創(chuàng)建訂單；
• 訂單服務調用賬戶服務扣款；
• 訂單服務調用庫存服務執(zhí)行庫存扣減；
• 訂單通過物流服務，轉化為物流運單；

這套流程在電商系統中是基本業(yè)務，在實際的開發(fā)中遠比這里描述的復雜。

2、服務時序圖

上述1中是業(yè)務性的流程概念描述，從系統開發(fā)層面，在微服務的架構模式下，通常的時序流如下：

這樣服務間的通信時序圖在程序設計中十分常見，在分布式系統中，清楚的描述各個服務間的通信流程是十分關鍵的。

上圖描述的交易流程是在最理想的狀態(tài)下，各個服務都執(zhí)行成功，但是程序是不能100%保證一直正常，經常出現如下情況：

• 服務間通信失敗；
• 單個節(jié)點服務宕掉；
• 服務接口執(zhí)行失敗；

這些都是實際開發(fā)中經常出現的問題，比如訂單創(chuàng)建成功，扣款成功，但是庫存扣減失敗，物流運單生成，那么這筆訂單該如何處理？這就是分布式事務要解決的核心問題。

分布式事務機制要保證不同服務之間形成一個整體性的可控的事務，業(yè)務流程上的服務除非全部成功，否則任何服務的操作失敗，都會導致所有服務上操作回滾，撤銷已經完成的動作。

二、TCC基礎概念

1、分段提交協議

XA是一個分布式事務協議，大致分為兩部分：事務管理器和本地資源管理器，本地資源管理器基本由數據庫實現，大多數關系型數據庫都實現XA接口，而事務管理器作為全局事務的調度者，負責整個事務中本地資源的提交和回滾，基本原理如下：

階段1：事務詢問

事務管理器向所有的參與事務的資源管理器發(fā)送確認請求，詢問是否可以執(zhí)行事務提交操作，并等待各參與者的響應，如果執(zhí)事務操作成功，就反饋給事務管理器表示事務可以執(zhí)行，如果沒有成功執(zhí)行事務，就反饋事務不可以執(zhí)行；

階段2：事務提交

XA根據第一階段每個資源管理器是否都準備提交成功，判斷是要事務整體提交還是回滾，正式執(zhí)行事務提交操作，并在完成提交之后釋放整個事務占用的資源；事務也會存在失敗情況，導致流程取消回滾；

XA事務具有強一致性，在兩階段提交的整個過程中，一直會持有資源的鎖，性能不理想的缺點很明顯，特別是在交易下單鏈路中，往往并發(fā)量很高，XA無法滿足該類高并發(fā)場景。

2、TCC概念簡介

Try(預處理)-Confirm(確認)-Cancel(取消)模式的簡稱TCC。

Try階段

業(yè)務檢查(一致性)及資源預留(隔離)，該階段是一個初步操作，提交事務前的檢查及預留業(yè)務資源完成；例如購票系統中的占位成功，需要在15分鐘內支付；

Confirm階段

確認執(zhí)行業(yè)務操作，不在執(zhí)行任何業(yè)務檢查，基于Try階段預留的業(yè)務資源，從理想狀態(tài)下看只要Try成功，Confirm也會成功，因為資源的檢查和鎖定都已經成功；該階段出現問題，需要重試機制或者手動處理；購票系統中的占位成功并且15分鐘內支付完成，購票成功；

Cancel階段

Cancel階段是在業(yè)務執(zhí)行錯誤需要回滾到狀態(tài)下執(zhí)行分支事務的取消，預留資源的釋放；購票系統中的占位成功但是15分鐘內沒有支付，取消占位；

3、TCC對比XA

XA事務的強一致性，導致資源層的鎖定；

TCC在業(yè)務層面追求最終一致性，不會長久占用資源；

三、分段事務分析

現在回到模塊一中的場景案例，在理想狀態(tài)下流程全部成功是好的，但實際情況是突發(fā)情況很多，基于TCC模式分析上述電商的具體業(yè)務：

1、資源預留

在TCC模式下，通常表字段的狀態(tài)設計思路為：訂單(支付中.已支付.取消訂單)，賬戶(金額.凍結金額)，庫存(庫存.凍結庫存)，物流(出庫中.已出庫，已撤回)，這種狀態(tài)管理在開發(fā)中非常常見。

所以在TCC模式里通常會如下處理資源預留：

假設訂單總額為：200，狀態(tài)：支付中，則此時資源預留情況如下：

• tc_account賬戶表：tc_total=1000，tc_ice=200，總金額1000，凍結200；
• tc_inventory庫存表：tc_total=100，tc_ice=20，總庫存100件，凍結20件；
• tc_waybill運單表：tc_state=1，運單狀態(tài)，出庫中；

這樣下單鏈路上的相關資源已檢查并且預留成功；

2、資源提交確認

資源預留成功之后，執(zhí)行資源提交執(zhí)行：

• tc_account賬戶表：tc_total=800，tc_ice=0，即訂單扣款成功；
• tc_inventory庫存表：tc_total=80，tc_ice=0，庫存消減成功；
• tc_waybill運單表：tc_state=2，運單狀態(tài)，已出庫；

這樣下單鏈路上的相關資源已全部提交處理成功，這是最理想的狀態(tài)；

3、失敗回滾

整個過程是可能執(zhí)行失敗的，或者用戶直接自己發(fā)起回退，則要回滾整個鏈路上的數據：

• tc_account賬戶表：tc_total=1000，tc_ice=0，取消賬戶凍結的200；
• tc_inventory庫存表：tc_total=100，tc_ice=0，取消庫存凍結的20件；
• tc_waybill運單表：tc_state=3，運單狀態(tài)，已撤回；

這樣下單鏈路上的相關數據都基于該筆訂單做回退操作，恢復；

4、補償機制

整個電商交易流程，不管是成功，還是完整的回退失敗，都是需要在理想狀態(tài)下，要求整個服務鏈路和數據是絕對正常的才行。但是在實際分布式架構下是很難保證的，所以在產品的設計上會預留很多操作入口，用來手動做事務補償或回退操作：

大型復雜的業(yè)務系統中，直接修改數據庫通常情況下是不允許的，一般核心流程會預留各種操作入口，用來處理突發(fā)狀況，彌補數據的完整性，例如交易鏈路上，只要扣款成功，后續(xù)的數據無論如何都會補上，是不允許回滾的，當然如果沒有扣款成功，訂單有效期結束，該筆交易也就算做結束。

5、寫在最后

通過電商交易的案例，和TCC模式的概念，描述了分布式事務的流程和處理思路，在開發(fā)時通常會選擇現有的分布式組件來具體實現事務控制，這個流程后續(xù)再聊。

四、源代碼地址

GitHub·地址 https://github.com/cicadasmile/data-manage-parent GitEE·地址 https://gitee.com/cicadasmile/data-manage-parent

推薦閱讀：架構設計

序號標題

00	架構設計：單服務.集群.分布式，基本區(qū)別和聯系
01	架構設計：分布式業(yè)務系統中，全局ID生成策略
02	架構設計：分布式系統調度，Zookeeper集群化管理
03	架構設計：接口冪等性原則，防重復提交Token管理
04	架構設計：緩存管理模式，監(jiān)控和內存回收策略
05	架構設計：異步處理流程，多種實現模式詳解
06	架構設計：高并發(fā)流量削峰，共享資源加鎖機制
07	架構設計：分布式服務，庫表拆分模式詳解
08	架構設計：分布式事務①概念簡介和基礎理論

總結

以上是生活随笔為你收集整理的架构设计 | 基于电商交易流程，图解TCC事务分段提交的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。