傳統的事務

事務(Transaction)是訪問并可能更新數據庫中各種數據項的一個程序執行單元(unit)。在關系數據庫中，一個事務由一組SQL語句組成。事務應該具有4個屬性：原子性、一致性、隔離性、持久性。這四個屬性通常稱為ACID特性。

• 原子性：一個事務是一個不可分割的工作單位，事務中包括的操作要么全部完成，要么全部取消
• 一致性：事務使數據庫從一個一致性狀態轉換為另一個一致性狀態，事務的中間狀態不可被觀察到。
• 隔離性：一個事務內部的操作及使用的數據對并發中的其它事務是隔離的。
• 持久性：一個事務一旦被提交，其對數據庫中數據的改變是永久性的，不因其它故障而受影響。

集中式數據庫與分布式數據庫

ACID

以一個學生管理系統為例，可以看到對于這個學生成績管理系統，不同的系統使用角色，對它有不同的要求：

那么傳統的事務
ACID屬性，是如何幫助我們做到滿足這些需求的呢？

數據量變大

而實際上，當我們考慮更大的數據量的時候，會發現，依賴于傳統集中式數據庫并無法很好地滿足我們對系統的需求。當數據量變大，第一個要面對的問題是數據再也無法只放在一臺機器上了，數據量的變大，意味著會有越來越多的客戶端來查詢這個數據庫，那么就會出現查詢的瓶頸，并且如果數據數非常重要的話，那么這些數據時丟不起的，而如果僅依賴于集中式數據庫，那么當這個集中式數據庫發生一些致命性的狀況的時候，數據可能丟失。總而言之，對于集中式數據庫來說，如果它出現了什么問題：不可查、丟數據等。那么其實意味著整個業務系統都陷入了不可用的狀態。

總結下來，集中式數據庫在通信、系統可靠性、可擴展性、性能瓶頸以及設計管理上，存在著明顯的缺點：

• 集中數據庫會有多個成績錄入員，因為集中數據庫只存在于某個服務器上，而成績錄入員卻是分散在全國各地的，因此會造成額外的通信開銷。
• 由于集中式數據庫所有的數據都存在一個點上，那么一旦這個點發生故障，就會導致整個成績管理系統停止運作，系統的可靠性差。
• 隨著數據量的變大，錄入的客戶端變多，查詢的客戶端變多，那么存儲系統本身的性能可能就會成為瓶頸，包括 CPU計算能力，IO吞吐能力，存儲能力，都有可能成為瓶頸。
• 可擴展性差，正由于集中式數據庫存在著性能差的問題，因此只能通過升級單機硬件能力的方式，實現數據庫服務能力擴展，比如原來采用 MySQL 單機數據庫，遇到訪問瓶頸時更換磁盤，訪問量更高時就需要考慮使用 Oracle 的商用解決方案、高端的存儲設備、高端小型機，也就是 IOE 架構，甚至升級 IOE 設備，以換取更高的擴展和服務能力，這個過程就會存在設備升級和數據遷移的成本，其可擴展性的代價會面臨巨大的成本問題。此外，根據摩爾定律，單機硬件能力的升級，并不能換來等比的效率加速比例，也就是說，增加多一倍的CPU核數，并不能帶來一倍的性能提升，這個提升并不是線性的。
• 當一個系統的功能變得越來越復雜，例如說b不僅記錄學生的成績，還記錄學生的獎懲歷史，出勤情況，而數據庫仍然只有一個點的情況下，集中數據庫上承載的業務類型越來越多，導致管理困難。

傳統集中式數據庫雖然能夠很好地保證業務一致性，但其面臨高速增長的訪問量和數據量時存在性能和處理能力上的瓶頸。

數據分布式存儲

分布式數據庫雖然引進了復雜性例如分布式事務的問題，但是分布式數據庫能解決集中式數據庫的大多數痛點。
分布式數據庫與集中式數據庫的區別主要在數據分布和可擴展性兩方面：

• 分布式數據庫的數據分散存儲，集中式數據庫的數據集中存儲。
• 分布式數據庫的擴展高效并且性價比高，而集中式數據庫不能無限擴容并且擴容存在著成本導致的性價比的問題。

總結起來，分布式數據庫具有以下的特點：

• 數據分布性，數據可以分布在不同的機器上，不同地理位置上。
• 數據統一性，雖然數據存放在不同的機器上，不同的地理位置上，但從整體上來看，它的系統邏輯應該是一致的
• 數據的透明性，雖然數據分散了，但是無論是查詢還是更新，它們都應該有統一的入口
• 數據的安全性，單個數據節點如果出現錯誤，它不應該影響其它節點，從而數據庫整體的安全性
• 數據的可擴展性，當現有集群稱為瓶頸時，分布式數據庫系統可以通過擴容來解決可擴展性的問題
• 數據的自治性，雖然數據分散存儲，但每一個節點它都應該要能夠獨立管理自己的數據，同時又不影響整體的統一性。

分布式事務

在高速增長的訪問量和數據量的背景下，為了解決單機性能瓶頸以及可擴展性等問題，數據庫分庫分表拆分和服務化（微服務）的運用越來越廣泛。完成一個業務功能，可能需要橫跨多個服務或者橫跨多個數據庫節點；也就是說，需要操作的資源位于多個資源服務器上，從業務的角度來看，需要保證對多個資源服務器的操作，要么全部成功，要么全部失敗。從本質上來說，分布式事務要保證不同資源服務器上的數據一致性。

場景

典型的分布式事務場景主要有跨庫事務、分庫分表以及跨服務事務。

跨庫事務

分庫分表

當對數據庫通過中間件代理的形式進行水平拆分后，不可避免的會在一個事務中操作多個分片節點

跨服務

在服務化的架構下，完成業務功能可能涉及到對多個服務的調用，而這些服務分別會操作不同的數據庫。需要保證跨服務對數據庫的操作要么都成功，要么都失敗，這是服務化場景下面臨的分布式問題。

X/Open DTP模型與XA規范

DTP 模型

X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 這個組織定義的一套分布式事務的標準，也就是了定義了規范和API接口，由廠商進行具體的實現。

模型元素

• 應用程序(Application Program ，簡稱AP)：用于定義事務邊界(即定義事務的開始和結束)，并且在事務邊界內對資源進行操作。
• 資源管理器(Resource Manager，簡稱RM)：如數據庫、文件系統等，并提供訪問資源的方式。
• 事務管理器(Transaction Manager ，簡稱TM)：負責分配事務唯一標識，監控事務的執行進度，并負責事務的提交、回滾等。
• 通信資源管理器(Communication Resource Manager，簡稱CRM)：控制一個TM域(TM domain)內或者跨TM域的分布式應用之間的通信。
• 通信協議(Communication Protocol，簡稱CP)：提供CRM提供的分布式應用節點之間的底層通信服務。

一個DTP模型實例，至少有3個組成部分：AP、RMs、TM。如下所示：

AP通過TM來聲明一個全局事務，然后操作不同的RM上的資源，最后通知TM來提交或者回滾全局事務。AP 可以和 TM 以及 RM 通信，TM 和 RM 互相之間可以通信，DTP模型里面定義了XA接口，TM 和 RM 通過XA接口進行雙向通信，例如:TM通知RM提交事務或者回滾事務，RM把提交結果通知給TM。AP和RM之間則通過RM提供的Native API 進行資源控制，這個沒有進行約API和規范，各個廠商自己實現自己的資源控制，比如Oracle自己的數據庫驅動程序。

XA 規范

在DTP本地模型實例中，由AP、RMs和TM組成，不需要其他元素。AP、RM和TM之間，彼此都需要進行交互，如下圖所示：

上圖中(1)表示AP-RM的交互接口，(2)表示AP-TM的交互接口，(3)表示RM-TM的交互接口
XA規范的最主要的作用是，就是定義了RM-TM的交互接口

XA規范中定義的RM 和 TM交互的接口如下圖所示：

二階段提交

XA規范除了定義的RM-TM交互的接口(XA Interface)之外，還對兩階段提交協議進行了優化。 兩階段協議(two-phase commit)是在OSI TP標準中提出的；在DTP參考模型中，指定了全局事務的提交要使用two-phase commit協議；而XA規范只是定義了兩階段提交協議中需要使用到的接口，也就是上述提到的RM-TM交互的接口，因為兩階段提交過程中的參與方，只有TM和RMs。

• 階段1

TM通知各個RM準備提交它們的事務分支。如果RM判斷自己進行的工作可以被提交，那就就對工作內容進行持久化，再給TM肯定答復；要是發生了其他情況，那給TM的都是否定答復。在發送了否定答復并回滾了已經的工作后，RM就可以丟棄這個事務分支信息。

• 階段2

TM根據階段1各個RM prepare的結果，決定是提交還是回滾事務。如果所有的RM都prepare成功，那么TM通知所有的RM進行提交；如果有RM prepare失敗的話，則TM通知所有RM回滾自己的事務分支。

二階段提交優化

XA規范對兩階段提交協議有2點優化：

• 只讀斷言

在階段1中，RM可以斷言“我這邊不涉及數據增刪改”來答復TM的prepare請求，從而讓這個RM脫離當前的全局事務，從而免去了Phase 2。
這種優化發生在其他RM都完成prepare之前的話，使用了只讀斷言的RM早于AP其他動作（比如說這個RM返回那些只讀數據給AP）前，就釋放了相關數據的上下文（比如讀鎖之類的），這時候其他全局事務或者本地事務就有機會去改變這些數據，結果就是無法保障整個系統的可序列化特性，有臟讀的風險。

• 一階段提交

如果需要增刪改的數據都在同一個RM上，TM可以使用一階段提交跳過兩階段提交中的階段1，直接執行階段2。

二階段提交缺點

同步阻塞

如果對操作讀很敏感，我們需要將事務隔離級別設置為SERIALIZABLE。而對于分布式事務來說，更是如此，可重復讀隔離級別不足以保證分布式事務一致性。

單點故障

一旦協調者TM發生故障。參與者RM會一直阻塞下去。尤其在第二階段，協調者發生故障，那么所有的參與者還都處于鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處于阻塞狀態的問題）

數據不一致

在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。于是整個分布式系統便出現了數據不一致性的現象。

三階段提交

由于二階段提交存在著諸如同步阻塞、單點問題等缺陷，所以，研究者們在二階段提交的基礎上做了改進，提出了三階段提交。
三階段提交（3PC)，是二階段提交（2PC）的改進版本，與兩階段提交不同的是，三階段提交有兩個改動點。

引入超時機制，同時在協調者和參與者中都引入超時機制。

在第一階段和第二階段中插入一個準備階段。保證了在最后提交階段之前各參與節點的狀態是一致的。也就是說，除了引入超時機制之外，3PC把2PC的準備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。

• CanCommit 階段

3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。

• PreCommit 階段

協調者根據參與者的反應情況來決定是否可以繼續事務的PreCommit操作。根據響應情況，有以下兩種可能。
假如協調者從所有的參與者獲得的反饋都是Yes響應，那么就會執行事務的預執行。

發送預提交請求。協調者向參與者發送PreCommit請求，并進入Prepared階段。

事務預提交。參與者接收到PreCommit請求后，會執行事務操作，并將undo和redo信息記錄到事務日志中。

響應反饋。如果參與者成功的執行了事務操作，則返回ACK響應，同時開始等待最終指令。

假如有任何一個參與者向協調者發送了No響應，或者等待超時之后，協調者都沒有接到參與者的響應，那么就執行事務的中斷。

發送中斷請求。協調者向所有參與者發送abort請求。

中斷事務。參與者收到來自協調者的abort請求之后（或超時之后，仍未收到協調者的請求），執行事務的中斷。

• doCommit階段

該階段進行真正的事務提交，也可以分為以下兩種情況。
情況1：執行提交

發送提交請求。協調接收到參與者發送的ACK響應，那么他將從預提交狀態進入到提交狀態。并向所有參與者發送doCommit請求。

事務提交。參與者接收到doCommit請求之后，執行正式的事務提交。并在完成事務提交之后釋放所有事務資源。

響應反饋。事務提交完之后，向協調者發送Ack響應。

完成事務。協調者接收到所有參與者的ack響應之后，完成事務。

情況2：中斷事務（協調者沒有接收到參與者發送的ACK響應）

發送中斷請求。協調者向所有參與者發送abort請求

事務回滾。參與者接收到abort請求之后，利用其在階段二記錄的undo信息來執行事務的回滾操作，并在完成回滾之后釋放所有的事務資源。

反饋結果。參與者完成事務回滾之后，向協調者發送ACK消息

中斷事務。協調者接收到參與者反饋的ACK消息之后，執行事務的中斷。

在doCommit階段，如果參與者無法及時接收到來自協調者的doCommit或者rebort請求時，會在等待超時之后，會繼續進行事務的提交。當進入第三階段時，說明參與者在第二階段已經收到了PreCommit請求，那么協調者產生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應都是Yes。當進入第三階段時，由于網絡超時等原因，雖然參與者沒有收到commit或者abort響應，但是他有理由相信：成功提交的幾率很大。
相對于2PC，3PC主要解決的單點故障問題，并減少阻塞，因為一旦參與者無法及時收到來自協調者的信息之后，他會默認執行commit。而不會一直持有事務資源并處于阻塞狀態。但是這種機制也會導致數據一致性問題，因為，由于網絡原因，協調者發送的abort響應沒有及時被參與者接收到，那么參與者在等待超時之后執行了commit操作。這樣就和其他接到abort命令并執行回滾的參與者之間存在數據不一致的情況。
無論是二階段提交還是三階段提交都無法徹底解決分布式的一致性問題。

CAP理論與BASE柔性事務

CAP 理論

2000年7月，加州大學伯克利分校的 Eric Brewer 教授在分布式計算原則研究會議上提出 CAP 猜想。直到 2002 年，又麻省理工學院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP 理論，從而讓 CAP 理論正式成為分布式計算領域的公認定理。
CAP理論：一個分布式系統最多只能同時滿足一致性（consistency）、可用性（Availability）、分區容錯性（partition-tolerance）這三項中的兩項。
{% asset_img cap.jpg CAP理論模型 %}

一致性

指更新操作成功并返回客戶端完成后，所有節點在同一時間的數據完全一致。

可用性

指系統提供的服務必須一直處于可用的狀態，對于用戶的每一個操作請求總是能夠在有限的時間內返回結果。

分區容錯性

指分布式系統在遇到某節點或網絡分區故障的時候，仍然能對外提供滿足一致性和可用性的服務。

BASE 理論

一個分布式系統無法同時滿足一致性、可用性、分區容錯性三個特點，需要對其進行取舍。對于一個分布式系統而言，分區容錯性是一個最基本的要求，分布式系統中的組件必然需要被部署到不同的節點，網絡問題又是一個必定會出現的異常情況，因此分區容錯性也就成為了一個分布式系統必然需要面對和解決的問題。
eBay的架構師Dan Pritchett源于對大規模分布式系統的實踐總結，在ACM上發表文章提出BASE理論。
BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用可以采用適合的方式達到最終一致性（Eventual Consitency）。
BASE是指Basically Available（基本可用）、Soft state（柔性狀態）和Eventually consistent（最終一致性）

基本可用
指分布式系統在出現不可預知故障的時候，允許損失部分可用性。

柔性狀態

指允許系統中的數據存在中間狀態，并認為該中間狀態的存在不會影響系統的整體可用性。

最終一致

強調的是所有的數據更新操作，在經過一段時間的同步之后，最終都能夠達到一個一致的狀態。
BASE理論面向的是大型高可用可擴展的分布式系統，通過犧牲一致性獲得高可用性。

柔性事務解決方案一般有：最大努力通知、可靠消息最終一致性以及TCC。

參考資料

Distributed Transaction Processing: Reference Model, Version 3
Distributed Transaction Processing:The XA Specification
Atomic Distributed Transactions: a RESTful Design
田守枝的技術博客

總結

以上是生活随笔為你收集整理的分布式事务概览的全部內容，希望文章能夠幫你解決所遇到的問題。

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