分布式事務(wù)-04:TCC實(shí)現(xiàn)過程及原理
摘要：本文主要講解分布式事務(wù)中TCC相關(guān)基礎(chǔ)概念，原理及詳細(xì)的執(zhí)行過程。
上一篇：分布式事務(wù)-03:3PC 三階段提交協(xié)議實(shí)現(xiàn)過程及原理
1.tcc理論基礎(chǔ)
前面我們講了分布式事務(wù)的基本概念，CAP理論等，也講了2pc協(xié)議，3pc協(xié)議，我們可以暫時(shí)認(rèn)為2pc協(xié)議，3pc協(xié)議他們是傳統(tǒng)的事務(wù)處理機(jī)制，這一篇，我們講一講TCC（Try-Confirm-Cancel） 事務(wù)機(jī)制，相對(duì)于傳統(tǒng)事務(wù)機(jī)制（X/Open XA Two-Phase-Commit），TCC的特別之處在于它不依賴資源管理器(RM)對(duì)XA的支持，而是通過對(duì)業(yè)務(wù)邏輯（由業(yè)務(wù)系統(tǒng)提供的）的調(diào)度來實(shí)現(xiàn)分布式事務(wù)。
在一個(gè)業(yè)務(wù)系統(tǒng)中，我們有A服務(wù)，提供一個(gè)操作Op,他對(duì)外提供服務(wù)時(shí)，由于網(wǎng)絡(luò)原因，服務(wù)狀態(tài)，數(shù)據(jù)庫狀態(tài)等原因，這個(gè)Op操作，是不能確定百分百可以成功的，怎么辦呢？
我們可以用這樣一種思路：對(duì)這個(gè)Op的操作，我們第一次調(diào)用時(shí)，只是當(dāng)作一個(gè)臨時(shí)操作（try），我們保留后續(xù)取消這個(gè)操作的權(quán)力，如果全局事務(wù)認(rèn)為它該commit,那我們就對(duì)這個(gè)臨時(shí)性操作做一個(gè)確定性的提交(confirm)，如果全局事務(wù)認(rèn)為它該rollback，那我們就撤銷這個(gè)操作(cancel)。?
在tcc事務(wù)機(jī)制中，每一個(gè)初步操作，最終都會(huì)被確認(rèn)或取消。因此，針對(duì)一個(gè)具體的業(yè)務(wù)服務(wù)，TCC事務(wù)機(jī)制需要業(yè)務(wù)系統(tǒng)提供三段業(yè)務(wù)邏輯：
初步操作Try；
確認(rèn)操作Confirm；
取消操作Cancel；?
2. tcc實(shí)現(xiàn)
2.1初步操作（Try）
TCC事務(wù)機(jī)制中的業(yè)務(wù)邏輯（Try），從執(zhí)行階段來看，與傳統(tǒng)事務(wù)機(jī)制中業(yè)務(wù)邏輯相同。但從業(yè)務(wù)角度來看，卻不一樣。TCC機(jī)制中的Try僅是一個(gè)初步操作，它和后續(xù)的確認(rèn)一起才能真正構(gòu)成一個(gè)完整的業(yè)務(wù)邏輯。?
我們可以認(rèn)為：傳統(tǒng)事務(wù)機(jī)制的業(yè)務(wù)邏輯=tcc事務(wù)機(jī)制的try+tcc事務(wù)機(jī)制的confirm。
TCC機(jī)制將傳統(tǒng)事務(wù)機(jī)制中的業(yè)務(wù)邏輯一分為二，拆分后保留的部分即為初步操作（Try）；而分離出的部分即為確認(rèn)操作（Confirm），被延遲到事務(wù)提交階段執(zhí)行。
?TCC事務(wù)機(jī)制以初步操作（Try）為中心的，確認(rèn)操作（Confirm）和取消操作（Cancel）都是圍繞初步操作（Try）而展開。因此，Try階段中的操作，其保障性是最好的，即使失敗，仍然有取消操作（Cancel）可以將其不良影響進(jìn)行回撤。?
2.2確認(rèn)操作（Confirm）
確認(rèn)操作（Confirm）是對(duì)初步操作（Try）的一個(gè)補(bǔ)充。當(dāng)TCC事務(wù)管理器決定commit全局事務(wù)時(shí)，就會(huì)逐個(gè)執(zhí)行初步操作（Try）指定的確認(rèn)操作（Confirm），將初步操作（Try）未完成的事項(xiàng)最終完成。?
2.3取消操作（Cancel）
取消操作（Cancel）是對(duì)初步操作（Try）的一個(gè)回撤。當(dāng)TCC事務(wù)管理器決定rollback全局事務(wù)時(shí)，就會(huì)逐個(gè)執(zhí)行初步操作（Try）指定的取消操作（Cancel）,將初步操作（Try）已完成的操作全部撤回。?
在傳統(tǒng)事務(wù)機(jī)制中，業(yè)務(wù)邏輯的執(zhí)行和事務(wù)的處理，是在不同的階段由不同的部件來完成的：業(yè)務(wù)邏輯部分訪問資源實(shí)現(xiàn)數(shù)據(jù)存儲(chǔ)，其處理是由業(yè)務(wù)系統(tǒng)負(fù)責(zé)；事務(wù)處理部分通過協(xié)調(diào)資源管理器以實(shí)現(xiàn)事務(wù)管理，其處理由事務(wù)管理器來負(fù)責(zé)。?
而在TCC事務(wù)機(jī)制中的業(yè)務(wù)邏輯處理和事務(wù)處理，其關(guān)系就錯(cuò)綜復(fù)雜：業(yè)務(wù)邏輯（Try/Confirm/Cancel）階段涉及所參與資源事務(wù)的commit/rollback；全局事務(wù)commit/rollback時(shí)又涉及到業(yè)務(wù)邏輯（Try/Confirm/Cancel）的執(zhí)行 。
3.通俗解釋
如果我們想在項(xiàng)目中落地tcc分布式事務(wù)，首先需要選擇某種tcc框架整合到項(xiàng)目中，在傳統(tǒng)的（有別于tcc模式）業(yè)務(wù)邏輯實(shí)現(xiàn)中，我們寫業(yè)務(wù)，一個(gè)接口一般有一個(gè)實(shí)現(xiàn)（這里不要摳詞語考慮多實(shí)現(xiàn)，我們只是為了更直觀的展示用tcc和不用tcc兩種模式下的顯著區(qū)別），現(xiàn)在要改造為3個(gè)：Try、Confirm、Cancel ：
1）先是服務(wù)調(diào)用鏈路依次執(zhí)行 Try 邏輯。
2）如果都正常的話，TCC 分布式事務(wù)框架推進(jìn)執(zhí)行 Confirm 邏輯，完成整個(gè)事務(wù)。
3）如果某個(gè)服務(wù)的 Try 邏輯有問題，TCC 分布式事務(wù)框架感知到之后就會(huì)推進(jìn)執(zhí)行各個(gè)服務(wù)的 Cancel 邏輯，撤銷之前try階段執(zhí)行的各種操作。
分布式事務(wù)主要就是應(yīng)對(duì)下面這些可能遇到的情況：
- 某個(gè)服務(wù)的數(shù)據(jù)庫宕機(jī)了；
- 某個(gè)服務(wù)自己掛了；
- Redis、Elasticsearch、MQ 等基礎(chǔ)設(shè)施故障了；
- 某些資源不足了，比如說庫存不夠這些；
- ......
在業(yè)務(wù)操作調(diào)用時(shí)，先來 Try 一下，不要把業(yè)務(wù)邏輯完成，先試試看，看各個(gè)服務(wù)能不能基本正常運(yùn)轉(zhuǎn)，能不能先凍結(jié)需要的資源。
如果 Try 都 OK，也就是說，底層的數(shù)據(jù)庫、Redis、Elasticsearch、MQ 都是可以寫入數(shù)據(jù)的，并且你保留好了需要使用的一些資源（比如凍結(jié)了一部分庫存）。
接著，再執(zhí)行各個(gè)服務(wù)的 Confirm 邏輯，基本上 Confirm 就可以很大概率保證一個(gè)分布式事務(wù)的完成了。
那如果 Try 階段某個(gè)服務(wù)就失敗了，比如說底層的數(shù)據(jù)庫掛了，或者 Redis 掛了，等等。此時(shí)就自動(dòng)執(zhí)行各個(gè)服務(wù)的 Cancel 邏輯，把之前的 Try 邏輯都回滾。保證大家要么一起成功，要么一起失敗。
如果有一些意外的情況發(fā)生了，比如說某個(gè)服務(wù)突然掛了，然后再次重啟，TCC 分布式事務(wù)框架是如何保證之前沒執(zhí)行完的分布式事務(wù)繼續(xù)執(zhí)行的呢？
TCC 事務(wù)框架都是有日志模塊的，主要用來記錄一些分布式事務(wù)的活動(dòng)日志的，可以在磁盤上的日志文件里記錄，也可以在數(shù)據(jù)庫里記錄，來保存分布式事務(wù)運(yùn)行的各個(gè)階段的狀態(tài)和相關(guān)數(shù)據(jù)，如果由于其他原因?qū)е铝朔?wù)出現(xiàn)問題，這時(shí)候日志就會(huì)起作用了。
4.tcc優(yōu)缺點(diǎn)
1.實(shí)現(xiàn)tcc的業(yè)務(wù)成本，一個(gè)邏輯得寫3套，分別對(duì)應(yīng)try,confirm,cancel;
2.confirm和cancel操作的執(zhí)行成本;
3.記錄日志的成本和開銷;
4.復(fù)雜業(yè)務(wù)，tcc的cc難以處理，難以實(shí)現(xiàn);
5.如果框架不考慮冪等，事務(wù)內(nèi)cc實(shí)現(xiàn)需要考慮冪等；
3 tcc適用場景
5.適用場景
1.強(qiáng)隔離性，嚴(yán)格一致性要求的業(yè)務(wù)；
2.執(zhí)行時(shí)間較短的業(yè)務(wù)；
本文部分內(nèi)容參考：https://www.bytesoft.org/
分布式事務(wù)系列：
分布式事務(wù)-00:你真的了解ACID,BASE,CAP嗎
分布式事務(wù)-01:分布式事務(wù)產(chǎn)生原因及相關(guān)概念
分布式事務(wù)-02:2PC 二階段提交協(xié)議實(shí)現(xiàn)過程及原理
分布式事務(wù)-03:3PC 三階段提交協(xié)議實(shí)現(xiàn)過程及原理
分布式事務(wù)-04:TCC 實(shí)現(xiàn)過程及原理
往期系列：
SpringBoot系列
SpringCloud系列
Java虛擬機(jī)系列
精選面經(jīng)
......持續(xù)更新中......
對(duì)文章內(nèi)容有疑問或者不同的見解，歡迎關(guān)注公眾號(hào)java4all，或添加我的微信w1186355422一起交流討論。
IT云清
