在如今的分佈式盛行的時代，分佈式事務永遠都是繞不開的一個話題，今天就談談分佈式事務相關的一致性與實戰解決方案。
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也有。
總之，分佈式系統中事務更多的是對CAP權衡，在實際應用中，根據業務要求、開發人員情況以及所用框架不同進行調整。
閱讀更多 優知學院 的文章
