微服務(wù)分布式事務(wù)之LCN、TCC特點(diǎn)、事務(wù)補(bǔ)償機(jī)制緣由以及設(shè)計(jì)重點(diǎn)

在億級(jí)流量架構(gòu)之分布式事務(wù)解決方案對(duì)比中, 已經(jīng)簡(jiǎn)單闡明了從本機(jī)事務(wù)到分布式事務(wù)的演變過(guò)程, 文章的最后簡(jiǎn)單說(shuō)明了TCC事務(wù), 這兒將會(huì)深入了解TCC事務(wù)是原理, 以及理論支持, 最后會(huì)用Demo舉例實(shí)現(xiàn)。

XA協(xié)議

在上面提到的文章中, 分布式事務(wù)直接講二階段提交, 思維邏輯有些斷層, 但是那畢竟是比較解決方案, 在這兒從理論上推導(dǎo)分布式事務(wù)的根基, 也就是為什么要二階段提交。

在單體應(yīng)用中, 往往由自己來(lái)保證事務(wù)的一致性, 但是分布式中, 涉及到跨網(wǎng)絡(luò)調(diào)用就難以保證, 從理論上講兩臺(tái)機(jī)器理論上無(wú)法達(dá)到一致的狀態(tài), 所以專門從服務(wù)角色上將事務(wù)操作抽象出一個(gè)服務(wù)用來(lái)協(xié)調(diào)事務(wù), 叫做協(xié)調(diào)者, 或者說(shuō)事務(wù)管理者。由全局事務(wù)管理器管理和協(xié)調(diào)的事務(wù)，可以跨越多個(gè)資源(如數(shù)據(jù)庫(kù)或JMS隊(duì)列)和進(jìn)程。全局事務(wù)管理器一般使用 XA 二階段提交協(xié)議與數(shù)據(jù)庫(kù)進(jìn)行交互。

而XA協(xié)議, 就是事務(wù)管理者與各個(gè)服務(wù)模塊(也叫服務(wù)者、資源管理者)之間的通訊遵守的協(xié)議就是XA協(xié)議, 簡(jiǎn)單來(lái)說(shuō)就是規(guī)范了接口, 這個(gè)協(xié)議由X/Open組織提出, 是分布式事務(wù)的規(guī)范。 XA規(guī)范主要定義了全局事務(wù)管理器(TM)和局部資源管理器(RM)之間的接口。除此之外, XA接口是雙向的系統(tǒng)接口，在事務(wù)管理器 （TM）以及一個(gè)或多個(gè)資源管理器（RM）之 間形成通信橋梁,如上圖。

二階段提交協(xié)議

二階段協(xié)議,一句話說(shuō)就是, 先進(jìn)行一個(gè)復(fù)雜度低的詢問(wèn)操作, 看看各個(gè)服務(wù)模塊(也叫參與者、資源管理者、RM)是否可以進(jìn)行事務(wù)操作, 一方面檢驗(yàn)網(wǎng)絡(luò)是否通暢, 另一方面看看對(duì)應(yīng)的資源是否被占用 , 如果可以得到的回應(yīng)是所有的服務(wù)可以進(jìn)行事務(wù)操作, 那么這時(shí)候再通知所有服務(wù)提交事務(wù)。詳細(xì)的說(shuō), 二階段提交(2PC：Two-Phase Commit), 該協(xié)議將一個(gè)分布式的事務(wù)過(guò)程拆分成兩個(gè)階段： 投票 和 事務(wù)提交 。為了讓整個(gè)數(shù)據(jù)庫(kù)集群能夠正常的運(yùn)行，該協(xié)議指定了一個(gè) 協(xié)調(diào)者(事務(wù)管理器) 單點(diǎn)，用于協(xié)調(diào)整個(gè)數(shù)據(jù)庫(kù)集群各節(jié)點(diǎn)的運(yùn)行。為了簡(jiǎn)化描述，我們將數(shù)據(jù)庫(kù)集群中的各個(gè)節(jié)點(diǎn)稱為 參與者(也叫服務(wù)者, 資源管理者) 。

第一階段：投票

該階段的主要目的在于打探數(shù)據(jù)庫(kù)集群中的各個(gè)參與者是否能夠正常的執(zhí)行事務(wù)，具體步驟如下：

1. 協(xié)調(diào)者向所有的參與者發(fā)送事務(wù)執(zhí)行請(qǐng)求，并等待參與者反饋事務(wù)執(zhí)行結(jié)果；

2. 事務(wù)參與者收到請(qǐng)求之后，執(zhí)行事務(wù)但不提交，并記錄事務(wù)日志；

3. 參與者將自己事務(wù)執(zhí)行情況反饋給協(xié)調(diào)者，同時(shí)阻塞等待協(xié)調(diào)者的后續(xù)指令。

第二階段：事務(wù)提交

在經(jīng)過(guò)第一階段協(xié)調(diào)者的詢盤之后，各個(gè)參與者會(huì)回復(fù)自己事務(wù)的執(zhí)行情況，這時(shí)候存在 3 種可能性：

1. 所有的參與者都回復(fù)能夠正常執(zhí)行事務(wù)。

2. 一個(gè)或多個(gè)參與者回復(fù)事務(wù)執(zhí)行失敗。

3. 協(xié)調(diào)者等待超時(shí)。

對(duì)于第 1 種情況，協(xié)調(diào)者將向所有的參與者發(fā)出提交事務(wù)的通知，具體步驟如下：

1. 協(xié)調(diào)者向各個(gè)參與者發(fā)送 commit 通知，請(qǐng)求提交事務(wù)；

2. 參與者收到事務(wù)提交通知之后執(zhí)行 commit 操作，然后釋放占有的資源；

3. 參與者向協(xié)調(diào)者返回事務(wù) commit 結(jié)果信息。

除此之外, 還有2種情況, 囿于篇幅, 詳情參考: 億級(jí)流量架構(gòu)之分布式事務(wù)思路及方法后面的二階段提交協(xié)議

今天要聊的TCC就是二階段提交的具體事務(wù)實(shí)現(xiàn)。

LCN

詳情參考:官網(wǎng)(中文版)

有了前面的XA協(xié)議以及二階段提交的知識(shí), 就不難理解LCN框架了, 這個(gè)框架可以理解成就是上面所說(shuō)的協(xié)調(diào)者, 不生產(chǎn)事務(wù), 只負(fù)責(zé)協(xié)調(diào)事務(wù)。5.0以后框架兼容了LCN、TCC、TXC三種事務(wù)模式。

LCN中各個(gè)字母依次代表:鎖定事務(wù)單元（lock）、確認(rèn)事務(wù)模塊狀態(tài)(confirm)、通知事務(wù)(notify)。

在一個(gè)分布式系統(tǒng)下存在多個(gè)模塊協(xié)調(diào)來(lái)完成一次業(yè)務(wù)。那么就存在一次業(yè)務(wù)事務(wù)下可能橫跨多種數(shù)據(jù)源節(jié)點(diǎn)的可能。TX-LCN目的是解決這樣的問(wèn)題。

例如存在服務(wù)模塊A 、B、 C。A模塊是mysql作為數(shù)據(jù)源的服務(wù)，B模塊是基于redis作為數(shù)據(jù)源的服務(wù)，C模塊是基于mongo作為數(shù)據(jù)源的服務(wù)。若需要解決他們的事務(wù)一致性就需要針對(duì)不同的節(jié)點(diǎn)采用不同的方案，并且統(tǒng)一協(xié)調(diào)完成分布式事務(wù)的處理。

在LCN中, 協(xié)調(diào)者稱之為TxManager , 參與者稱之為 TxClient, TxManager作為分布式事務(wù)的控制方, 事務(wù)發(fā)起方或者參與方都由TxClient端來(lái)控制決定。

時(shí)序圖(來(lái)源官網(wǎng)):

LCN核心步驟

• 創(chuàng)建事務(wù)組
  是指在事務(wù)發(fā)起方開(kāi)始執(zhí)行業(yè)務(wù)代碼之前先調(diào)用TxManager創(chuàng)建事務(wù)組對(duì)象，然后拿到事務(wù)標(biāo)示GroupId的過(guò)程。

• 加入事務(wù)組
  添加事務(wù)組是指參與方在執(zhí)行完業(yè)務(wù)方法以后，將該模塊的事務(wù)信息通知給TxManager的操作。

• 通知事務(wù)組
  是指在發(fā)起方執(zhí)行完業(yè)務(wù)代碼以后，將發(fā)起方執(zhí)行結(jié)果狀態(tài)通知給TxManager,TxManager將根據(jù)事務(wù)最終狀態(tài)和事務(wù)組的信息來(lái)通知相應(yīng)的參與模塊提交或回滾事務(wù)，并返回結(jié)果給事務(wù)發(fā)起方。

TCC

詳情參考: Github(中文版)

TCC事務(wù)機(jī)制相對(duì)于二階段提交，其特征在于它不依賴資源管理器(RM)對(duì)XA協(xié)議的支持，而是通過(guò)對(duì)（由業(yè)務(wù)系統(tǒng)提供的）業(yè)務(wù)邏輯的調(diào)度來(lái)實(shí)現(xiàn)分布式事務(wù), 將事務(wù)分成 Try 和 Confirm/ Cancel兩個(gè)階段。

三種操作作用: Try: 嘗試執(zhí)行業(yè)務(wù)、 Confirm:確認(rèn)執(zhí)行業(yè)務(wù)、 Cancel: 取消執(zhí)行業(yè)務(wù)。

整體流程如圖

Try 從執(zhí)行階段來(lái)看，與傳統(tǒng)事務(wù)機(jī)制(二階段提交)中業(yè)務(wù)邏輯相同。但從業(yè)務(wù)角度來(lái)看，卻不一樣。TCC機(jī)制中的Try僅是一個(gè)初步操作，它和后續(xù)的確認(rèn)一起才能真正構(gòu)成一個(gè)完整的業(yè)務(wù)邏輯。TCC機(jī)制將傳統(tǒng)事務(wù)機(jī)制(2PC)中的業(yè)務(wù)邏輯一分為二:

拆分后保留的部分為初步操作（Try）；

而分離出的部分即為驗(yàn)證操作（Confirm/cancel），被延遲到事務(wù)提交階段執(zhí)行。

三階段主要特點(diǎn):

TCC補(bǔ)償機(jī)制

在很多情況下，我們是無(wú)法做到強(qiáng)一致的 ACID 的。特別是我們需要跨多個(gè)系統(tǒng)的時(shí)候，而且這些系統(tǒng)還不是由一個(gè)公司所提供的。比如，在我們的日常生活中，我們經(jīng)常會(huì)遇到這樣的情況，就是要找很多方協(xié)調(diào)很多事，而且要保證我們每一件事都成功，否則整件事就做不到。

參考 http://www./article/6556

比如，要出門旅游， 我們需要干這么幾件事。

第一，向公司請(qǐng)假，拿到相應(yīng)的假期；

第二，訂飛機(jī)票或是火車票；

第三，訂酒店；

第四，租車。

這四件事中，前三件必需完全成功，我們才能出行，而第四件事只是一個(gè)錦上添花的事，但第四件事一旦確定，那么也會(huì)成為整個(gè)事務(wù)的一部分。這些事都是要向不同的組織或系統(tǒng)請(qǐng)求。我們可以并行地做這些事，而如果某個(gè)事有變化，其它的事都會(huì)跟著出現(xiàn)一些變化。

設(shè)想下面的幾種情況。

1. 我沒(méi)有訂到返程機(jī)票，那么我就去不了了。我需要把訂到的去程機(jī)票，酒店、租到的車都給取消了，并且把請(qǐng)的假也取消了。

2. 如果我假也請(qǐng)好了，機(jī)票，酒店也訂好了，只是車沒(méi)租到，那么并不影響我出行這個(gè)事，整個(gè)事還是可以繼續(xù)的。

3. 如果我的飛機(jī)因?yàn)樘鞖庠蛉∠蚴峭睃c(diǎn)了，那么我被迫要去調(diào)整和修改我的酒店預(yù)訂和租車的預(yù)訂。

從人類的實(shí)際生活當(dāng)中，我們可以看出，上述的這些情況都是天天在發(fā)生的事情。所以，我們的分布式系統(tǒng)也是一樣的，也是需要處理這樣的事情——就是當(dāng)條件不滿足，或是有變化的時(shí)候，需要從業(yè)務(wù)上做相應(yīng)的整體事務(wù)的補(bǔ)償。

對(duì)于業(yè)務(wù)補(bǔ)償來(lái)說(shuō)，首先需要將服務(wù)做成冪等性的，如果一個(gè)事務(wù)失敗了或是超時(shí)了，我們需要不斷地重試，努力地達(dá)到最終我們想要的狀態(tài)。然后，如果我們不能達(dá)到這個(gè)我們想要的狀態(tài)，我們需要把整個(gè)狀態(tài)恢復(fù)到之前的狀態(tài)。另外，如果有變化的請(qǐng)求，我們需要啟動(dòng)整個(gè)事務(wù)的業(yè)務(wù)更新機(jī)制。

業(yè)務(wù)補(bǔ)償機(jī)制特點(diǎn)

由上可知，一個(gè)好的業(yè)務(wù)補(bǔ)償機(jī)制需要做到下面這幾點(diǎn)。

1. 要能清楚地描述出要達(dá)到什么樣的狀態(tài)（比如：請(qǐng)假、機(jī)票、酒店這三個(gè)都必須成功，租車是可選的），以及如果其中的條件不滿足，那么，我們要回退到哪一個(gè)狀態(tài)。這就是所謂的整個(gè)業(yè)務(wù)的起始狀態(tài)定義。

2. 當(dāng)整條業(yè)務(wù)跑起來(lái)的時(shí)候，我們可以串行或并行地做這些事。對(duì)于旅游訂票是可以并行的，但是對(duì)于網(wǎng)購(gòu)流程（下單、支付、送貨）是不能并行的。總之，我們的系統(tǒng)需要努力地通過(guò)一系列的操作達(dá)到一個(gè)我們想要的狀態(tài)。如果達(dá)不到，就需要通過(guò)補(bǔ)償機(jī)制回滾到之前的狀態(tài)。這就是所謂的狀態(tài)擬合。

3. 對(duì)于已經(jīng)完成的事務(wù)進(jìn)行整體修改，可以考慮成一個(gè)修改事務(wù)。

其實(shí)，在純技術(shù)的世界里也有這樣的事。比如，線上運(yùn)維系統(tǒng)需要發(fā)布一個(gè)新的服務(wù)或是對(duì)一個(gè)已有的服務(wù)進(jìn)行水平擴(kuò)展，我們需要先找到相應(yīng)的機(jī)器，然后初始化環(huán)境，再部署上應(yīng)用，再做相應(yīng)的健康檢查，最后接入流量。這一系列的動(dòng)作都要完全成功，所以，我們的部署系統(tǒng)就需要管理好整個(gè)過(guò)程和相關(guān)的運(yùn)行狀態(tài)。

業(yè)務(wù)補(bǔ)償?shù)脑O(shè)計(jì)重點(diǎn)

業(yè)務(wù)補(bǔ)償主要做兩件事。

1. 努力地把一個(gè)業(yè)務(wù)流程執(zhí)行完成。

2. 如果執(zhí)行不下去，需要啟動(dòng)補(bǔ)償機(jī)制，回滾業(yè)務(wù)流程。

所以，下面是幾個(gè)重點(diǎn)。

• 因?yàn)橐岩粋€(gè)業(yè)務(wù)流程執(zhí)行完成，需要這個(gè)流程中所涉及的服務(wù)方支持冪等性。并且在上游有重試機(jī)制。

• 我們需要小心維護(hù)和監(jiān)控整個(gè)過(guò)程的狀態(tài)，所以，千萬(wàn)不要把這些狀態(tài)放到不同的組件中，最好是一個(gè)業(yè)務(wù)流程的控制方來(lái)做這個(gè)事，也就是一個(gè)工作流引擎。所以，這個(gè)工作流引擎是需要高可用和穩(wěn)定的。這就好像旅行代理機(jī)構(gòu)一樣，我們把需求告訴它，它會(huì)幫我們搞定所有的事。如果有問(wèn)題，也會(huì)幫我們回滾和補(bǔ)償?shù)摹?/p>

• 補(bǔ)償?shù)臉I(yè)務(wù)邏輯和流程不一定非得是嚴(yán)格反向操作。有時(shí)候可以并行，有時(shí)候，可能會(huì)更簡(jiǎn)單?？傊O(shè)計(jì)業(yè)務(wù)正向流程的時(shí)候，也需要設(shè)計(jì)業(yè)務(wù)的反向補(bǔ)償流程。

• 我們要清楚地知道，業(yè)務(wù)補(bǔ)償?shù)臉I(yè)務(wù)邏輯是強(qiáng)業(yè)務(wù)相關(guān)的，很難做成通用的。

• 下層的業(yè)務(wù)方最好提供短期的資源預(yù)留機(jī)制。就像電商中的把貨品的庫(kù)存預(yù)先占住等待用戶在 15 分鐘內(nèi)支付。如果沒(méi)有收到用戶的支付，則釋放庫(kù)存。然后回滾到之前的下單操作，等待用戶重新下單。

站在巨人的肩膀上