TCC事務的解決方案是怎樣的

這篇文章將為大家詳細講解有關TCC事務的解決方案是怎樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

前言

在開始之前先聊一聊什么是微服務，顧名思義，微服務得從兩個方面去理解，什么是"微"、什么是"服務"， 微 狹義來講就是體積小、著名的"2 pizza 團隊"很好的詮釋了這一解釋（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，所有參與人從設計、開發、測試、運維所有人加起來 只需要2個披薩就夠了 ）。而所謂服務，一定要區別于系統，服務一個或者一組相對較小且獨立的功能單元，是用戶可以感知最小功能集。

場景

這里就不啰嗦哪些東西了，百度一大堆，咱們用代碼看問題~ ~。

在傳統的單體架構的業務中可以使Mysql事務來保持數據的一致性，如果跨系統、跨服務、跨數據庫，應該如何保持數據一致性呢？

概念引入

在了解分布式事務之前要先了解這兩個概念：BASE理論及CAP定理。

BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫，BASE是對CAP中一致性和可用性權衡的結果，其來源于對大規模互聯網系統分布式實踐的結論，是基于CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）。

• BA: Basic Availability 基本業務可用性（支持分區失敗）

• S: Soft state 柔性狀態（狀態允許有短時間不同步，異步）

• E: Eventual consistency 最終一致性（最終數據是一致的，但不是實時一致）

CAP定理

對于共享數據系統，最多只能同時擁有CAP其中的兩個，沒法三者兼顧，任兩者的組合都有其適用場景，真實系統應當是ACID與BASE的混合體，不同類型的業務可以也應當區別對待

柔性事務解決方案之TCC

進入主題，介紹下分布式事務TCC的技術方案，先上一張圖。

實現

這里講述下，我在代碼中的實現思路以及方法，供大家參考，方法不一定是最好的，主要講的是實現的一個基本思路，可能有很多內容沒考慮到，需要大家的指正。

業務中設計階段有：
try嘗試階段：預留扣除（增加）資源
confirm提交階段：確認扣除（增加）資源
cancel回滾階段：回滾預留資源
也就是說每個服務提供者必須要實現這三個階段的方法

1. 一個完整的業務活動由一個主業務服務與若干從業務服務組成；

2. 主業務服務負責發起并完成整個業務活動；

3. 從業務服務提供TCC型業務操作；

4. 業務活動管理器控制業務活動的一致性，它登記業務活動中的操作， 并在業務活動提交時確認所有的TCC型操作的confirm操作，在業務活動取消時調用所有TCC型操作的cancel操作

TCC事務注意事項

并發控制

用戶在實現 TCC 時，應當考慮并發性問題，將鎖的粒度降到最低，以最大限度提高分布式事務的并發性。

在一階段 Try 操作中，分布式事務 T1 和分布式事務 T2 分別預留的那一部分資源，相互之間無干擾。這樣在分布式事務的二階段，無論 T1 是提交還是回滾，都不會對 T2 產生影響，這樣 T1 和 T2 可以在同一筆業務數據上并行執行。

允許空回滾

如下圖所示，事務協調器在調用 TCC 服務的一階段 Try 操作時，可能會出現因為丟包而導致的網絡超時。此時事務管理器會觸發二階段回滾，調用 TCC 服務的 Cancel 操作，而 Cancel 操作調用未出現超時。

TCC 服務在未收到 Try 請求的情況下收到 Cancel 請求，這種場景被稱為空回滾。空回滾在生產環境經常出現，用戶在實現 TCC 服務時，應允許空回滾的執行，即收到空回滾時返回成功。

防懸掛控制

如下圖所示，事務協調器在調用 TCC 服務的一階段 Try 操作時，可能會出現因網絡擁堵而導致的超時。此時事務管理器會觸發二階段回滾，調用 TCC 服務的 Cancel 操作，Cancel 調用未超時。在此之后，擁堵在網絡上的一階段 Try 數據包被 TCC 服務收到，出現二階段 Cancel 請求比一階段 Try 請求先執行的情況，此 TCC 服務在執行晚到的Try 之后，將永遠不會再收到二階段的 Confirm 或者 Cancel，造成 TCC 服務懸掛。

用戶在實現 TCC 服務時，要允許空回滾，但是要拒絕執行空回滾之后 Try 請求，要避免出現懸掛。

冪等控制

無論是網絡數據包重傳，還是異常事務的補償執行，都會導致 TCC 服務的 Try、Confirm 或者 Cancel 操作被重復執行；用戶在實現 TCC 服務時，需要考慮冪等控制，即 Try、Confirm、Cancel 執行一次和執行多次的業務結果是一樣的。

關于TCC事務的解決方案是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。