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

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

前言

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

場景

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

在傳統(tǒng)的單體架構(gòu)的業(yè)務中可以使Mysql事務來保持數(shù)據(jù)的一致性，如果跨系統(tǒng)、跨服務、跨數(shù)據(jù)庫，應該如何保持數(shù)據(jù)一致性呢？

概念引入

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

BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個短語的簡寫，BASE是對CAP中一致性和可用性權衡的結(jié)果，其來源于對大規(guī)模互聯(lián)網(wǎng)系統(tǒng)分布式實踐的結(jié)論，是基于CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應用都可以根據(jù)自身的業(yè)務特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性（Eventual consistency）。

• BA: Basic Availability 基本業(yè)務可用性（支持分區(qū)失敗）

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

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

CAP定理

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

柔性事務解決方案之TCC

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

實現(xiàn)

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

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

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

2. 主業(yè)務服務負責發(fā)起并完成整個業(yè)務活動；

3. 從業(yè)務服務提供TCC型業(yè)務操作；

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

TCC事務注意事項

并發(fā)控制

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

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

允許空回滾

如下圖所示，事務協(xié)調(diào)器在調(diào)用 TCC 服務的一階段 Try 操作時，可能會出現(xiàn)因為丟包而導致的網(wǎng)絡超時。此時事務管理器會觸發(fā)二階段回滾，調(diào)用 TCC 服務的 Cancel 操作，而 Cancel 操作調(diào)用未出現(xiàn)超時。

TCC 服務在未收到 Try 請求的情況下收到 Cancel 請求，這種場景被稱為空回滾。空回滾在生產(chǎn)環(huán)境經(jīng)常出現(xiàn)，用戶在實現(xiàn) TCC 服務時，應允許空回滾的執(zhí)行，即收到空回滾時返回成功。

防懸掛控制

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

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

冪等控制

無論是網(wǎng)絡數(shù)據(jù)包重傳，還是異常事務的補償執(zhí)行，都會導致 TCC 服務的 Try、Confirm 或者 Cancel 操作被重復執(zhí)行；用戶在實現(xiàn) TCC 服務時，需要考慮冪等控制，即 Try、Confirm、Cancel 執(zhí)行一次和執(zhí)行多次的業(yè)務結(jié)果是一樣的。

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