事務(wù)是數(shù)據(jù)庫系統(tǒng)中非常有趣也非常重要的概念，它是數(shù)據(jù)庫管理系統(tǒng)執(zhí)行過程中的一個邏輯單元，它能夠保證一個事務(wù)中的所有操作要么全部執(zhí)行，要么全不執(zhí)行;在 SOA 與微服務(wù)架構(gòu)大行其道的今天，在分布式的多個服務(wù)中保證業(yè)務(wù)的一致性就需要我們實現(xiàn)分布式事務(wù)。

[[274102]]

在這篇文章中，我們將介紹 事務(wù)的實現(xiàn)原理、分布式事務(wù)的理論基礎(chǔ)以及實現(xiàn)原理。

事務(wù)

在文章的開頭，我們已經(jīng)說過事務(wù)是數(shù)據(jù)庫管理系統(tǒng)執(zhí)行過程中的一個邏輯單位，它能保證一組數(shù)據(jù)庫操作要么全部執(zhí)行，要么全不執(zhí)行，我們能夠通過事務(wù)將數(shù)據(jù)庫從一個狀態(tài)遷移到另一個狀態(tài)，在每一個狀態(tài)中，數(shù)據(jù)庫中的數(shù)據(jù)都保持一致性。 

database-and-transaction

數(shù)據(jù)庫事務(wù)擁有四個特性，原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)：

transaction-basics

我們經(jīng)常將這上述的四大特性簡寫為 ACID，而數(shù)據(jù)庫事務(wù)的實現(xiàn)原理其實也就是實現(xiàn)這四大特性的原理。

實現(xiàn)原理

在之前的文章 『淺入深出』MySQL 中事務(wù)的實現(xiàn) 中其實已經(jīng)對如何實現(xiàn)事務(wù)的 ACID 這幾個基本屬性給出了比較詳細的介紹和分析，在這里就簡單介紹幾個比較重要的實現(xiàn)細節(jié)，關(guān)于展開的內(nèi)容，可以閱讀上述文章。

事務(wù)日志

為了實現(xiàn)確保事務(wù)能在執(zhí)行的任意過程中回滾(原子性)并且提交的事務(wù)會永久保存在數(shù)據(jù)庫中，我們會使用事務(wù)日志來存儲事務(wù)執(zhí)行過程中的數(shù)據(jù)庫的變動，每一條事務(wù)日志中都包含事務(wù)的 ID、當(dāng)前被修改的元素、變動前以及變動后的值。

Transaction-Log

當(dāng)我們有以上的事務(wù)日志之后，一旦需要對事務(wù)進行回滾就非常容易了，數(shù)據(jù)庫會根據(jù)上述日志生成一個相反的操作恢復(fù)事務(wù)發(fā)生之前的狀態(tài);事務(wù)日志除了能夠?qū)κ聞?wù)進行回滾保證原子性之外，還能夠?qū)崿F(xiàn)持久性，當(dāng)一個事務(wù)常食對數(shù)據(jù)庫進行修改時，它其實會先生成一條日志并刷新到磁盤上，寫日志的操作由于是追加的所以非?？?，在這之后才會向數(shù)據(jù)庫中寫入或者更新對應(yīng)的記錄。

在 MySQL 最常見的存儲引擎 InnoDB 中，事務(wù)日志其實有兩種，一種是回滾日志(undo log)，另一種是重做日志(redo log)，其中前者保證事務(wù)的原子性，后者保證事務(wù)的持久性，兩者可以統(tǒng)稱為事務(wù)日志。

并發(fā)控制

數(shù)據(jù)庫作為最關(guān)鍵的后端服務(wù)，很難想象只能串行執(zhí)行每一個數(shù)據(jù)庫操作帶來的性能影響，然而在并發(fā)執(zhí)行 SQL 的過程中就可能無法保證數(shù)據(jù)庫對于隔離性的要求，歸根結(jié)底這就是一致性、隔離性與性能之間的權(quán)衡。

tradeoff-and-concurrency

為了避免并發(fā)帶來的一致性問題、滿足數(shù)據(jù)庫對于隔離性要求，數(shù)據(jù)庫系統(tǒng)往往都會使用并發(fā)控制機制盡可能地充分利用機器的效率，常見的幾種并發(fā)控制機制就是鎖、時間戳和 MVCC：

concurrency-contro

作為悲觀并發(fā)控制機制，鎖使用在更新資源之前對資源進行鎖定的方式保證多個數(shù)據(jù)庫的會話同時修改某一行記錄時不會出現(xiàn)脫離預(yù)期的行為，而時間戳這種方式在每次提交時對資源是否被改變進行檢查。

分布式事務(wù)

從廣義上來看，分布式事務(wù)其實也是事務(wù)，只是由于業(yè)務(wù)上的定義以及微服務(wù)架構(gòu)設(shè)計的問題，所以需要在多個服務(wù)之間保證業(yè)務(wù)的事務(wù)性，也就是 ACID 四個特性；從單機的數(shù)據(jù)庫事務(wù)變成分布式事務(wù)時，原有單機中相對可靠的方法調(diào)用以及進程間通信方式已經(jīng)沒有辦法使用，同時由于網(wǎng)絡(luò)通信經(jīng)常是不穩(wěn)定的，所以服務(wù)之間信息的傳遞會出現(xiàn)障礙。

tx-and-distributed-tx

模塊(或服務(wù))之間通信方式的改變是造成分布式事務(wù)復(fù)雜的最主要原因，在同一個事務(wù)之間的執(zhí)行多段代碼會因為網(wǎng)絡(luò)的不穩(wěn)定造成各種奇怪的問題，當(dāng)我們通過網(wǎng)絡(luò)請求其他服務(wù)的接口時，往往會得到三種結(jié)果：正確、失敗和超時，無論是成功還是失敗，我們都能得到唯一確定的結(jié)果，超時代表請求的發(fā)起者不能確定接受者是否成功處理了請求，這也是造成諸多問題的誘因。

communication-reliability-and-transaciton

系統(tǒng)之間的通信可靠性從單一系統(tǒng)中的可靠變成了微服務(wù)架構(gòu)之間的不可靠，分布式事務(wù)其實就是在不可靠的通信下實現(xiàn)事務(wù)的特性。無論是事務(wù)還是分布式事務(wù)實現(xiàn)原子性都無法避免對持久存儲的依賴，事務(wù)使用磁盤上的日志記錄執(zhí)行的過程以及上下文，這樣無論是需要回滾還是補償都可以通過日志追溯，而分布式事務(wù)也會依賴數(shù)據(jù)庫、Zookeeper 或者 ETCD 等服務(wù)追蹤事務(wù)的執(zhí)行過程，總而言之，各種形式的日志是保證事務(wù)幾大特性的重要手段。

2PC 與 3PC

兩階段提交是一種使分布式系統(tǒng)中所有節(jié)點在進行事務(wù)提交時保持一致性而設(shè)計的一種協(xié)議;在一個分布式系統(tǒng)中，所有的節(jié)點雖然都可以知道自己執(zhí)行操作后的狀態(tài)，但是無法知道其他節(jié)點執(zhí)行操作的狀態(tài)，在一個事務(wù)跨越多個系統(tǒng)時，就需要引入一個作為協(xié)調(diào)者的組件來統(tǒng)一掌控全部的節(jié)點并指示這些節(jié)點是否把操作結(jié)果進行真正的提交，想要在分布式系統(tǒng)中實現(xiàn)一致性的其他協(xié)議都是在兩階段提交的基礎(chǔ)上做的改進。

two-phase-commit

兩階段提交的執(zhí)行過程就跟它的名字一樣分為兩個階段，投票階段和提交階段，在投票階段中，協(xié)調(diào)者(Coordinator)會向事務(wù)的參與者(Cohort)詢問是否可以執(zhí)行操作的請求，并等待其他參與者的響應(yīng)，參與者會執(zhí)行相對應(yīng)的事務(wù)操作并記錄重做和回滾日志，所有執(zhí)行成功的參與者會向協(xié)調(diào)者發(fā)送 AGREEMENT 或者 ABORT 表示執(zhí)行操作的結(jié)果。

two-phase-commit-voting-phase

當(dāng)所有的參與者都返回了確定的結(jié)果(同意或者終止)時，兩階段提交就進入了提交階段，協(xié)調(diào)者會根據(jù)投票階段的返回情況向所有的參與者發(fā)送提交或者回滾的指令。

two-phase-commit-commit-phase

當(dāng)事務(wù)的所有參與者都決定提交事務(wù)時，協(xié)調(diào)者會向參與者發(fā)送 COMMIT 請求，參與者在完成操作并釋放資源之后向協(xié)調(diào)者返回完成消息，協(xié)調(diào)者在收到所有參與者的完成消息時會結(jié)束整個事務(wù);與之相反，當(dāng)有參與者決定 ABORT 當(dāng)前事務(wù)時，協(xié)調(diào)者會向事務(wù)的參與者發(fā)送回滾請求，參與者會根據(jù)之前執(zhí)行操作時的回滾日志對操作進行回滾并向協(xié)調(diào)者發(fā)送完成的消息，在提交階段，無論當(dāng)前事務(wù)被提交還是回滾，所有的資源都會被釋放并且事務(wù)也一定會結(jié)束。

兩階段提交協(xié)議是一個阻塞協(xié)議，也就是說在兩階段提交的執(zhí)行過程中，除此之外，如果事務(wù)的執(zhí)行過程中協(xié)調(diào)者永久宕機，事務(wù)的一部分參與者將永遠無法完成事務(wù)，它們會等待協(xié)調(diào)者發(fā)送 COMMIT 或者 ROLLBACK 消息，甚至?xí)霈F(xiàn)多個參與者狀態(tài)不一致的問題。

two-phase-commit-problems

3PC

為了解決兩階段提交在協(xié)議的一些問題，三階段提交引入了超時機制和準(zhǔn)備階段，如果協(xié)調(diào)者或者參與者在規(guī)定的之間內(nèi)沒有接受到來自其他節(jié)點的響應(yīng)，就會根據(jù)當(dāng)前的狀態(tài)選擇提交或者終止整個事務(wù)，準(zhǔn)備階段的引入其實讓事務(wù)的參與者有了除回滾之外的其他選擇。

Three-phase_commit_diagra

當(dāng)參與者向協(xié)調(diào)者發(fā)送 ACK 后，如果長時間沒有得到協(xié)調(diào)者的響應(yīng)，在默認情況下，參與者會自動將超時的事務(wù)進行提交，不會像兩階段提交中被阻塞住;上述的圖片非常清楚地說明了在不同階段，協(xié)調(diào)者或者參與者的超時會造成什么樣的行為。

XA 事務(wù)

MySQL 的 InnoDB 引擎其實能夠支持分布式事務(wù)，也就是我們經(jīng)常說的 XA 事務(wù);XA 事務(wù)就是用了我們在上一節(jié)中提到的兩階段提交協(xié)議實現(xiàn)分布式事務(wù)，其中事務(wù)管理器為協(xié)調(diào)者，而資源管理器就是分布式事務(wù)的參與者。

two-phase-commit-and-xa-transaction

到這里，其實我們已經(jīng)能夠清晰地知道 MySQL 中的 XA 事務(wù)是如何實現(xiàn)的：

• 資源管理器提供了訪問事務(wù)資源的能力，數(shù)據(jù)庫就是一種常見的資源管理器，它能夠提交或者回滾其管理的事務(wù);
• 事務(wù)管理器協(xié)調(diào)整個分布式事務(wù)的各個部分，它與多個資源管理器通信，分別處理他們管理的事務(wù)，這些事務(wù)都是整體事務(wù)的一個分支。

distributed-transaction-and-transactions

正如兩階段提交協(xié)議中定義的，MySQL 提供的 XA 接口可以非常方便地實現(xiàn)協(xié)議中的投票和提交階段，我們可以通過一下的流程圖簡單理解一下 MySQL XA 的接口是如何使用的：

mysql-xa-transaction-states

XA 確實能夠保證較強的一致性，但是在 MySQL XA 的執(zhí)行過程中會對相應(yīng)的資源加鎖，阻塞其他事務(wù)對該資源的訪問，如果事務(wù)長時間沒有 COMMIT 或者 ROLLBACK，其實會對數(shù)據(jù)庫造成比較嚴(yán)重的影響。

Saga

兩階段提交其實可以保證事務(wù)的強一致性，但是在很多業(yè)務(wù)場景下，我們其實只需要保證業(yè)務(wù)的最終一致性，在一定的時間窗口內(nèi)，多個系統(tǒng)中的數(shù)據(jù)不一致是可以接受的，在過了時間窗口之后，所有系統(tǒng)都會返回一致的結(jié)果。

Saga 其實就一種簡化的分布式事務(wù)解決方案，它將一系列的分布式操作轉(zhuǎn)化成了一系列的本地事務(wù)，在每一個本地事務(wù)中我們都會更新數(shù)據(jù)庫并且向集群中的其他服務(wù)發(fā)送一條的新的消息來觸發(fā)下一個本地的事務(wù);一旦本地的事務(wù)因為違反了業(yè)務(wù)邏輯而失敗，那么就會立刻觸發(fā)一系列的回滾操作來撤回之前本地事務(wù)造成的副作用。

LLT

相比于本地的數(shù)據(jù)庫事務(wù)來說，長事務(wù)(Long Lived Transaction)會對一些數(shù)據(jù)庫資源持有相對較長的一段時間，這會嚴(yán)重地影響其他正常數(shù)據(jù)庫事務(wù)的執(zhí)行，為了解決這一問題，Hector Garcia-Molina 和 Kenneth Salem 在 1987 發(fā)布了論文 Sagas 用于解決這一問題。

如果一個 LLT 能夠被改寫成一系列的相互交錯重疊的多個數(shù)據(jù)庫事務(wù)，那么這個 LLT 就是一個 Saga;數(shù)據(jù)庫系統(tǒng)能夠保證 Saga 中一系列的事務(wù)要么全部成功執(zhí)行、要么它們的補償事務(wù)能夠回滾全部的副作用，保證整個分布式事務(wù)的最終一致性。Saga 的概念和它的實現(xiàn)都是非常簡單的，但是它卻能夠有很大的潛力增加整個系統(tǒng)的處理能力。

long-lived-transaction-and-transactions

事務(wù)越長并且越復(fù)雜，那么這個事務(wù)由于異常而被回滾以及死鎖的可能性就會逐漸增加，Saga 會將一個 LLT 分解成多個短事務(wù)，能夠非常明顯地降低事務(wù)被回滾的風(fēng)險。

協(xié)同與編排

當(dāng)我們使用 Saga 模式開發(fā)分布式事務(wù)時，有兩種協(xié)調(diào)不同服務(wù)的方式，一種是協(xié)同(Choreography)，另一種是編排(Orchestration)：

saga-pattern

如果對于一個分布式事務(wù)，我們采用協(xié)同的方式進行開發(fā)，每一個本地的事務(wù)都會觸發(fā)一個其他服務(wù)中的本地事務(wù)的執(zhí)行，也就是說事務(wù)的執(zhí)行過程是一個流的形式進行的：

saga-pattern-choreography

當(dāng)我們選擇使用協(xié)同的方式處理事務(wù)時，服務(wù)之間的通信其實就是通過事件進行的，每一個本的事務(wù)最終都會向服務(wù)的下游發(fā)送一個新的事件，既可以是消息隊列中的消息，也可以是 RPC 的請求，只是下游提供的接口需要保證冪等和重入。

除此之外，通過協(xié)同方式創(chuàng)建的分布式事務(wù)其實并沒有明顯的中心化節(jié)點，多個服務(wù)參與者之間的交互協(xié)議要從全局來定義，每個服務(wù)能夠處理以及發(fā)送的事件和接口都需要進行比較嚴(yán)謹?shù)脑O(shè)計，盡可能提供抽象程度高的事件或者接口，這樣各個服務(wù)才能實現(xiàn)自治并重用已有的代碼和邏輯。

如果我們不想使用協(xié)同的方式對分布式事務(wù)進行處理，那么也可以選擇編排的方式實現(xiàn)分布式事務(wù)，編排的方式引入了中心化的協(xié)調(diào)器節(jié)點，我們通過一個 Saga 對象來追蹤所有的子任務(wù)的調(diào)用情況，根據(jù)任務(wù)的調(diào)用情況決定是否需要調(diào)用對應(yīng)的補償方案，并在網(wǎng)絡(luò)請求出現(xiàn)超時時進行重試：

saga-pattern-orchestration

在這里我們就引入了一個中心化的『協(xié)調(diào)器』，它會保存當(dāng)前分布式事務(wù)進行到底的狀態(tài)，并根據(jù)情況對事務(wù)進行回滾或者提交操作，在服務(wù)編排的過程中，我們是從協(xié)調(diào)者本身觸發(fā)考慮整個事務(wù)的執(zhí)行過程的，相對于協(xié)同的方式，編排實現(xiàn)的過程相對來說更為簡單。

協(xié)同與編排其實是兩種思路截然相反的模式，前者強調(diào)各個服務(wù)的自治與去中心化，后者需要一個中心化的組件對事務(wù)執(zhí)行的過程進行統(tǒng)一的管理，兩者的優(yōu)缺點其實就是中心化與去中心化的優(yōu)缺點，中心化的方案往往都會造就一個『上帝服務(wù)』，其中包含了非常多組織與集成其他節(jié)點的工作，也會有單點故障的問題，而去中心化的方案就會帶來管理以及調(diào)試上的不便，當(dāng)我們需要追蹤一個業(yè)務(wù)的執(zhí)行過程時就需要跨越多個服務(wù)進行，增加了維護的成本。

下游約束

當(dāng)我們選擇使用 Saga 對分布式事務(wù)進行開發(fā)時，會對分布式事務(wù)的參與者有一定的約束，每一個事務(wù)的參與者都需要保證：

提供接口和補償副作用的接口;

接口支持重入并通過全局唯一的 ID 保證冪等;

這樣我們就能夠保證一個長事務(wù)能夠在網(wǎng)絡(luò)通信發(fā)生超時時進行重試，同時在需要對事務(wù)進行回滾時調(diào)用回滾接口達到我們的目的。

小結(jié)

Saga 這種模式其實完全放棄了同時滿足事務(wù)四大基本特性 ACID 的想法，而是選擇降低實現(xiàn)分布式事務(wù)的難度并減少資源同步以及鎖定帶來的問題，選擇實現(xiàn) BASE(Basic Availability, Soft, Eventual consistency) 事務(wù)，達到業(yè)務(wù)上的基本可用以及最終一致性，在絕大多數(shù)的業(yè)務(wù)場景中，實現(xiàn)最終一致性就能夠基本滿足業(yè)務(wù)的全部需求，極端場景下還是應(yīng)該選擇兩階段提交或者干脆放棄分布式事務(wù)這種易錯的實現(xiàn)方式，轉(zhuǎn)而使用單機中的數(shù)據(jù)庫事務(wù)來解決。

消息服務(wù)

分布式事務(wù)帶來復(fù)雜度的原因其實就是由于各個模塊之間的通信不穩(wěn)定，當(dāng)我們發(fā)出一個網(wǎng)絡(luò)請求時，可能的返回結(jié)果是成功、失敗或者超時。

network-communication

網(wǎng)絡(luò)無論是返回成功還是失敗其實都是一個確定的結(jié)果，當(dāng)網(wǎng)絡(luò)請求超時的時候其實非常不好處理，在這時調(diào)用方并不能確定這一次請求是否送達而且不會知道請求的結(jié)果，但是消息服務(wù)可以保證某條信息一定會送達到調(diào)用方;大多數(shù)消息服務(wù)都會提供兩種不同的 QoS，也就是服務(wù)的等級。 

message-delivery-qos

最常見的兩種服務(wù)等級就是 At-Most-Once 和 At-Least-Once，前者能夠保證發(fā)送方不對接收方是否能收到消息作保證，消息要么會被投遞一次，要么不會被投遞，這其實跟一次普通的網(wǎng)絡(luò)請求沒有太多的區(qū)別;At-Least-Once 能夠解決消息投遞失敗的問題，它要求發(fā)送者檢查投遞的結(jié)果，并在失敗或者超時時重新對消息進行投遞，發(fā)送者會持續(xù)對消息進行推送，直到接受者確認消息已經(jīng)被收到，相比于 At-Most-Once，At-Least-Once 因為能夠確保消息的投遞會被更多人使用。

除了這兩種常見的服務(wù)等級之外，還有另一種服務(wù)等級，也就是 Exactly-Once，這種服務(wù)等級不僅對發(fā)送者提出了要求，還對消費者提出了要求，它需要接受者對接收到的所有消息進行去重，發(fā)送者和接受者一方對消息進行重試，另一方對消息進行去重，兩者分別部署在不同的節(jié)點上，這樣對于各個節(jié)點上的服務(wù)來說，它們之間的通信就是 Exactly-Once 的，但是需要注意的是，Exacly-Once 一定需要接收方的參與。

我們可以通過實現(xiàn) AMQP 協(xié)議的消息隊列來實現(xiàn)分布式事務(wù)，在協(xié)議的標(biāo)準(zhǔn)中定義了 tx_select、tx_commit 和 tx_rollback 三個事務(wù)相關(guān)的接口，其中 tx_select能夠開啟事務(wù)，tx_commit 和 tx_rollback 分別能夠提交或者回滾事務(wù)。

使用消息服務(wù)實現(xiàn)分布式事務(wù)在底層的原理上與其他的方法沒有太多的差別，只是消息服務(wù)能夠幫助我們實現(xiàn)的消息的持久化以及重試等功能，能夠為我們提供一個比較合理的 API 接口，方便開發(fā)者使用。

總結(jié)

分布式事務(wù)的實現(xiàn)方式是分布式系統(tǒng)中非常重要的一個問題，在微服務(wù)架構(gòu)和 SOA 大行其道的今天，掌握分布式事務(wù)的原理和使用方式已經(jīng)是作為后端開發(fā)者理所應(yīng)當(dāng)掌握的技能，從實現(xiàn) ACID 事務(wù)的 2PC 與 3PC 到實現(xiàn) BASE 補償式事務(wù)的 Saga，再到最后通過事務(wù)消息的方式異步地保證消息最終一定會被消費成功，我們?yōu)榱嗽黾酉到y(tǒng)的吞吐量以及可用性逐漸降低了系統(tǒng)對一致性的要求。

在業(yè)務(wù)沒有對一致性有那么強的需求時，作者一般會使用 Saga 協(xié)議對分布式事務(wù)進行設(shè)計和開發(fā)，而在實際工作中，需要強一致性事務(wù)的業(yè)務(wù)場景幾乎沒有，我們都可以實現(xiàn)最終一致性，在發(fā)生腦裂或者不一致問題時通過補償?shù)姆绞竭M行解決，這就能解決幾乎全部的問題。

Reference

Database transaction · Wikipedia

『淺入深出』MySQL 中事務(wù)的實現(xiàn)

MySQL · 特性分析 · 淺談 MySQL 5.7 XA 事務(wù)改進

XA Transactions

Two-phase commit protocol

Pattern: Saga

Sagas

RocketMQ 4.3正式發(fā)布，支持分布式事務(wù)

Akka Message Delivery - At-Most-Once, At-Least-Once, and Exactly-Once

Part 1 At-Most-Once

Part 2 At-Least-Once

Part 3 Exactly-Once

Message Delivery Reliability