之前在InfoQ上看過支付寶分享的SOA架構下的事務處理經驗, 其中提到 TCC (Try-Confirm-Cancel) 模式。自己思考了一下，實現一個支持TCC事務的業務服務在復雜場景下還是有難度，例如一個業務服務可能涉及到一系列的數據表的變化，如何才能保證在try以后這些數據被鎖定（防止其他事務用掉,進而導致confirm的時候失?。?希望有過TCC開發經驗的同學分享一下心得。
4 回答
撒科打諢
TA貢獻1934條經驗 獲得超2個贊
TCC是分布式事務實現的一種方式
TRYING 階段主要是對業務系統做檢測及資源預留
CONFIRMING 階段主要是對業務系統做確認提交，TRYING階段執行成功并開始執行CONFIRMING階段時，默認 CONFIRMING階段是不會出錯的。即：只要TRYING成功，CONFIRMING一定成功。
CANCELING 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。
而冪等性則是指業務方法調用一次與調用多次的執行返回結果是一樣的。
舉個支付項目的例子：
支付系統接收到會員的支付請求后，需要扣減會員賬戶余額、增加會員積分（暫時假設需要同步實現）增加商戶賬戶余額
再假設：會員系統、商戶系統、積分系統是獨立的三個子系統，無法通過傳統的事務方式進行處理。
TRYING階段：我們需要做的就是會員資金賬戶的資金預留，即：凍結會員賬戶的金額（訂單金額）
CONFIRMING階段：我們需要做的就是會員積分賬戶增加積分余額，商戶賬戶增加賬戶余額
CANCELING階段：該階段需要執行的就是解凍釋放我們扣減的會員余額
以上所有的操作需要滿足冪等性，冪等性的實現方式可以是：
1、通過唯一鍵值做處理，即每次調用的時候傳入唯一鍵值，通過唯一鍵值判斷業務是否被操作，如果已被操作，則不再重復操作
2、通過狀態機處理，給業務數據設置狀態，通過業務狀態判斷是否需要重復執行
另外：你也可以看下這篇博客，上面是以傳統電商平臺支付系統為例的一套分布式事務處理實現，講的也比較深
http://www.roncoo.com/article/detail/124243
添加回答
舉報
0/150
提交
取消