怎么理解高并發(fā)下的數(shù)據(jù)庫分布式事務

這篇文章主要介紹“怎么理解高并發(fā)下的數(shù)據(jù)庫分布式事務”，在日常操作中，相信很多人在怎么理解高并發(fā)下的數(shù)據(jù)庫分布式事務問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解高并發(fā)下的數(shù)據(jù)庫分布式事務”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

1、什么是分布式事務

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

2、分布式事務的產生的原因

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

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

2.2、應用SOA化

所謂的SOA化，就是業(yè)務的服務化。比如原來單機支撐了整個電商網站，現(xiàn)在對整個網站進行拆解，分離出了訂單中心、用戶中心、庫存中心。對于訂單中心，有專門的數(shù)據(jù)庫存儲訂單信息，用戶中心也有專門的數(shù)據(jù)庫存儲用戶信息，庫存中心也會有專門的數(shù)據(jù)庫存儲庫存信息。這時候如果要同時對訂單和庫存進行操作，那么就會涉及到訂單數(shù)據(jù)庫和庫存數(shù)據(jù)庫，為了保證數(shù)據(jù)一致性，就需要用到分布式事務。

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

3、事務的ACID特性

3.1、原子性（A）

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

3.2、一致性（C）

事務的執(zhí)行必須保證系統(tǒng)的一致性，就拿轉賬為例，A有500元，B有300元，如果在一個事務里A成功轉給B50元，那么不管并發(fā)多少，不管發(fā)生什么，只要事務執(zhí)行成功了，那么最后A賬戶一定是450元，B賬戶一定是350元。

3.3、隔離性（I）

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

3.4、持久性（D）

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

4、分布式事務的應用場景

4.1、支付

最經典的場景就是支付了，一筆支付，是對買家賬戶進行扣款，同時對賣家賬戶進行加錢，這些操作必須在一個事務里執(zhí)行，要么全部成功，要么全部失敗。而對于買家賬戶屬于買家中心，對應的是買家數(shù)據(jù)庫，而賣家賬戶屬于賣家中心，對應的是賣家數(shù)據(jù)庫，對不同數(shù)據(jù)庫的操作必然需要引入分布式事務。

4.2、在線下單

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

5、常見的分布式事務解決方案

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

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

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

5.2、消息事務+最終一致性

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

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

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

3、A執(zhí)行本地事務

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

通過以上4步完成了一個消息事務。對于以上的4個步驟，每個步驟都可能產生錯誤，下面一一分析：

步驟一出錯，則整個事務失敗，不會執(zhí)行A的本地操作步驟二出錯，則整個事務失敗，不會執(zhí)行A的本地操作步驟三出錯，這時候需要回滾預備消息，怎么回滾？答案是A系統(tǒng)實現(xiàn)一個消息中間件的回調接口，消息中間件會去不斷執(zhí)行回調接口，檢查A事務執(zhí)行是否執(zhí)行成功，如果失敗則回滾預備消息步驟四出錯，這時候A的本地事務是成功的，那么消息中間件要回滾A嗎？答案是不需要，其實通過回調接口，消息中間件能夠檢查到A執(zhí)行成功了，這時候其實不需要A發(fā)提交消息了，消息中間件可以自己對消息進行提交，從而完成整個消息事務基于消息中間件的兩階段提交往往用在高并發(fā)場景下，將一個分布式事務拆成一個消息事務（A系統(tǒng)的本地操作+發(fā)消息）+B系統(tǒng)的本地操作，其中B系統(tǒng)的操作由消息驅動，只要消息事務成功，那么A操作一定成功，消息也一定發(fā)出來了，這時候B會收到消息去執(zhí)行本地操作，如果本地操作失敗，消息會重投，直到B操作成功，這樣就變相地實現(xiàn)了A與B的分布式事務。原理如下：

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

5.3、TCC編程模式

所謂的TCC編程模式，也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業(yè)務邏輯分為三塊：Try、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態(tài)，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存?？傊?，TCC就是通過代碼人為實現(xiàn)了兩階段提交，不同的業(yè)務場景所寫的代碼都不一樣，復雜度也不一樣，因此，這種模式并不能很好地被復用。

到此，關于“怎么理解高并發(fā)下的數(shù)據(jù)庫分布式事務”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>