“如何解決TCC中的懸掛問題”！ 一個工作了4年的Java程式員，去京東面試，被問到這個問題。 大家好，我是Mic，一個工作了14年的Java程式員 這個問題面試官想考察什麼方面的知識？我們又該怎麼回答呢？ 問題解析 TCC是分散式事務問題裡面的解決方案，一般在應聘互聯網公司的時候問的比較多。 實際 ...
“如何解決TCC中的懸掛問題”！
一個工作了4年的Java程式員，去京東面試，被問到這個問題。
大家好，我是Mic，一個工作了14年的Java程式員
這個問題面試官想考察什麼方面的知識？我們又該怎麼回答呢？
問題解析
TCC是分散式事務問題裡面的解決方案，一般在應聘互聯網公司的時候問的比較多。
實際上，在TCC這個事務解決方案裡面，除了懸掛問題以外，還有空回滾、冪等性需要考慮。
但是我們在應用的時候都是採用一些成熟的框架，比如Seata，這些框架本身就幫我們解決了。
導致大部分人不知道這個問題的意思。
所謂TCC，其實就是（Try-Confirm-Cancel），也就是把一個事務拆分成兩個階段，類似於傳統的XA事務模型。
Try這個階段，是實現業務的檢查，預留必要的業務資源。
Confirm，真正執行業務邏輯，只需要使用try階段預留的業務資源進行處理就行。
Cancel，如果事務執行失敗，就通過cancel方法釋放try階段預留的資源。
在TCC事務模式下，我們通過一個事務協調器來管理多個事務，每個事務先執行try方法。
當所有事務參與者的try方法執行成功，就執行confirm方法完成真正邏輯的執行，一旦任意一個事務參與者出現異常，就通過cancel介面觸發事務回滾，釋放Try階段占用的資源。
很顯然，這是一個最終一致性的實現方案，因此當Try執行成功，就必須確保Confirm執行成功。
當Try執行失敗，就必須確保Cancel實現資源釋放。
而面試題中提到懸掛問題，指的是TCC執行Try介面出現網路超時時候，使得TCC觸發Cancel介面回滾，但可能在回滾之後，這個超時的Try介面才被真正執行，也就導致Cancel介面比Try介面先執行。
從而造成Try介面預留的資源一直無法釋放，這種情況就是懸掛。
以上就是TCC懸掛問題的背景，它確實是每個成熟的高級開發必須要瞭解的細節。
因為有可能會造成比較嚴重的生產事故。
瞭解了背景之後，我們應該如何解決呢？下麵來看看高手的回答。
高手：
對於懸掛問題，我認為只需要保證Cancel介面執行完以後，Try介面不允許在執行就可以了。
所以，我們可以在Try介面裡面，先判斷Cancel介面有沒有執行過，如果已經執行過，就不再執行。
是否執行過的這個判斷，可以在事務控製表裡面插入一條事務控制記錄來標記這個事務的回滾狀態。
然後在Try介面中只需要讀取這個狀態來判斷就行了。
總結
好了，今天的分享就到這裡結束了。
如果喜歡我的作品，記得點贊、收藏、關註！！！
版權聲明：本博客所有文章除特別聲明外，均採用 CC BY-NC-SA 4.0 許可協議。轉載請註明來自
Mic帶你學架構！
如果本篇文章對您有幫助，還請幫忙點個關註和贊，您的堅持是我不斷創作的動力。歡迎關註「跟著Mic學架構」公眾號公眾號獲取更多技術乾貨！
