1捕发、什么是分布式事務(wù)

分布式事務(wù)就是指事務(wù)的參與者、支持事務(wù)的服務(wù)器失受、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上拭卿。以上是百度百科的解釋，簡單的說贱纠，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務(wù)器上响蕴，且屬于不同的應(yīng)用谆焊，分布式事務(wù)需要保證這些小操作要么全部成功，要么全部失敗浦夷。本質(zhì)上來說辖试，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

2劈狐、分布式事務(wù)的產(chǎn)生的原因

2.1罐孝、數(shù)據(jù)庫分庫分表

當數(shù)據(jù)庫單表一年產(chǎn)生的數(shù)據(jù)超過1000W，那么就要考慮分庫分表肥缔，具體分庫分表的原理在此不做解釋莲兢，以后有空詳細說，簡單的說就是原來的一個數(shù)據(jù)庫變成了多個數(shù)據(jù)庫续膳。這時候改艇，如果一個操作既訪問01庫，又訪問02庫坟岔，而且要保證數(shù)據(jù)的一致性谒兄，那么就要用到分布式事務(wù)。

2.2社付、應(yīng)用SOA化

所謂的SOA化承疲，就是業(yè)務(wù)的服務(wù)化邻耕。比如原來單機支撐了整個電商網(wǎng)站，現(xiàn)在對整個網(wǎng)站進行拆解燕鸽，分離出了訂單中心兄世、用戶中心、庫存中心绵咱。對于訂單中心碘饼，有專門的數(shù)據(jù)庫存儲訂單信息，用戶中心也有專門的數(shù)據(jù)庫存儲用戶信息悲伶，庫存中心也會有專門的數(shù)據(jù)庫存儲庫存信息艾恼。這時候如果要同時對訂單和庫存進行操作，那么就會涉及到訂單數(shù)據(jù)庫和庫存數(shù)據(jù)庫麸锉，為了保證數(shù)據(jù)一致性钠绍，就需要用到分布式事務(wù)。

以上兩種情況表象不同花沉，但是本質(zhì)相同柳爽，都是因為要操作的數(shù)據(jù)庫變多了！

3碱屁、事務(wù)的ACID特性

3.1磷脯、原子性（A）

所謂的原子性就是說，在整個事務(wù)中的所有操作娩脾，要么全部完成赵誓，要么全部不做，沒有中間狀態(tài)柿赊。對于事務(wù)在執(zhí)行中發(fā)生錯誤俩功，所有的操作都會被回滾，整個事務(wù)就像從沒被執(zhí)行過一樣碰声。

3.2诡蜓、一致性（C）

事務(wù)的執(zhí)行必須保證系統(tǒng)的一致性，就拿轉(zhuǎn)賬為例胰挑，A有500元蔓罚，B有300元，如果在一個事務(wù)里A成功轉(zhuǎn)給B50元洽腺，那么不管并發(fā)多少脚粟，不管發(fā)生什么，只要事務(wù)執(zhí)行成功了蘸朋，那么最后A賬戶一定是450元核无，B賬戶一定是350元。

3.3藕坯、隔離性（I）

所謂的隔離性就是說团南，事務(wù)與事務(wù)之間不會互相影響噪沙，一個事務(wù)的中間狀態(tài)不會被其他事務(wù)感知。

3.4吐根、持久性（D）

所謂的持久性正歼，就是說一單事務(wù)完成了，那么事務(wù)對數(shù)據(jù)所做的變更就完全保存在了數(shù)據(jù)庫中拷橘，即使發(fā)生停電局义，系統(tǒng)宕機也是如此。

4冗疮、分布式事務(wù)的應(yīng)用場景

4.1萄唇、支付

最經(jīng)典的場景就是支付了，一筆支付术幔，是對買家賬戶進行扣款另萤，同時對賣家賬戶進行加錢，這些操作必須在一個事務(wù)里執(zhí)行诅挑，要么全部成功四敞，要么全部失敗。而對于買家賬戶屬于買家中心拔妥，對應(yīng)的是買家數(shù)據(jù)庫忿危，而賣家賬戶屬于賣家中心，對應(yīng)的是賣家數(shù)據(jù)庫没龙，對不同數(shù)據(jù)庫的操作必然需要引入分布式事務(wù)癌蚁。

4.2、在線下單

買家在電商平臺下單兜畸，往往會涉及到兩個動作，一個是扣庫存碘梢，第二個是更新訂單狀態(tài)咬摇，庫存和訂單一般屬于不同的數(shù)據(jù)庫，需要使用分布式事務(wù)保證數(shù)據(jù)一致性煞躬。

5肛鹏、常見的分布式事務(wù)解決方案

5.1、基于XA協(xié)議的兩階段提交

XA是一個分布式事務(wù)協(xié)議恩沛，由Tuxedo提出在扰。XA中大致分為兩部分：事務(wù)管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫實現(xiàn)雷客，比如Oracle芒珠、DB2這些商業(yè)數(shù)據(jù)庫都實現(xiàn)了XA接口，而事務(wù)管理器作為全局的調(diào)度者搅裙，負責各個本地資源的提交和回滾皱卓。XA實現(xiàn)分布式事務(wù)的原理如下：

總的來說裹芝，XA協(xié)議比較簡單，而且一旦商業(yè)數(shù)據(jù)庫實現(xiàn)了XA協(xié)議娜汁，使用分布式事務(wù)的成本也比較低嫂易。但是，XA也有致命的缺點掐禁，那就是性能不理想怜械，特別是在交易下單鏈路，往往并發(fā)量很高傅事，XA無法滿足高并發(fā)場景缕允。XA目前在商業(yè)數(shù)據(jù)庫支持的比較理想，在mysql數(shù)據(jù)庫中支持的不太理想享完，mysql的XA實現(xiàn)灼芭，沒有記錄prepare階段日志，主備切換回導(dǎo)致主庫與備庫數(shù)據(jù)不一致般又。許多nosql也沒有支持XA彼绷，這讓XA的應(yīng)用場景變得非常狹隘。

5.2茴迁、消息事務(wù)+最終一致性

所謂的消息事務(wù)就是基于消息中間件的兩階段提交寄悯，本質(zhì)上是對消息中間件的一種特殊利用，它是將本地事務(wù)和發(fā)消息放在了一個分布式事務(wù)里堕义，保證要么本地操作成功成功并且對外發(fā)消息成功猜旬，要么兩者都失敗，開源的RocketMQ就支持這一特性倦卖，具體原理如下：

1洒擦、A系統(tǒng)向消息中間件發(fā)送一條預(yù)備消息

2、消息中間件保存預(yù)備消息并返回成功

3怕膛、A執(zhí)行本地事務(wù)

4熟嫩、A發(fā)送提交消息給消息中間件

通過以上4步完成了一個消息事務(wù)。對于以上的4個步驟褐捻，每個步驟都可能產(chǎn)生錯誤掸茅，下面一一分析：

步驟一出錯，則整個事務(wù)失敗柠逞，不會執(zhí)行A的本地操作步驟二出錯昧狮，則整個事務(wù)失敗，不會執(zhí)行A的本地操作步驟三出錯板壮，這時候需要回滾預(yù)備消息逗鸣，怎么回滾？答案是A系統(tǒng)實現(xiàn)一個消息中間件的回調(diào)接口，消息中間件會去不斷執(zhí)行回調(diào)接口慕购，檢查A事務(wù)執(zhí)行是否執(zhí)行成功聊疲，如果失敗則回滾預(yù)備消息步驟四出錯，這時候A的本地事務(wù)是成功的沪悲，那么消息中間件要回滾A嗎获洲？答案是不需要，其實通過回調(diào)接口殿如，消息中間件能夠檢查到A執(zhí)行成功了贡珊，這時候其實不需要A發(fā)提交消息了，消息中間件可以自己對消息進行提交涉馁，從而完成整個消息事務(wù)基于消息中間件的兩階段提交往往用在高并發(fā)場景下门岔，將一個分布式事務(wù)拆成一個消息事務(wù)（A系統(tǒng)的本地操作+發(fā)消息）+B系統(tǒng)的本地操作，其中B系統(tǒng)的操作由消息驅(qū)動烤送，只要消息事務(wù)成功寒随，那么A操作一定成功，消息也一定發(fā)出來了帮坚，這時候B會收到消息去執(zhí)行本地操作妻往，如果本地操作失敗，消息會重投试和，直到B操作成功讯泣，這樣就變相地實現(xiàn)了A與B的分布式事務(wù)。原理如下：

雖然上面的方案能夠完成A和B的操作阅悍，但是A和B并不是嚴格一致的好渠，而是最終一致的，我們在這里犧牲了一致性节视，換來了性能的大幅度提升拳锚。當然，這種玩法也是有風險的寻行，如果B一直執(zhí)行不成功晌畅，那么一致性會被破壞，具體要不要玩寡痰，還是得看業(yè)務(wù)能夠承擔多少風險。

5.3棋凳、TCC編程模式

所謂的TCC編程模式拦坠，也是兩階段提交的一個變種。TCC提供了一個編程框架剩岳，將整個業(yè)務(wù)邏輯分為三塊：Try贞滨、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存晓铆，Confirm階段則是去更新訂單狀態(tài)勺良，如果更新訂單失敗，則進入Cancel階段骄噪，會去恢復(fù)庫存尚困。總之链蕊，TCC就是通過代碼人為實現(xiàn)了兩階段提交事甜，不同的業(yè)務(wù)場景所寫的代碼都不一樣，復(fù)雜度也不一樣滔韵，因此逻谦，這種模式并不能很好地被復(fù)用。

在此我向大家推薦一個架構(gòu)學習交流群陪蜻。交流學習群號：478030634 ?里面會分享一些資深架構(gòu)師錄制的視頻錄像：有Spring邦马，MyBatis，Netty源碼分析宴卖，高并發(fā)滋将、高性能乙濒、分布式详羡、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化邻吞、分布式架構(gòu)等這些成為架構(gòu)師必備的知識體系齿兔。還能領(lǐng)取免費的學習資源橱脸，目前受益良多

6、總結(jié)

分布式事務(wù)分苇，本質(zhì)上是對多個數(shù)據(jù)庫的事務(wù)進行統(tǒng)一控制添诉，按照控制力度可以分為：不控制、部分控制和完全控制医寿。不控制就是不引入分布式事務(wù)栏赴，部分控制就是各種變種的兩階段提交，包括上面提到的消息事務(wù)+最終一致性靖秩、TCC模式须眷，而完全控制就是完全實現(xiàn)兩階段提交。部分控制的好處是并發(fā)量和性能很好沟突，缺點是數(shù)據(jù)一致性減弱了花颗，完全控制則是犧牲了性能，保障了一致性惠拭，具體用哪種方式扩劝，最終還是取決于業(yè)務(wù)場景。作為技術(shù)人員，一定不能忘了技術(shù)是為業(yè)務(wù)服務(wù)的棒呛，不要為了技術(shù)而技術(shù)聂示，針對不同業(yè)務(wù)進行技術(shù)選型也是一種很重要的能力

原文：https://blog.csdn.net/yunzhaji3762/article/details/82989335