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

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權衡，在實際應用中，根據業務要求、開發人員情況以及所用框架不同進行調整。

你可能也喜歡:

詳解分布式一致性ACID、CAP、BASE，以及區別

阿里P8架構師談：分布式數據庫數據一致性的原理、與技術實現方案

阿里P8架構師談：分布式事務的解決方案，以及原理、總結

阿里P8架構師談：分布式Session共享的4類技術方案，與優劣勢比較

阿里P8架構師談：分布式鎖的3種實現（數據庫、緩存、Zookeeper)

阿里P8架構師談：分布式系統全局唯一ID簡介、特點、5種生成方式

---

總結

以上是生活随笔為你收集整理的一篇文章彻底搞懂“分布式事务”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。