分布式事務是企業內建中的一個技術難點，也是每一個分布式系統架構中都會涉及到的一個東西，特别是在這幾年越來越火的微服務架構中，幾乎可以說是無法避免。
本篇文章将通過詳解分布式事務的一緻性，以及分布式事務實戰解決方案，幫助大家搞懂分布式事務，推薦收藏。
01 為什麼需要分布式事務
由于近十年網際網路的發展非常迅速，很多網站的通路越來越大，集中式環境已經不能滿足業務的需要了，隻能按照業務為機關進行資料拆分(包含：垂直拆分與水準拆分)，以及按照業務為機關提供服務，從早期的集中式轉變為面向服務架構的分布式應用環境。
舉一個典型的例子，阿裡的淘寶網站随着通路量越來越大，隻能按照商品、訂單、使用者、店鋪等業務為機關進行資料庫拆分，以及按照業務為機關提供服務接口。
這個時候 為了完成一個簡單的業務功能，比如：購買商品後扣款，有可能需要橫跨多個服務，涉及使用者訂單、商品庫存、支付等多個資料庫，而這些操作又需要在同一個事務中完，這就涉及到到了分布式事務。
本質上來說，分布式事務就是為了保證不同資源伺服器的資料一緻性。
02 分布式的一緻性理論
最早加州大學伯克利分校 Eric Brewer教授提出一個分布式系統特性的CAP理論。
1.CAP 理論的不可能三角
一緻性（Consistency）
可用性（Availability）
分區容錯性（Partition tolerance）
在分布式系統中，是不存在同時滿足一緻性 Consistency、可用性 Availability和分區容錯性 Partition Tolerance三者的。
一句話總結：一緻性、可用性和分區容錯在分布式事務中不可兼得。
在絕大多數的場景，都需要犧牲強一緻性來換取系統的高可用性，系統往往隻需要保證最終一緻性。
這也是是後來發展出的BASE理論的基礎。
2.BASE 理論
Basically Available（基本可用）
Soft state（柔軟狀态）
Eventually consistent（最終一緻性）三個短語的簡寫。
BASE是對CAP中一緻性和可用性權衡的結果，其來源于對大規模網際網路系統分布式實踐的結論，是基于CAP定理逐漸演化而來的，其核心思想是即使無法做到強一緻性（Strong consistency），但每個應用都可以根據自身的業務特點，采用适當的方式來使系統達到最終一緻性（Eventual consistency）。
03 分布式事務的解決方案
1.基于XA協定的兩階段送出 2PC(2-phase commit protocol)
XA是一個分布式事務協定，XA中大緻分為兩部分：事務管理器和本地資料總管,其中本地資料總管往往由資料庫實作，而事務管理器作為全局的排程者，負責各個本地資源的送出和復原。
大緻的流程：
第一階段是表決階段，所有參與者都将本事務能否成功的資訊回報發給協調者；
第二階段是執行階段，協調者根據所有參與者的回報，通知所有參與者，步調一緻地在所有分支上送出或者復原。
優缺點
盡量保證了資料的強一緻，實作成本較低，在各大主流資料庫都有自己實作，存在單點故障問題、性能問題、跨資料庫問題。
2.事務補償TCC模式
TCC方案其實是兩階段送出的一種改進，将整個業務邏輯的每個分支顯式的分成了Try、Confirm、Cancel三個操作。
Try部分完成業務的準備工作，confirm部分完成業務的送出，cancel部分完成事務的復原，基本原理如下圖所示：
對代碼有侵入性，降低了鎖沖突，提高了吞吐量，缺點是有時候并沒有那麼好實作。
案例
螞蟻金服的DTS(prepare、commit、rollback)
3.消息隊列最終一緻性方案
通過異步解耦的方式，通過第三方中間件。
RocketMQ RabbitMQ等均可實作，RocketMQ 還有專門的事務型消息，新版的kafka也有。
本文介紹了分布式事務的一些特性和解決方案，分布式事務最初是為解決單服務多資料庫資源的場景而誕生的。随着技術的發展，特别是 SOA 分布式應用架構，以及微服務時代的到來，服務變成了基本業務單元。
分布式系統中事務更多的是對CAP權衡，在實際應用中，會根據業務要求、開發人員情況以及所用架構不同進行調整。
如果覺得有用，請點贊支援下，送BAT架構專題合集500+，私信回複【架構】即可領取。
我是陳睿Mike，專注分享：BAT架構技術幹貨連載+BAT面試真題及答案等純技術幹貨，更多幹貨分享，前往我的部落格檢視。
------end------