談談分散式事務TCC機制
前言
分散式事務是幾乎所有分散式微服務系統中，最棘手也是最重要的一個點了。在講解分散式事務前，先了解下資料庫事務的特性；資料庫事務的幾個特性：原子性(Atomicity )、一致性( Consistency )、隔離性或獨立性( Isolation)和永續性(Durabilily)，簡稱就是ACID。
CAP定理
CAP定理是由加州大學伯克利分校Eric Brewer教授提出來的，他指出WEB服務無法同時滿足一下3個屬性：
-
一致性(Consistency) ： 客戶端知道一系列的操作都會同時發生(生效)
-
可用性(Availability) ： 每個操作都必須以可預期的響應結束
-
分割槽容錯性(Partition tolerance) ： 即使出現單個元件無法可用,操作依然可以完成
具體地講在分散式系統中，在任何資料庫設計中，一個Web應用至多隻能同時支援上面的兩個屬性。顯然，任何橫向擴充套件策略都要依賴於資料分割槽。因此，設計人員必須在一致性與可用性之間做出選擇。
BASE理論
在分散式系統中，我們往往追求的是可用性，它的重要程式比一致性要高，那麼如何實現高可用性呢？ 前人已經給我們提出來了另外一個理論，就是BASE理論，它是用來對CAP定理進行進一步擴充的。BASE理論指的是：
-
Basically Available（基本可用）
-
Soft state（軟狀態）
-
Eventually consistent（最終一致性）
BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是： 我們無法做到強一致，但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性 （Eventual consistency）。
分散式事務TCC
TCC 其實就是採用的補償機制，其核心思想是：針對每個操作，都要註冊一個與其對應的確認和補償（撤銷）操作。它分為三個階段：
-
Try 階段主要是對業務系統做檢測及資源預留
-
Confirm 階段主要是對業務系統做確認提交，Try階段執行成功並開始執行 Confirm階段時，預設 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。
-
Cancel 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。
舉個例子，假入 Bob 要向 Smith 轉賬，思路大概是：我們有一個本地方法，裡面依次呼叫
1、首先在 Try 階段，要先呼叫遠端介面把 Smith 和 Bob 的錢給凍結起來。
2、在 Confirm 階段，執行遠端呼叫的轉賬的操作，轉賬成功進行解凍。
3、如果第2步執行成功，那麼轉賬成功，如果第二步執行失敗，則呼叫遠端凍結介面對應的解凍方法 (Cancel)。
Try部分完成業務的準備工作，confirm部分完成業務的提交，cancel部分完成事務的回滾。基本原理如下圖所示。
事務開始時，業務應用會向事務協調器註冊啟動事務。之後業務應用會呼叫所有服務的try介面，完成一階段準備。之後事務協調器會根據try介面返回情況，決定呼叫confirm介面或者cancel介面。如果介面呼叫失敗，會進行重試。
TCC方案讓應用自己定義資料庫操作的粒度，使得降低鎖衝突、提高吞吐量成為可能。 當然TCC方案也有不足之處，集中表現在以下兩個方面：
對應用的侵入性強。業務邏輯的每個分支都需要實現try、confirm、cancel三個操作，應用侵入性較強，改造成本高。
實現難度較大。需要按照網路狀態、系統故障等不同的失敗原因實現不同的回滾策略。為了滿足一致性的要求，confirm和cancel介面必須實現冪等。