在過去的兩年里，微服務(wù)變得越來越熱門，各種框架和組件的出現(xiàn)促進(jìn)了微服務(wù)的發(fā)展。

眾所周知，每個微服務(wù)都是一個對應(yīng)的小服務(wù)，多個服務(wù)可以很容易地組合起來形成更強(qiáng)大的服務(wù)。服務(wù)之間的數(shù)據(jù)和部署是獨(dú)立的，因此故障可以相互隔離。但是它也帶來了分布式應(yīng)用程序?qū)⒚媾R的問題:

如何保證多個服務(wù)之間的交易？如何保證操作的原子性和一致性？

對于傳統(tǒng)的應(yīng)用程序開發(fā)和部署，所謂的ACID可以通過數(shù)據(jù)事務(wù)來保證，但是在微服務(wù)場景中，數(shù)據(jù)庫無法做到這一點(diǎn)。

這時候2PC和3PC輪流解決這樣的問題。但是，在某些場景下，根據(jù)我們的實(shí)際需求，我們并不需要純2PC。比如你只關(guān)心數(shù)據(jù)的原子性和最終一致性，那么你就受不了2PC階段的堵塞，于是一些聰明人想出了一個新辦法。這是我們今天要討論的靈活交易TCC。

什么是靈活交易TCC？

我們今天說的靈活交易，“軟”主要是相對于“傳統(tǒng)”的ACID，靈活交易只需要遵循BASE原則。而TCC是一種柔性交易的實(shí)現(xiàn)。TCC是三個首字母，試-確認(rèn)-取消。具體描述是將整個操作分為以上三個步驟。嘗試在兩個微服務(wù)之間同時進(jìn)行。在嘗試階段，將進(jìn)行數(shù)據(jù)驗(yàn)證、檢查和資源預(yù)創(chuàng)建。如果兩者都成功，則分別進(jìn)行確認(rèn)。如果兩者都成功，整個TCC交易就完成了。如果確認(rèn)時出現(xiàn)服務(wù)問題，會轉(zhuǎn)到取消，相當(dāng)于確認(rèn)的反操作。

整個靈活交易有多種實(shí)現(xiàn)思路，比如:

特定用途

在之前的項(xiàng)目開發(fā)中，我們也有類似的場景來確保兩個微服務(wù)之間的一致性。根據(jù)具體場景，采用TCC交易。當(dāng)時是通過部門的一個基本組成部分和異步補(bǔ)償來保證的。

基本實(shí)現(xiàn)原理

這些TCC框架基本都是“注釋”的形式，其中聲明了Confirm方法和Cancel方法，然后帶有注釋的方法被AOP統(tǒng)一截取，然后根據(jù)結(jié)果分別執(zhí)行Confirm或者Cancel。

代碼如下所示:

@可賠(confirmMethod = "confirmRecord "，cancelMethod = "cancelRecord "，transactionContextEditor = methotransactioncontexteditor . class)

公共字符串記錄(事務(wù)上下文事務(wù)上下文，大寫貿(mào)易訂單到貿(mào)易訂單到){

確認(rèn)方法

public void confirm record(transaction context transaction context，CapitaL TradeOrder to TradeOrder to){

取消方法:

public void cancelRecord(transaction context transaction context，Redpackettradeordto tradeorderto){

基于相似的框架，可以更方便地滿足我們的業(yè)務(wù)使用場景。歡迎留言添加您如何確保分布式場景中的一致性。