“如何解決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學架構」公眾號公眾號獲取更多技術干貨！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/505473.html
標籤：其他
上一篇：django中的視圖層