TCC事務(wù)分段提交的示例分析

小編給大家分享一下TCC事務(wù)分段提交的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

一、場(chǎng)景案例簡(jiǎn)介

1、場(chǎng)景描述

分布式事務(wù)在業(yè)務(wù)系統(tǒng)中是十分常見(jiàn)的，最經(jīng)典的場(chǎng)景就是電商架構(gòu)中的交易業(yè)務(wù)，如圖：

客戶(hù)端通過(guò)請(qǐng)求訂單服務(wù)，執(zhí)行下單操作，實(shí)際上從訂單服務(wù)上又觸發(fā)了多個(gè)服務(wù)鏈請(qǐng)求，基本步驟如下：

• 客戶(hù)端請(qǐng)求在訂單服務(wù)上創(chuàng)建訂單；

• 訂單服務(wù)調(diào)用賬戶(hù)服務(wù)扣款；

• 訂單服務(wù)調(diào)用庫(kù)存服務(wù)執(zhí)行庫(kù)存扣減；

• 訂單通過(guò)物流服務(wù)，轉(zhuǎn)化為物流運(yùn)單；

這套流程在電商系統(tǒng)中是基本業(yè)務(wù)，在實(shí)際的開(kāi)發(fā)中遠(yuǎn)比這里描述的復(fù)雜。

2、服務(wù)時(shí)序圖

上述1中是業(yè)務(wù)性的流程概念描述，從系統(tǒng)開(kāi)發(fā)層面，在微服務(wù)的架構(gòu)模式下，通常的時(shí)序流如下：

這樣服務(wù)間的通信時(shí)序圖在程序設(shè)計(jì)中十分常見(jiàn)，在分布式系統(tǒng)中，清楚的描述各個(gè)服務(wù)間的通信流程是十分關(guān)鍵的。

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

• 服務(wù)間通信失??；

• 單個(gè)節(jié)點(diǎn)服務(wù)宕掉；

• 服務(wù)接口執(zhí)行失??；

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

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

二、TCC基礎(chǔ)概念

1、分段提交協(xié)議

XA是一個(gè)分布式事務(wù)協(xié)議，大致分為兩部分：事務(wù)管理器和本地資源管理器，本地資源管理器基本由數(shù)據(jù)庫(kù)實(shí)現(xiàn)，大多數(shù)關(guān)系型數(shù)據(jù)庫(kù)都實(shí)現(xiàn)XA接口，而事務(wù)管理器作為全局事務(wù)的調(diào)度者，負(fù)責(zé)整個(gè)事務(wù)中本地資源的提交和回滾，基本原理如下：

階段1：事務(wù)詢(xún)問(wèn)

事務(wù)管理器向所有的參與事務(wù)的資源管理器發(fā)送確認(rèn)請(qǐng)求，詢(xún)問(wèn)是否可以執(zhí)行事務(wù)提交操作，并等待各參與者的響應(yīng)，如果執(zhí)事務(wù)操作成功，就反饋給事務(wù)管理器表示事務(wù)可以執(zhí)行，如果沒(méi)有成功執(zhí)行事務(wù)，就反饋事務(wù)不可以執(zhí)行；

階段2：事務(wù)提交

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

XA事務(wù)具有強(qiáng)一致性，在兩階段提交的整個(gè)過(guò)程中，一直會(huì)持有資源的鎖，性能不理想的缺點(diǎn)很明顯，特別是在交易下單鏈路中，往往并發(fā)量很高，XA無(wú)法滿(mǎn)足該類(lèi)高并發(fā)場(chǎng)景。

2、TCC概念簡(jiǎn)介

Try(預(yù)處理)-Confirm(確認(rèn))-Cancel(取消)模式的簡(jiǎn)稱(chēng)TCC。

Try階段

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

Confirm階段

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

Cancel階段

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

3、TCC對(duì)比XA

XA事務(wù)的強(qiáng)一致性，導(dǎo)致資源層的鎖定；

TCC在業(yè)務(wù)層面追求最終一致性，不會(huì)長(zhǎng)久占用資源；

三、分段事務(wù)分析

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

1、資源預(yù)留

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

所以在TCC模式里通常會(huì)如下處理資源預(yù)留：

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

• tc_account賬戶(hù)表：tc_total=1000，tc_ice=200，總金額1000，凍結(jié)200；

• tc_inventory庫(kù)存表：tc_total=100，tc_ice=20，總庫(kù)存100件，凍結(jié)20件；

• tc_waybill運(yùn)單表：tc_state=1，運(yùn)單狀態(tài)，出庫(kù)中；

這樣下單鏈路上的相關(guān)資源已檢查并且預(yù)留成功；

2、資源提交確認(rèn)

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

• tc_account賬戶(hù)表：tc_total=800，tc_ice=0，即訂單扣款成功；

• tc_inventory庫(kù)存表：tc_total=80，tc_ice=0，庫(kù)存消減成功；

• tc_waybill運(yùn)單表：tc_state=2，運(yùn)單狀態(tài)，已出庫(kù)；

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

3、失敗回滾

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

• tc_account賬戶(hù)表：tc_total=1000，tc_ice=0，取消賬戶(hù)凍結(jié)的200；

• tc_inventory庫(kù)存表：tc_total=100，tc_ice=0，取消庫(kù)存凍結(jié)的20件；

• tc_waybill運(yùn)單表：tc_state=3，運(yùn)單狀態(tài)，已撤回；

這樣下單鏈路上的相關(guān)數(shù)據(jù)都基于該筆訂單做回退操作，恢復(fù)；

4、補(bǔ)償機(jī)制

整個(gè)電商交易流程，不管是成功，還是完整的回退失敗，都是需要在理想狀態(tài)下，要求整個(gè)服務(wù)鏈路和數(shù)據(jù)是絕對(duì)正常的才行。但是在實(shí)際分布式架構(gòu)下是很難保證的，所以在產(chǎn)品的設(shè)計(jì)上會(huì)預(yù)留很多操作入口，用來(lái)手動(dòng)做事務(wù)補(bǔ)償或回退操作：

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

以上是“TCC事務(wù)分段提交的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！