"分散式交易"解決方案匯總 -- 2PC/TCC/事務訊息/1PC

說到分散式交易，網上的文章汗牛充棟，理論很多，實踐也多。有的清晰的說明了問題，有些越看越糊塗。
之前我也寫過一篇分散式交易的文章《分布式訊息佇列RocketMQ–事務訊息–解決分散式交易的最佳實務》，裡面主要講了“事務訊息”這1種解決方案的2種實現方式。本文將在那篇文章的基礎上，把我認為的其他靠譜方案也系統性的整理一下。 2PC的問題 2PC簡介

說到分散式交易，就會提到2pc。2pc是什麼，我這裡簡要說明一下。網上文章實在太多。就不畫圖詳細闡述了。

2pc涉及到2個階段，3個操作： 
階段1：“準備提交”。事務協調者向所有參與者發起prepare，所有參與者回答yes/no。 
階段2：“正式提交”。如果所有參與者都回答yes，則向所有參與者發起commit；否則，向所有參與者發起rollback。 
因此，要實現2pc，所有參與者，都得實現3個介面：prepare/commit/rollback。 2PC的實現

關於2pc，對應的實現層面，也就是XA協議。有一個Atomikos開源庫，也實現了這個協議。有興趣的可以去看一下如何使用。 2PC的問題

（1）階段2，事務協調者掛了，則所有參與者接受不到commit/rollback指令，將處於“懸而不決”狀態 
（2）階段2，其中一個參與者逾時或者出錯，那其他參與者，是commit，還是rollback呢。 也不能確定

為瞭解決2pc的問題，又引入3pc。3pc有類似的掛了如何解決的問題，因此還是沒能徹底解決問題，此處就不詳述了。 TCC

為瞭解決SOA系統中的分散式交易問題，支付寶提出了TCC。2PC通常都是在跨庫的DB層面，而TCC本質就是一個應用程式層面的2PC。

同樣，TCC中，每個參與者需要3個操作：Try/Confirm/Cancel，也是2個階段。 
階段1：”資源預留/資源檢查“，也就是事務協調者調用所有參與者的Try操作 
階段2：“一起提交”。如果所有的Try成功，一起執行Confirm。否則，所有的執行Cancel. TCC是如何解決2PC的問題呢。

關鍵：Try階段成功之後，Confirm如果失敗(不管是協調者掛了，還是某個參與者逾時），不斷重試。。 
同樣，Cancel失敗了，也是不斷重試。這就要求Confirm/Cancel都必須是等冪操作。

下面以1個轉賬case為例，來說明TCC的過程： 
有3個帳號A, B, C，通過SOA提供的轉賬服務作業。A, B同時分別要向C轉30, 50元，最後C的帳號+80，A, B各減30, 50。

階段1：A帳號鎖定30，B帳號鎖定50，檢查C帳號的合法性（比如C帳號是否違法被凍結，C帳號是否已登出。。。）。 
所以，對應的“扣錢”的Try操作就是”鎖定”，對應的“加錢”的Try操作就是檢查帳號合法性

階段2：A, B, C都Try成功，執行Confirm。即A, B減錢，C加錢。如果任意一個失敗，不斷重試。

從上面的案例可以看出，Try操作主要是為了“保證業務操作的前置條件都得到滿足”，然後在Confirm階段，因為前置條件都滿足了，所以可以不斷重試保證成功。 事務訊息 – 最終一致性

關於最終一致性，又有2種實現方式，這個在《分布式訊息佇列RocketMQ–事務訊息–解決分散式交易的最佳實務》中已經有詳細闡述，此處不再展開。 1PC – Saga – 事務補償

我們知道，在tcc裡面，有2個階段。其中第1個階段是“鎖定資源”，目的是為了保證第2個階段的提交在業務上不會失敗。 
而1pc，就是捨棄掉第1個階段，不做資源鎖定，直接進行第2個階段的提交。如果業務的特性可以允許不需要鎖定資源，那就可以省去第1個階段，直接做第2個階段。

如果第2個階段失敗呢，有2種策略：策略1，同TCC一樣，也是不斷重試commit，硬著頭皮上；策略2，復原，也就是事務補償，做之前操作的反操作。

關於1pc，個人理解的不是特別到位，有興趣的可以參考cqrs的saga。 
http://www.cnblogs.com/netfocus/p/3149156.html