淺談：分佈式事務

在現在的分佈式盛行的年代，分佈式事務永遠都是繞不開的一個話題，今天就談談分佈式事務相關的一致性與實戰解決方案。

1、爲何須要分佈式事務

因爲近十年互聯網的發展很是迅速，不少網站的訪問量愈來愈大，集中式環境已經不能知足業務的須要了，只能按照業務爲單位進行數據拆分（包含：垂直拆分與水平拆分），以及按照業務爲單位提供服務，從早期的集中式轉變爲面向服務加構的分佈式應用環境。

舉一個經典的例子，阿里的淘寶網站隨着訪問量愈來愈大，只能按照商品、訂單、用戶、店鋪等業務爲單位進行數據庫拆分，以及按照業務爲單位提供服務接口。

 

 這個時候，爲了完成一個簡單的業務功能，好比：購買商品後扣款，有可能須要橫跨多個服務，涉及用戶訂單、商品庫存、支付等多個數據庫，而這些操做又須要再同一個事務中完成，這就涉及到了分佈式事務。

本質上來講，分佈式事務就是爲了保證不一樣資源服務器的數據一致性。

2、分佈式的一致性理論

最先加州大學伯克利分校Eric Brewer教授提出一個分佈式系統特性的CAP理論。

一、CAP理論的不可能三角

 

（1）一致性（Consistency）

（2）可用性（Availability）

（3）分區容錯性（Partition tolerance）

在分佈式系統中，是不存在同時知足一致性Consistency、可用性Availability和分區容錯性Partition Tolerance三者的。

一句話總結：一致性、可用性和分區容錯再分佈式事務中不可兼得。再絕大多數的場景，都須要犧牲強一致性來換取系統的高可用性，系統每每只須要保證最終一致性。這也是後來發展出來的BASE理論的基礎

二、BASE理論

 

（1）Basically Available（基本可用）

（2）Soft State（柔軟狀態）

（3）Eventually consistent（最終一致性）

BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的結論，是基於CAP定理逐步演化而來的，其核心思想是即便沒法作到強一致性（Strong consistency），但每一個應用均可以根據自身的業務特色，採用適當的方式來使系統達到最終一致性（Eventual consistency）

3、分佈式事務的解決方案

 一、基於XA協議的兩階段提交2PC（2-phase commit）

XA是一個分佈式事務協議，XA中大體分爲兩部分：事務管理器和本地資源管理器，其中本地資源管理器每每由數據庫實現，而事務管理器做爲全局的調度者，負責各個本地資源的提交和回滾。

 

 大體的流程:

（1）第一階段是表決階段，全部參與者都將本事務可否成功的信息反饋給協調者；

（2）第二階段是執行階段，協調者根據全部參與者的反饋，通知全部參與者，步調一致地再全部分支上提交或者回滾。

優缺點：

儘可能保證了數據的強一致性，實現成本較低，在各大主流數據庫都有本身的實現，存在單點故障問題、性能問題、跨數據庫問題。

二、事務補償TCC模式

TCC方案實際上是兩階段提交的一種改進，將整個業務邏輯的每一個分支顯式的分紅了Try、Confirm、Cancel三個操做。

 

 

 優缺點：

對於代碼有侵入性，下降了鎖衝突，提升了吞吐量，缺點是有時候並無那麼好實現。

案例：

螞蟻金服的DTS（prepare、commit、rollback）

三、消息隊列最終一致性方案

經過異步解耦的方式，經過第三種中間件

 

 案例：

RocketMQ、BabbitMQ等都可實現，RocketMQ還有專門的事務型消息，新版的kafka也有。

總之，分佈式系統中事務更多的是對CAP權衡，在實際應用中，根據業務要求、開發人員狀況以及所用框架的不一樣進行調整。

好了，今天的知識就先分享到這裏了。