事務的具體定義

事務(Transaction)是訪問并可能更新數據庫中各種數據項的一個程序執(zhí)行單元(unit)。在關系數據庫中，一個事務由一組SQL語句組成。事務應該具有4個屬性：原子性、一致性、隔離性、持久性。這四個屬性通常稱為ACID特性。
事務提供一種機制將一個活動涉及的所有操作納入到一個不可分割的執(zhí)行單元，組成事務的所有操作只有在所有操作均能正常執(zhí)行的情況下方能提交，只要其中任一操作執(zhí)行失敗，都將導致整個事務的回滾。

簡單地說，事務提供一種“要么什么都不做，要么做全套（All or Nothing）”機制。

數據庫本地事務

在計算機系統中，更多的是通過關系型數據庫來控制事務，這是利用數據庫本身的事務特性來實現的，因此叫數據庫事務，由于應用主要靠關系數據庫來控制事務，而數據庫通常和應用在同一個服務器，所以基于關系型數據庫的事務又被稱為本地事務。
回顧一下數據庫事務的四大特性 ACID：

說到數據庫事務就不得不說，數據庫事務中的四大特性 ACID：

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

• 在 MySQL 中，原子性通過回滾日志（Undo Log）來實現。當事務執(zhí)行時，MySQL 將所有操作的結果記錄到回滾日志中，如果事務執(zhí)行失敗，MySQL 將通過回滾日志將所有操作回滾到執(zhí)行前的狀態(tài)。

C：一致性(Consistency)：事務的一致性指的是在一個事務執(zhí)行之前和執(zhí)行之后數據庫都必須處于一致性狀態(tài)。

• 如果事務成功地完成，那么系統中所有變化將正確地應用，系統處于有效狀態(tài)。
• 如果在事務中出現錯誤，那么系統中的所有變化將自動地回滾，系統返回到原始狀態(tài)。
• 在 MySQL 中，一致性通過使用鎖來實現。當事務執(zhí)行時，MySQL 會對需要修改的數據行加鎖，以防止其他事務對數據的修改導致不一致。

I：隔離性(Isolation)：指的是在并發(fā)環(huán)境中，當不同的事務同時操縱相同的數據時，每個事務都有各自的完整數據空間。

由并發(fā)事務所做的修改必須與任何其他并發(fā)事務所做的修改隔離。事務查看數據更新時，數據所處的狀態(tài)要么是另一事務修改它之前的狀態(tài)，要么是另一事務修改它之后的狀態(tài)，事務不會查看到中間狀態(tài)的數據。

• 在 MySQL 中，隔離性通過使用鎖和 MVCC（多版本并發(fā)控制）來實現。MVCC 是指對于每個修改操作，MySQL 會保存一份舊的數據版本，并通過版本號來控制事務的隔離級別。

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

• 在 MySQL 中，持久性通過使用重做日志（Redo Log）來實現。當事務提交時，MySQL 將事務的修改操作記錄到重做日志中，以確保數據的持久性。

分布式事務

隨著互聯網的快速發(fā)展，軟件系統由原來的單體應用轉變?yōu)榉植际綉?，隨著應用服務化，出現各個微服務，以及這些服務對應的庫表，多個庫表之間的數據操作可能需要保證原子性。

下圖描述了單體應用向微服務的演變：

分布式系統會把一個應用系統拆分為可獨立部署的多個服務，因此需要服務與服務之間遠程協作才能完成事務操作，這種分布式系統環(huán)境下由不同的服務之間通過網絡遠程協作完成事務稱之為分布式事務，例如用戶注冊送積分事務、創(chuàng)建訂單減庫存事務，銀行轉賬事務等都是分布式事務。

分布式事務基礎理論

CAP定理

CAP定理，又被叫作布魯爾定理。對于設計分布式系統來說(不僅僅是分布式事務)的架構師來說，CAP就是你的入門理論。
CAP理論告訴我們，一個分布式系統不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）和分區(qū)容錯性（P：Partion tolerance）這三個基本需求，最多只能同時滿足其中的兩項。

C - Consistency(一致性)：

在分布式環(huán)境下，一致性是指數據在多個副本之間是否能夠保持一致的特性。對某個指定的客戶端來說，讀操作能返回最新的寫操作。對于數據分布在不同節(jié)點上的數據上來說，如果在某個節(jié)點更新了數據，那么在其他節(jié)點如果都能讀取到這個最新的數據，那么就稱為強一致，如果有某個節(jié)點沒有讀取到，那就是分布式不一致。

如何實現一致性？

• 1、寫入主數據庫后要將數據同步到從數據庫。
• 2、寫入主數據庫后，在向從數據庫同步期間要將從數據庫鎖定，待同步完成后再釋放鎖，以免在新數據寫入成功后，向從數據庫查詢到舊的數據。

分布式系統一致性的特點：

• 1、由于存在數據同步的過程，寫操作的響應會有一定的延遲。
• 2、為了保證數據一致性會對資源暫時鎖定，待數據同步完成釋放鎖定資源。
• 3、如果請求數據同步失敗的結點則會返回錯誤信息，一定不會返回舊數據。

A - Availability(可用性)：

可用性是指系統提供的服務必須一直處于可用的狀態(tài)，對于用戶的每一個操作請求總是能夠在有限的時間內返回正確結果。非故障的節(jié)點在合理的時間內返回合理的響應(不是錯誤和超時的響應)?？捎眯缘膬蓚€關鍵一個是合理的時間，一個是合理的響應。合理的時間指的是請求不能無限被阻塞，應該在合理的時間給出返回。合理的響應指的是系統應該明確返回結果并且結果是正確的，這里的正確指的是比如應該返回50，而不是返回40。

如何實現可用性？

• 1、寫入主數據庫后要將數據同步到從數據庫。
• 2、由于要保證從數據庫的可用性，不可將從數據庫中的資源進行鎖定。
• 3、即使數據還沒有同步過來，從數據庫也要返回要查詢的數據，哪怕是舊數據，如果連舊數據也沒有則可以按照約定返回一個默認信息，但不能返回錯誤或響應超時。

分布式系統可用性的特點：

• 1、 所有請求都有響應，且不會出現響應超時或響應錯誤。

P - Partition tolerance(分區(qū)容錯性)：

分布式系統在遇到任何網絡分區(qū)故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網絡環(huán)境都發(fā)生了故障。打個比方，這里個集群有多臺機器，有臺機器網絡出現了問題，但是這個集群仍然可以正常工作。

網絡分區(qū)是指在分布式系統中，不同的節(jié)點分布在不同的子網絡（機房或異地網絡等）中，由于一些特殊的原因導致這些子網絡之間出現網絡不連通的狀況，但各個子網絡的內部網絡是正常的，從而導致整個系統的網絡環(huán)境被切分成了若干孤立的區(qū)域。需要注意的是，組成一個分布式系統的每個節(jié)點的加入與退出都可以看作是一個特殊的網絡分區(qū)。

如何實現分區(qū)容錯性？

• 1、盡量使用異步取代同步操作，例如使用異步方式將數據從主數據庫同步到從數據，這樣結點之間能有效的實現松耦合。
• 2、添加從數據庫結點，其中一個從結點掛掉其它從結點提供服務。

分布式分區(qū)容錯性的特點：
1、分區(qū)容錯性分是布式系統具備的基本能力。

CAP組合方式

熟悉CAP的人都知道，三者不能共有。在所有分布式事務場景中不會同時具備CAP三個特性，因為在具備了P的前提下C和A是不能共存的。

在分布式系統中，網絡無法100%可靠，分區(qū)其實是一個必然現象，如果我們選擇了CA而放棄了P，那么當發(fā)生分區(qū)現象時，為了保證一致性，這個時候必須拒絕請求，但是A又不允許，所以分布式系統理論上不可能選擇CA架構，只能選擇CP或者AP架構。

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

CAP有哪些組合方式呢？

所以在生產中對分布式事務處理時要根據需求來確定滿足CAP的哪兩個方面。
1）AP：
放棄一致性(這里說的一致性是強一致性)，追求分區(qū)容錯性和可用性。這是很多分布式系統設計時的選擇。

通常實現AP都會保證最終一致性，后面講的BASE理論就是根據AP來擴展的，一些業(yè)務場景 比如：訂單退款，今日退款成功，明日賬戶到賬，只要用戶可以接受在一定時間內到賬即可。

2）CP：
放棄可用性，追求一致性和分區(qū)容錯性，我們的zookeeper其實就是追求的強一致，又比如跨行轉賬，一次轉賬請求要等待雙方銀行系統都完成整個事務才算完成。

3）CA：
放棄分區(qū)容忍性，即不進行分區(qū)，不考慮由于網絡不通或結點掛掉的問題，則可以實現一致性和可用性。那么系統將不是一個標準的分布式系統，我們最常用的關系型數據就滿足了CA。

階段總結

• CAP是一個已經被證實的理論，一個分布式系統最多只能同時滿足一致性（Consistency）、可用性（Availability）和分區(qū)容忍性（Partition tolerance）這三項中的兩項。
• 它可以作為我們進行架構設計、技術選型的考量標準。對于多數大型互聯網應用的場景，結點眾多、部署分散，而且現在的集群規(guī)模越來越大，所以節(jié)點故障、網絡故障是常態(tài)，而且要保證服務可用性達到N個9（99.99..%），并要達到良好的響應性能來提高用戶體驗，因此一般都會做出如下選擇：保證P和A，舍棄C強一致，保證最終一致性。

BASE理論

1、理解強一致性和最終一致性
CAP理論告訴我們一個分布式系統最多只能同時滿足一致性（Consistency）、可用性（Availability）和分區(qū)容忍性（Partition tolerance）這三項中的兩項，其中AP在實際應用中較多，AP即舍棄一致性，保證可用性和分區(qū)容忍性，但是在實際生產中很多場景都要實現一致性，比如主數據庫向從數據庫同步數據，即使不要一致性，但是最終也要將數據同步成功來保證數據一致，這種一致性和CAP中的一致性不同，CAP中的一致性要求在任何時間查詢每個結點數據都必須一致，它強調的是強一致性，但是最終一致性是允許可以在一段時間內每個結點的數據不一致，但是經過一段時間每個結點的數據必須一致，它強調的是最終數據的一致性。

BASE是Basically Available(基本可用)、Soft state(軟狀態(tài))和Eventually consistent (最終一致性)三個短語的縮寫。BASE理論是對CAP中AP的一個擴展，通過犧牲強一致性來獲得可用性，當出現故障允許部分不可用但要保證核心功能可用，允許數據在一段時間內是不一致的，但最終達到一致狀態(tài)。滿足BASE理論的事務，我們稱之為“柔性事務”。

BASE理論指的是：

Basically Available（基本可用）：允許響應時間拉長，允許功能上的損失，允許降級頁面（系統繁忙，稍后重試等），即分布式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。如，電商網站交易付款出現問題了，商品依然可以正常瀏覽。

Soft state（軟狀態(tài)）：是指允許系統中的數據存在中間狀態(tài)，并認為該中間狀態(tài)的存在不會影響系統的整體可用性。如訂單的"支付中"、“數據同步中”等狀態(tài)，待數據最終一致后狀態(tài)改為“成功”狀態(tài)。

Eventually consistent（最終一致性）：本質就是需要保證最終數據能夠達到一致性，而不需要實時保證系統數據的強一致性。如訂單的"支付中"狀態(tài)，最終會變?yōu)椤爸Ц冻晒Α被蛘?支付失敗"，使訂單狀態(tài)與實際交易結果達成一致，但需要一定時間的延遲、等待。

分布式事務解決方案

以理論為基礎，針對不同的分布式場景業(yè)界常見的解決方案有2PC、TCC、可靠消息最終一致性、最大努力通知這幾種。

兩階段提交：分布式事務兩階段提交——XA方案 Seata方案

TCC方案：分布式事務TCC方案——Hmily方案

可靠消息最終一致性：分布式事務解決方案——可靠消息最終一致性

最大努力通知：分布式事務解決方案——最大努力通知

分布式事務對比分析:

2階段提交(2PC)：

最大的詬病是一個阻塞協議。RM在執(zhí)行分支事務后需要等待TM的決定，此時服務會阻塞并鎖定資源。由于其阻塞機制和最差時間復雜度高， 因此，這種設計不能適應隨著事務涉及的服務數量增加而擴展的需要，很難用于并發(fā)較高以及子事務生命周期較長 (long-running transactions) 的分布式服務中。

TCC方案：

如果拿TCC事務的處理流程與2PC兩階段提交做比較，2PC通常都是在跨庫的DB層面，而TCC則在應用層面的處理，需要通過業(yè)務邏輯來實現。這種分布式事務的實現方式的優(yōu)勢在于，可以讓應用自己定義數據操作的粒度，使得降低鎖沖突、提高吞吐量成為可能。而不足之處則在于對應用的侵入性非常強，業(yè)務邏輯的每個分支都需要實現try、confirm、cancel三個操作。此外，其實現難度也比較大，需要按照網絡狀態(tài)、系統故障等不同的失敗原因實現不同的回滾策略。典型的使用場景：滿，登錄送優(yōu)惠券等。

可靠消息最終一致性

可靠消息最終一致性事務適合執(zhí)行周期長且實時性要求不高的場景。引入消息機制后，同步的事務操作變?yōu)榛谙?zhí)行的異步操作，避免了分布式事務中的同步阻塞操作的影響，并實現了兩個服務的解耦。典型的使用場景：注冊送積分，登錄送優(yōu)惠券等。

最大努力通知

最大努力通知是分布式事務中要求最低的一種，適用于一些最終一致性時間敏感度低的業(yè)務；允許發(fā)起通知方處理業(yè)務失敗，在接收通知方收到通知后積極進行失敗處理，無論發(fā)起通知方如何處理結果都會不影響到接收通知方的后續(xù)處理；發(fā)起通知方需提供查詢執(zhí)行情況接口，用于接收通知方校對結果。典型的使用場景：銀行通知、支付結果通知等。

總結：

在條件允許的情況下，我們盡可能選擇本地事務單數據源，因為它減少了網絡交互帶來的性能損耗，且避免了數據弱一致性帶來的種種問題。若某系統頻繁且不合理的使用分布式事務，應首先從整體設計角度觀察服務的拆分是否合理，是否高內聚低耦合？是否粒度太??？分布式事務一直是業(yè)界難題，因為網絡的不確定性，而且我們習慣于拿
分布式事務與單機事務ACID做對比。

無論是數據庫層的XA、還是應用層TCC、可靠消息、最大努力通知等方案，都沒有完美解決分布式事務問題，它們不過是各自在性能、一致性、可用性等方面做取舍，尋求某些場景偏好下的權衡。

github源碼地址：https://github.com/jjhyb/distributed-transaction