從下單場景談談分佈式理論：TCC/BASE/2PC/3PC

柔性事務TCC

TCC：Try-Confirm-Cancel

Try階段：完成全部的業務檢查，預留(鎖定)業務資源

Confirm階段：確認執行業務操做，

Cancel階段： 業務最終失敗，或者部分業務資源鎖定失敗，釋放已鎖定的資源

以常見的下單時使用優惠券的場景爲例，涉及三個應用：訂單服務、庫存服務、優惠券服務：

一、用戶提交下單請求
二、鎖定商品庫存
三、鎖定優惠券
四、訂單落庫

Try階段（用戶下單）：
        依次同步調用鎖定商品庫存、鎖定優惠券
Confirm階段（用戶支付完成）：
       更新訂單狀態爲已支付
       調用庫存扣減、優惠券覈銷。可經過本地任務表或消息隊列保證最終處理成功。
Cancel階段： 
        場景一：鎖定商品庫存成功，鎖定優惠券業務處理失敗。整個業務操做失敗，釋放前一步鎖定的商品庫存。
        場景二：庫存和優惠券都鎖定成功了，可是訂單超時未支付自動關閉，或者用戶主動取消。釋放對應的庫存和優惠券。

 

TCC使用了加鎖粒度較小的柔性事務。如上面的流程，鎖定庫存、鎖定優惠券、訂單落庫三個操做，並無遵循ACID的原則包在一個大的事務中總體進行原子性的提交。而是變成各自獨立應用處理的小事務分開處理。所以也沒法保證在同一時刻各個數據源的數據是對應的（強一致性），某些時刻會出現鎖定了庫存可是訂單尚未落庫。TCC追求的是最終一致性，根據業務最終的成功與否，變動參與者的最終狀態和業務狀態一致。

看到這，瞭解分佈式中BASE理論的會想起軟狀態和最終一致性，TCC算是BASE理論的一種體現。

BASE理論

BASE：Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一致性）

 基本可用：保證核心功能可用。犧牲邊緣功能和部分響應時間。好比電商中，核心業務爲下單，物流查詢、商品評論可適當降級處理。

軟狀態：由於延遲等因素致使的各個節點在某時刻不一致的狀態。

最終一致：最終保持各個節點的數據一致。如上述場景。

2PC和3PC

而後咱們又聽到2PC的概念，也是分爲兩階段，先預留資源再提交，這不和TCC同樣嗎。的確，兩者的兩階段提交的思想確實是同樣的。

2PC和TCC的兩階段補償的區別

但咱們說的2PC指的是基於XA規範的兩階段提交。而XA規範定義的DTP分佈式事務模型中TM和RM的交互。

DTP分佈式事務模型中的三個角色：AP(應用程序)、TM（事務管理器）、RM（資源管理器）

由此總結

2PC是針對是資源層面的（這裏的資源包括數據庫、消息隊列等）事務操做，他的協調者和參與者分別是事務管理器和資源管理器。關注的是多個數據源和數據副本之間的同步，爲了保證強一致性，在整個兩階段包在一個大事務中，會一直持有資源的鎖。典型的例子如Mysql的先寫Redo日誌再寫BinLog就是兩階段的提交。而像Springboot開發者只須要加個@Transactional註解便可，無需關心兩階段提交的細節。

TCC是針對業務應用程序層的，協調者是應用程序，參與者也是應用程序。關注的是應用之間數據的協調。對應的鎖定釋放邏輯包括冪等邏輯都須要開發者實現。

 

3PC

可是兩階段提交是完美的麼，答案是否認的。

這裏咱們先不分什麼TCC的兩階段提交仍是基於XA的2PC了，再去想一想剛纔的下單場景有什麼問題：

假如鎖定了庫存以後，應用或者說協調者崩潰了，後續的工做都沒完成。前期被鎖定的庫存沒有人來釋放了，最終一致性出現問題了。

3PC便是在這種背景下產生的

3PC中增長了超時機制，來避免上述資源狀態永遠沒法實現最終一致的問題，然而超時了到底應該是回滾釋放仍是提交確認呢？

先看看三個階段幹了什麼

        階段1：查詢資源是否可用，注意只查詢不鎖定。全部參與者均可提交再進行下一段，下降預留資源時才發現部分參與者不可提交產生回滾的機率。

        階段2：鎖定資源

        階段3：提交確認

參與者收到PreCommit後返回超時，釋放預留資源，使整個事務在進入階段3以前徹底回滾。

參與者收到DoCommit後返回超時，仍然提交確認。由於能進到階段3說明協調者已經完成了階段2對全部參與者的資源預留鎖定。雖然大機率整個事務會成功，但如此畢竟不是徹底嚴謹的，腦裂問題仍然存在，仍然會出現某個參與者提交其餘參與者返回失敗這樣數據不一致的問題。

腦裂問題：協調者就是分佈式/集羣中的大腦，腦裂即協調者（領導者）的做用失效了。好比崩潰了，或者出現了多個協調者，使得參與者的行爲沒有被統一調度而出現不一致的狀況。

針對上述問題，Paxos算法提供瞭解決方案，每次處理通過分佈式節點中的參與者投票決議是否容許提交，獲得超過半數投票者的贊成後提交。對Paxos的細節本文不作贅述了。