不知道你是否遇到過這樣的情況，去小賣鋪買東西，付了錢，但是店主因為處理了一些其他事，居然忘記你付了錢，又叫你重新付。又或者在網(wǎng)上購物明明已經(jīng)扣款，但是卻告訴我沒有發(fā)生交易。這一系列情況都是因為沒有事務導致的。這說明了事務在生活中的一些重要性。有了事務，你去小賣鋪買東西，那就是一手交錢一手交貨。有了事務，你去網(wǎng)上購物，扣款即產(chǎn)生訂單交易。

事務的具體定義

事務提供一種機制將一個活動涉及的所有操作納入到一個不可分割的執(zhí)行單元，組成事務的所有操作只有在所有操作均能正常執(zhí)行的情況下方能提交，只要其中任一操作執(zhí)行失敗，都將導致整個事務的回滾。簡單地說，事務提供一種“要么什么都不做，要么做全套（All or Nothing）”機制。

數(shù)據(jù)庫本地事務

ACID

說到數(shù)據(jù)庫事務就不得不說，數(shù)據(jù)庫事務中的四大特性，ACID:

• A:原子性(Atomicity)

一個事務(transaction)中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環(huán)節(jié)。事務在執(zhí)行過程中發(fā)生錯誤，會被回滾（Rollback）到事務開始前的狀態(tài)，就像這個事務從來沒有執(zhí)行過一樣。

就像你買東西要么交錢收貨一起都執(zhí)行，要么要是發(fā)不出貨，就退錢。

• C:一致性(Consistency)

事務的一致性指的是在一個事務執(zhí)行之前和執(zhí)行之后數(shù)據(jù)庫都必須處于一致性狀態(tài)。如果事務成功地完成，那么系統(tǒng)中所有變化將正確地應用，系統(tǒng)處于有效狀態(tài)。如果在事務中出現(xiàn)錯誤，那么系統(tǒng)中的所有變化將自動地回滾，系統(tǒng)返回到原始狀態(tài)。

• I:隔離性(Isolation)

指的是在并發(fā)環(huán)境中，當不同的事務同時操縱相同的數(shù)據(jù)時，每個事務都有各自的完整數(shù)據(jù)空間。由并發(fā)事務所做的修改必須與任何其他并發(fā)事務所做的修改隔離。事務查看數(shù)據(jù)更新時，數(shù)據(jù)所處的狀態(tài)要么是另一事務修改它之前的狀態(tài)，要么是另一事務修改它之后的狀態(tài)，事務不會查看到中間狀態(tài)的數(shù)據(jù)。

打個比方，你買東西這個事情，是不影響其他人的。

• D:持久性(Durability)

指的是只要事務成功結束，它對數(shù)據(jù)庫所做的更新就必須***保存下來。即使發(fā)生系統(tǒng)崩潰，重新啟動數(shù)據(jù)庫系統(tǒng)后，數(shù)據(jù)庫還能恢復到事務成功結束時的狀態(tài)。

打個比方，你買東西的時候需要記錄在賬本上，即使老板忘記了那也有據(jù)可查。

InnoDB實現(xiàn)原理

InnoDB是mysql的一個存儲引擎，大部分人對mysql都比較熟悉，這里簡單介紹一下數(shù)據(jù)庫事務實現(xiàn)的一些基本原理，在本地事務中，服務和資源在事務的包裹下可以看做是一體的:

而事務的ACID是通過InnoDB日志和鎖來保證。事務的隔離性是通過數(shù)據(jù)庫鎖的機制實現(xiàn)的，持久性通過redo log（重做日志）來實現(xiàn)，原子性和一致性通過Undo log來實現(xiàn)。UndoLog的原理很簡單，為了滿足事務的原子性，在操作任何數(shù)據(jù)之前，首先將數(shù)據(jù)備份到一個地方（這個存儲數(shù)據(jù)備份的地方稱為UndoLog）。然后進行數(shù)據(jù)的修改。如果出現(xiàn)了錯誤或者用戶執(zhí)行了ROLLBACK語句，系統(tǒng)可以利用Undo Log中的備份將數(shù)據(jù)恢復到事務開始之前的狀態(tài)。 和Undo Log相反，RedoLog記錄的是新數(shù)據(jù)的備份。在事務提交前，只要將RedoLog持久化即可，不需要將數(shù)據(jù)持久化。當系統(tǒng)崩潰時，雖然數(shù)據(jù)沒有持久化，但是RedoLog已經(jīng)持久化。系統(tǒng)可以根據(jù)RedoLog的內(nèi)容，將所有數(shù)據(jù)恢復到***的狀態(tài)。 對具體實現(xiàn)過程有興趣的同學可以去自行搜索擴展。

分布式事務

什么是分布式事務

分布式事務就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬于不同的應用，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。本質上來說，分布式事務就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

分布式事務產(chǎn)生的原因

從上面本地事務來看，我們可以看為兩塊，一個是service產(chǎn)生多個節(jié)點，另一個是resource產(chǎn)生多個節(jié)點。

service多個節(jié)點

隨著互聯(lián)網(wǎng)快速發(fā)展，微服務，SOA等服務架構模式正在被大規(guī)模的使用，舉個簡單的例子，一個公司之內(nèi)，用戶的資產(chǎn)可能分為好多個部分，比如余額，積分，優(yōu)惠券等等。在公司內(nèi)部有可能積分功能由一個微服務團隊維護，優(yōu)惠券又是另外的團隊維護

resource多個節(jié)點

同樣的，互聯(lián)網(wǎng)發(fā)展得太快了，我們的Mysql一般來說裝***的數(shù)據(jù)就得進行分庫分表，對于一個支付寶的轉賬業(yè)務來說，你給的朋友轉錢，有可能你的數(shù)據(jù)庫是在北京，而你的朋友的錢是存在上海，所以我們依然無法保證他們能同時成功。

從上面來看分布式事務是隨著互聯(lián)網(wǎng)高速發(fā)展應運而生的，這是一個必然的我們之前說過數(shù)據(jù)庫的ACID四大特性，已經(jīng)無法滿足我們分布式事務，這個時候又有一些新的大佬提出一些新的理論:

CAP

CAP定理，又被叫作布魯爾定理。對于設計分布式系統(tǒng)來說(不僅僅是分布式事務)的架構師來說，CAP就是你的入門理論。

• C (一致性):對某個指定的客戶端來說，讀操作能返回***的寫操作。對于數(shù)據(jù)分布在不同節(jié)點上的數(shù)據(jù)上來說，如果在某個節(jié)點更新了數(shù)據(jù)，那么在其他節(jié)點如果都能讀取到這個***的數(shù)據(jù)，那么就稱為強一致，如果有某個節(jié)點沒有讀取到，那就是分布式不一致。
• A (可用性)：非故障的節(jié)點在合理的時間內(nèi)返回合理的響應(不是錯誤和超時的響應)?？捎眯缘膬蓚€關鍵一個是合理的時間，一個是合理的響應。合理的時間指的是請求不能***被阻塞，應該在合理的時間給出返回。合理的響應指的是系統(tǒng)應該明確返回結果并且結果是正確的，這里的正確指的是比如應該返回50，而不是返回40。
• P (分區(qū)容錯性):當出現(xiàn)網(wǎng)絡分區(qū)后，系統(tǒng)能夠繼續(xù)工作。打個比方，這里個集群有多臺機器，有臺機器網(wǎng)絡出現(xiàn)了問題，但是這個集群仍然可以正常工作。

熟悉CAP的人都知道，三者不能共有，如果感興趣可以搜索CAP的證明，在分布式系統(tǒng)中，網(wǎng)絡無法100%可靠，分區(qū)其實是一個必然現(xiàn)象，如果我們選擇了CA而放棄了P，那么當發(fā)生分區(qū)現(xiàn)象時，為了保證一致性，這個時候必須拒絕請求，但是A又不允許，所以分布式系統(tǒng)理論上不可能選擇CA架構，只能選擇CP或者AP架構。

對于CP來說，放棄可用性，追求一致性和分區(qū)容錯性，我們的zookeeper其實就是追求的強一致。

對于AP來說，放棄一致性(這里說的一致性是強一致性)，追求分區(qū)容錯性和可用性，這是很多分布式系統(tǒng)設計時的選擇，后面的BASE也是根據(jù)AP來擴展。

順便一提，CAP理論中是忽略網(wǎng)絡延遲，也就是當事務提交時，從節(jié)點A復制到節(jié)點B，但是在現(xiàn)實中這個是明顯不可能的，所以總會有一定的時間是不一致。同時CAP中選擇兩個，比如你選擇了CP，并不是叫你放棄A。因為P出現(xiàn)的概率實在是太小了，大部分的時間你仍然需要保證CA。就算分區(qū)出現(xiàn)了你也要為后來的A做準備，比如通過一些日志的手段，是其他機器回復至可用。

BASE

BASE 是 Basically Available(基本可用)、Soft state(軟狀態(tài))和 Eventually consistent (最終一致性)三個短語的縮寫。是對CAP中AP的一個擴展

1. 基本可用:分布式系統(tǒng)在出現(xiàn)故障時，允許損失部分可用功能，保證核心功能可用。
2. 軟狀態(tài):允許系統(tǒng)中存在中間狀態(tài)，這個狀態(tài)不影響系統(tǒng)可用性，這里指的是CAP中的不一致。
3. 最終一致:最終一致是指經(jīng)過一段時間后，所有節(jié)點數(shù)據(jù)都將會達到一致。

BASE解決了CAP中理論沒有網(wǎng)絡延遲，在BASE中用軟狀態(tài)和最終一致，保證了延遲后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的強一致性模型，而是通過犧牲強一致性來獲得可用性，并允許數(shù)據(jù)在一段時間內(nèi)是不一致的，但最終達到一致狀態(tài)。

分布式事務解決方案

有了上面的理論基礎后，這里介紹開始介紹幾種常見的分布式事務的解決方案。

是否真的要分布式事務

在說方案之前，首先你一定要明確你是否真的需要分布式事務？

上面說過出現(xiàn)分布式事務的兩個原因，其中有個原因是因為微服務過多。我見過太多團隊一個人維護幾個微服務，太多團隊過度設計，搞得所有人疲勞不堪，而微服務過多就會引出分布式事務，這個時候我不會建議你去采用下面任何一種方案，而是請把需要事務的微服務聚合成一個單機服務，使用數(shù)據(jù)庫的本地事務。因為不論任何一種方案都會增加你系統(tǒng)的復雜度，這樣的成本實在是太高了，千萬不要因為追求某些設計，而引入不必要的成本和復雜度。

如果你確定需要引入分布式事務可以看看下面幾種常見的方案。

2PC

說到2PC就不得不聊數(shù)據(jù)庫分布式事務中的 XA Transactions。

***階段：事務管理器要求每個涉及到事務的數(shù)據(jù)庫預提交(precommit)此操作，并反映是否可以提交.

第二階段：事務協(xié)調(diào)器要求每個數(shù)據(jù)庫提交數(shù)據(jù)，或者回滾數(shù)據(jù)。

優(yōu)點： 盡量保證了數(shù)據(jù)的強一致，實現(xiàn)成本較低，在各大主流數(shù)據(jù)庫都有自己實現(xiàn)，對于MySQL是從5.5開始支持。

缺點:

• 單點問題:事務管理器在整個流程中扮演的角色很關鍵，如果其宕機，比如在***階段已經(jīng)完成，在第二階段正準備提交的時候事務管理器宕機，資源管理器就會一直阻塞，導致數(shù)據(jù)庫無法使用。
• 同步阻塞:在準備就緒之后，資源管理器中的資源一直處于阻塞，直到提交完成，釋放資源。
• 數(shù)據(jù)不一致:兩階段提交協(xié)議雖然為分布式數(shù)據(jù)強一致性所設計，但仍然存在數(shù)據(jù)不一致性的可能，比如在第二階段中，假設協(xié)調(diào)者發(fā)出了事務commit的通知，但是因為網(wǎng)絡問題該通知僅被一部分參與者所收到并執(zhí)行了commit操作，其余的參與者則因為沒有收到通知一直處于阻塞狀態(tài)，這時候就產(chǎn)生了數(shù)據(jù)的不一致性。

總的來說，XA協(xié)議比較簡單，成本較低，但是其單點問題，以及不能支持高并發(fā)(由于同步阻塞)依然是其***的弱點。

TCC

關于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年發(fā)表的一篇名為《Life beyond Distributed Transactions:an Apostate’s Opinion》的論文提出。 TCC事務機制相比于上面介紹的XA，解決了其幾個缺點: 1.解決了協(xié)調(diào)者單點，由主業(yè)務方發(fā)起并完成這個業(yè)務活動。業(yè)務活動管理器也變成多點，引入集群。 2.同步阻塞:引入超時，超時后進行補償，并且不會鎖定整個資源，將資源轉換為業(yè)務邏輯形式，粒度變小。 3.數(shù)據(jù)一致性，有了補償機制之后，由業(yè)務活動管理器控制一致性

• Try階段：嘗試執(zhí)行,完成所有業(yè)務檢查（一致性）,預留必須業(yè)務資源（準隔離性）

• Confirm階段：確認執(zhí)行真正執(zhí)行業(yè)務，不作任何業(yè)務檢查，只使用Try階段預留的業(yè)務資源，Confirm操作滿足冪等性。要求具備冪等設計，Confirm失敗后需要進行重試。

• Cancel階段：取消執(zhí)行，釋放Try階段預留的業(yè)務資源 Cancel操作滿足冪等性Cancel階段的異常和Confirm階段異常處理方案基本上一致。

舉個簡單的例子如果你用100元買了一瓶水， Try階段:你需要向你的錢包檢查是否夠100元并鎖住這100元，水也是一樣的。

如果有一個失敗，則進行cancel(釋放這100元和這一瓶水)，如果cancel失敗不論什么失敗都進行重試cancel，所以需要保持冪等。

如果都成功，則進行confirm,確認這100元扣，和這一瓶水被賣，如果confirm失敗無論什么失敗則重試(會依靠活動日志進行重試)

對于TCC來說適合一些:

• 強隔離性，嚴格一致性要求的活動業(yè)務。
• 執(zhí)行時間較短的業(yè)務

實現(xiàn)參考:ByteTCC:https://github.com/liuyangming/ByteTCC/

本地消息表

本地消息表這個方案最初是ebay提出的 ebay的完整方案https://queue.acm.org/detail.cfm?id=1394128。

此方案的核心是將需要分布式處理的任務通過消息日志的方式來異步執(zhí)行。消息日志可以存儲到本地文本、數(shù)據(jù)庫或消息隊列，再通過業(yè)務規(guī)則自動或人工發(fā)起重試。人工重試更多的是應用于支付場景，通過對賬系統(tǒng)對事后問題的處理。

對于本地消息隊列來說核心是把大事務轉變?yōu)樾∈聞?。還是舉上面用100元去買一瓶水的例子。

1.當你扣錢的時候，你需要在你扣錢的服務器上新增加一個本地消息表，你需要把你扣錢和寫入減去水的庫存到本地消息表放入同一個事務(依靠數(shù)據(jù)庫本地事務保證一致性。

2.這個時候有個定時任務去輪詢這個本地事務表，把沒有發(fā)送的消息，扔給商品庫存服務器，叫他減去水的庫存，到達商品服務器之后這個時候得先寫入這個服務器的事務表，然后進行扣減，扣減成功后，更新事務表中的狀態(tài)。

3.商品服務器通過定時任務掃描消息表或者直接通知扣錢服務器，扣錢服務器本地消息表進行狀態(tài)更新。

4.針對一些異常情況，定時掃描未成功處理的消息，進行重新發(fā)送，在商品服務器接到消息之后，首先判斷是否是重復的，如果已經(jīng)接收，在判斷是否執(zhí)行，如果執(zhí)行在馬上又進行通知事務，如果未執(zhí)行，需要重新執(zhí)行需要由業(yè)務保證冪等，也就是不會多扣一瓶水。

本地消息隊列是BASE理論，是最終一致模型，適用于對一致性要求不高的。實現(xiàn)這個模型時需要注意重試的冪等。

MQ事務

基本流程如下: ***階段Prepared消息，會拿到消息的地址。

第二階段執(zhí)行本地事務。

第三階段通過***階段拿到的地址去訪問消息，并修改狀態(tài)。消息接受者就能使用這個消息。

如果消費超時，則需要一直重試，消息接收端需要保證冪等。如果消息消費失敗，這個就需要人工進行處理，因為這個概率較低，如果為了這種小概率時間而設計這個復雜的流程反而得不償失

Saga事務

Saga是30年前一篇數(shù)據(jù)庫倫理提到的一個概念。其核心思想是將長事務拆分為多個本地短事務，由Saga事務協(xié)調(diào)器協(xié)調(diào)，如果正常結束那就正常完成，如果某個步驟失敗，則根據(jù)相反順序一次調(diào)用補償操作。 Saga的組成：

每個Saga由一系列sub-transaction Ti 組成 每個Ti 都有對應的補償動作Ci，補償動作用于撤銷Ti造成的結果,這里的每個T，都是一個本地事務。 可以看到，和TCC相比，Saga沒有“預留 try”動作，它的Ti就是直接提交到庫。

Saga的執(zhí)行順序有兩種：

T1, T2, T3, ..., Tn

T1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < n Saga定義了兩種恢復策略：

向后恢復，即上面提到的第二種執(zhí)行順序，其中j是發(fā)生錯誤的sub-transaction，這種做法的效果是撤銷掉之前所有成功的sub-transation，使得整個Saga的執(zhí)行結果撤銷。 向前恢復，適用于必須要成功的場景，執(zhí)行順序是類似于這樣的：T1, T2, ..., Tj(失敗), Tj(重試),..., Tn，其中j是發(fā)生錯誤的sub-transaction。該情況下不需要Ci。

這里要注意的是，在saga模式中不能保證隔離性，因為沒有鎖住資源，其他事務依然可以覆蓋或者影響當前事務。

還是拿100元買一瓶水的例子來說，這里定義

T1=扣100元 T2=給用戶加一瓶水 T3=減庫存一瓶水

C1=加100元 C2=給用戶減一瓶水 C3=給庫存加一瓶水

我們一次進行T1,T2，T3如果發(fā)生問題，就執(zhí)行發(fā)生問題的C操作的反向。 上面說到的隔離性的問題會出現(xiàn)在，如果執(zhí)行到T3這個時候需要執(zhí)行回滾，但是這個用戶已經(jīng)把水喝了(另外一個事務)，回滾的時候就會發(fā)現(xiàn)，無法給用戶減一瓶水了。這就是事務之間沒有隔離性的問題

可以看見saga模式?jīng)]有隔離性的影響還是較大，可以參照華為的解決方案:從業(yè)務層面入手加入一 Session 以及鎖的機制來保證能夠串行化操作資源。也可以在業(yè)務層面通過預先凍結資金的方式隔離這部分資源， ***在業(yè)務操作的過程中可以通過及時讀取當前狀態(tài)的方式獲取到***的更新。

具體實例:可以參考華為的servicecomb

***

還是那句話，能不用分布式事務就不用，如果非得使用的話，結合自己的業(yè)務分析，看看自己的業(yè)務比較適合哪一種，是在乎強一致，還是最終一致即可。上面對解決方案只是一些簡單介紹，如果真正的想要落地，其實每種方案需要思考的地方都非常多，復雜度都比較大，所以***再次提醒一定要判斷好是否使用分布式事務。***在總結一些問題,大家可以下來自己從文章找尋答案:

1. ACID和CAP的 CA是一樣的嗎？
2. 分布式事務常用的解決方案的優(yōu)缺點是什么？適用于什么場景？
3. 分布式事務出現(xiàn)的原因？用來解決什么痛點？