【分佈式事務】分佈式事務解決方案

轉載:https://www.cnblogs.com/barrywxx/p/8533363.html

1 微服務的發展

微服務倡導將複雜的單體應用拆分爲若干個功能簡單、鬆耦合的服務,這樣能夠下降開發難度、加強擴展性、便於敏捷開發。當前被愈來愈多的開發者推崇,不少互聯網行業巨頭、開源社區等都開始了微服務的討論和實踐。Hailo有160個不一樣服務構成,NetFlix有大約600個服務。國內方面,阿里巴巴、騰訊360、京東、58同城等不少互聯網公司都進行了微服務化實踐。當前微服務的開發框架也很是多,比較著名的有DubboSpringCloudthrift 、grpc等。html

2 微服務落地存在的問題

雖然微服務如今如火如荼,但對其實踐其實仍處於探索階段。不少中小型互聯網公司,鑑於經驗、技術實力等問題,微服務落地比較困難。如著名架構師Chris Richardson所言,目前存在的主要困難有以下幾方面:spring

1)單體應用拆分爲分佈式系統後,進程間的通信機制和故障處理措施變的更加複雜。docker

2)系統微服務化後,一個看似簡單的功能,內部可能須要調用多個服務並操做多個數據庫實現,服務調用的分佈式事務問題變的很是突出。數據庫

3)微服務數量衆多,其測試、部署、監控等都變的更加困難。apache

隨着RPC框架的成熟,第一個問題已經逐漸獲得解決。例如dubbo能夠支持多種通信協議,springcloud能夠很是好的支持restful調用。對於第三個問題,隨着docker、devops技術的發展以及各公有云paas平臺自動化運維工具的推出,微服務的測試、部署與運維會變得愈來愈容易。segmentfault

而對於第二個問題,如今尚未通用方案很好的解決微服務產生的事務問題。分佈式事務已經成爲微服務落地最大的阻礙,也是最具挑戰性的一個技術難題。 爲此,本文將深刻和你們探討微服務架構下,分佈式事務的各類解決方案,並重點爲你們解讀阿里巴巴提出的分佈式事務解決方案----GTS。該方案中提到的GTS是全新一代解決微服務問題的分佈式事務互聯網中間件。restful

3 傳統分佈式事務解決方案

3.1 基於XA協議的兩階段提交方案

交易中間件與數據庫經過 XA 接口規範,使用兩階段提交來完成一個全局事務, XA 規範的基礎是兩階段提交協議。
第一階段是表決階段,全部參與者都將本事務可否成功的信息反饋發給協調者;第二階段是執行階段,協調者根據全部參與者的反饋,通知全部參與者,步調一致地在全部分支上提交或者回滾。網絡

 

兩階段提交方案應用很是普遍,幾乎全部商業OLTP數據庫都支持XA協議。可是兩階段提交方案鎖定資源時間長,對性能影響很大,基本不適合解決微服務事務問題。架構

3.2 TCC方案

TCC方案在電商、金融領域落地較多。TCC方案實際上是兩階段提交的一種改進。其將整個業務邏輯的每一個分支顯式的分紅了Try、Confirm、Cancel三個操做。Try部分完成業務的準備工做,confirm部分完成業務的提交,cancel部分完成事務的回滾。基本原理以下圖所示。框架

事務開始時,業務應用會向事務協調器註冊啓動事務。以後業務應用會調用全部服務的try接口,完成一階段準備。以後事務協調器會根據try接口返回狀況,決定調用confirm接口或者cancel接口。若是接口調用失敗,會進行重試。

TCC方案讓應用本身定義數據庫操做的粒度,使得下降鎖衝突、提升吞吐量成爲可能。 固然TCC方案也有不足之處,集中表如今如下兩個方面:

  • 對應用的侵入性強。業務邏輯的每一個分支都須要實現try、confirm、cancel三個操做,應用侵入性較強,改形成本高。
  • 實現難度較大。須要按照網絡狀態、系統故障等不一樣的失敗緣由實現不一樣的回滾策略。爲了知足一致性的要求,confirm和cancel接口必須實現冪等。

上述緣由致使TCC方案大多被研發實力較強、有迫切需求的大公司所採用。微服務倡導服務的輕量化、易部署,而TCC方案中不少事務的處理邏輯須要應用本身編碼實現,複雜且開發量大。

3.3 基於消息的最終一致性方案

消息一致性方案是經過消息中間件保證上、下游應用數據操做的一致性。基本思路是將本地操做和發送消息放在一個事務中,保證本地操做和消息發送要麼二者都成功或者都失敗。下游應用向消息系統訂閱該消息,收到消息後執行相應操做。

 

消息方案從本質上講是將分佈式事務轉換爲兩個本地事務,而後依靠下游業務的重試機制達到最終一致性。基於消息的最終一致性方案對應用侵入性也很高,應用須要進行大量業務改造,成本較高。 

相關文章
相關標籤/搜索