深入剖析分布式事務(wù)一致性

點擊下方“IT牧場”，選擇“設(shè)為星標”

概述

分布式事務(wù)是用來解決跨數(shù)據(jù)庫、跨服務(wù)更新數(shù)據(jù)一致性問題的。那么這里的一致性指的是什么，什么是強一致性，什么是弱一致性，與CAP理論中的一致性概念是一樣的嗎？本文將為您深入解答相關(guān)的問題。

一致性指什么

在數(shù)據(jù)庫的理論中，事務(wù)具備大家都熟悉的ACID特性，分別如下：

• Atomicity（原子性）：一個事務(wù)中的所有操作，要么全部完成，要么全部不完成，不會結(jié)束在中間某個環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯誤，會被恢復(fù)到事務(wù)開始前的狀態(tài)，就像這個事務(wù)從來沒有執(zhí)行過一樣。
• Consistency（一致性）：在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性沒有被破壞。完整性包括外鍵約束、應(yīng)用定義的等約束不會被破壞。
• Isolation（隔離性）：數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對其數(shù)據(jù)進行讀寫和修改的能力，隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。
• Durability（持久性）：事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失。

對于這里面的C（一致性），我們以一個非常具體的業(yè)務(wù)例子，來進行解釋。假如我們正在處理一個轉(zhuǎn)賬業(yè)務(wù)，假設(shè)是A轉(zhuǎn)給B 30元，在本地事務(wù)的支持下，我們的用戶看到A+B的總金額，在整個轉(zhuǎn)賬前后，以及轉(zhuǎn)賬過程中，都是保持不變的。那么這個時候用戶認為他看到的數(shù)據(jù)是一致的，符合業(yè)務(wù)約束的。

當我們業(yè)務(wù)變復(fù)雜，引入多個數(shù)據(jù)庫和大量微服務(wù)時，上述本地事務(wù)的一致性，依舊是業(yè)務(wù)非常關(guān)心的。假如一個業(yè)務(wù)更新操作，跨庫或者跨服務(wù)時，那么此時業(yè)務(wù)關(guān)心的一致性問題，就變成了分布式事務(wù)中的一致性問題。

在單機本地事務(wù)中，A+B的總金額在任何時刻去查（以常見的ReadCommitted或ReadRepeatable隔離級別），都是不變的，也就是業(yè)務(wù)約束一直都保持的這種一致性，我們稱之為強一致性。

無法做到強一致

目前在跨庫、跨服務(wù)的分布式實際應(yīng)用中，尚未看到有強一致性的方案。

我們來看看一致性級別最高的XA事務(wù)，是否是強一致的，我們以跨行轉(zhuǎn)賬（在這里，我們以跨庫更新AB來模擬）作為例子來說明，下面是一個XA事務(wù)的時序圖：

在這個時序圖中，我們在如圖所示的時間點發(fā)起查詢，那么我們查到的數(shù)據(jù)，將是A+B+30，不等于A+B，不符合強一致的要求。

理論上的強一致性

我們接下來思考，普通XA事務(wù)不是強一致的，但假如完全不考慮性能因素，有沒有可能在理論上做到強一致：

我們先看看如果我們把XA事務(wù)涉及的數(shù)據(jù)庫，隔離級別設(shè)定到Serializable，是否能到到強一致的效果呢？我們來看看前面的時序場景：

這種情況下，查到結(jié)果等于A+B，但是又有另一些場景出現(xiàn)了問題，如下圖所示：

按照圖中時序查詢的結(jié)果是：A+B-30，依舊是不一致。

深入思考這個強一致的問題之后，有一種做法可以做到強一致，做法如下：

• 對于查詢，也采用XA事務(wù)，并且查詢數(shù)據(jù)時，采用select for update的方式，所有數(shù)據(jù)查完之后，再xa commit
• 為了避免死鎖，需要將涉及到的數(shù)據(jù)庫排序，訪問數(shù)據(jù)都必須要按照相同的數(shù)據(jù)庫順序來寫入和查詢

在上述策略下，我們可以看到，在時序圖任何一個時間點進行查詢，獲得的結(jié)果都是A+B

• 在T0時間查詢，那么修改一定發(fā)生在查詢?nèi)客瓿芍螅圆樵兊玫浇Y(jié)果A+B

• 在T1，T2，T3查詢，那么查詢結(jié)果返回一定全部發(fā)生在修改完成之后，所以查詢得到結(jié)果也是A+B

很明顯這種理論上的強一致，效率極低，所有有數(shù)據(jù)交集的數(shù)據(jù)庫事務(wù)都是串行執(zhí)行，而且還需要按照特定的順序查詢/修改數(shù)據(jù)，因此成本極高，幾乎無法應(yīng)用在生產(chǎn)中。

NewSQL的強一致性

我們討論了跨庫、跨微服務(wù)的分布式事務(wù)是無法做到強一致的，其實還有一種分布式數(shù)據(jù)內(nèi)部的事務(wù)，因為事務(wù)跨節(jié)點了，也被成為分布式事務(wù)。這種分布式事務(wù)是可以做到強一致的，這種強一致是通過MVCC的技術(shù)達到的，原理和單機的數(shù)據(jù)庫類似，但復(fù)雜很多。詳細的實現(xiàn)方法可以參考谷歌的percolator

未來有沒有可能借鑒NewSQL的這種方式，來實現(xiàn)跨庫、跨微服務(wù)這類分布式事務(wù)的強一致性？理論上是可以的。

• 實現(xiàn)跨服務(wù)但不跨庫的分布式事務(wù)一致性，會相對簡單一些，其中一種方式就是實現(xiàn)XA事務(wù)中的TMRESUME選項（因為最終只有一個xa commit，不會出現(xiàn)兩個xa commit中間的不一致時間窗口）。
• 實現(xiàn)跨數(shù)據(jù)庫的分布式事務(wù)一致性，會困難很多，因為各個數(shù)據(jù)庫的內(nèi)部版本機制都不一樣，想要協(xié)同非常困難。

弱一致性的分類

既然現(xiàn)有的各種分布式事務(wù)方案都無法做到強一致，那么弱一致性之間是否有差別呢？我們進行了以下關(guān)于一致性強弱的分類：

一致性由強到弱分別是：

XA事務(wù)>消息>TCC>SAGA

這里的消息指的是本地消息表這種類型的分布式事務(wù)，關(guān)于這四種分布式事務(wù)的介紹，參見分布式事務(wù)最經(jīng)典的七種解決方案

他們的分類為：

• 無中間態(tài)：數(shù)據(jù)只有兩個狀態(tài)，事務(wù)前和事務(wù)后，沒有其他第三種狀態(tài)。XA、消息這兩種都是這種

• 有中間態(tài)：數(shù)據(jù)有中間態(tài)，例如TCC的Try，數(shù)據(jù)狀態(tài)和事務(wù)前事務(wù)后都不一樣；SAGA也有中間態(tài)，假如一個SAGA事務(wù)執(zhí)行正向操作后數(shù)據(jù)為W，又回滾了，那么W也與事務(wù)前事務(wù)后的狀態(tài)不同。

• XA：XA雖然不是強一致，但是XA的一致性是多種分布式事務(wù)中，一致性最好的，因為他處于不一致的狀態(tài)時間很短，只有一部分分支開始commit，但還沒有全部commit的這個時間窗口，數(shù)據(jù)是不一致的。因為數(shù)據(jù)庫的commit操作耗時，通常是10ms內(nèi)，因此不一致的窗口期很短。

• 消息：消息型在第一個操作完成后，在所有操作完成之前，這個時間窗口是不一致的，持續(xù)時長一般比XA更久。

• TCC：TCC的中間態(tài)，通常可控，可以自定義。通常情況下，這部分數(shù)據(jù)不展示給用戶，因此一致性比后面的SAGA要好。

• SAGA：SAGA如果發(fā)生回滾，而子事務(wù)中正向操作修改的數(shù)據(jù)會被用戶看到，可能給用戶帶來較差的體驗，因此一致性是最差的。

我們這里的分類僅僅從我們關(guān)心的幾個維度進行了歸納，適用于多數(shù)場景，但并不一定適用所有情況。在實際的應(yīng)用中，也可能出現(xiàn)TCC的一致性比消息更好，例如我在Try中執(zhí)行xa prepare，Confirm中執(zhí)行xa commit，Cancel中執(zhí)行xa rollback，在這種實現(xiàn)下，TCC的一致性就跟XA一樣，一致性其實高于消息。

CAP理論中的一致性

我們這里討論的一致性是指數(shù)據(jù)庫中的一致性概念，與CAP中的一致性不同。

• CAP中的強一致性是指用戶在分布式系統(tǒng)中寫完之后，立刻去讀，如果能夠像本地讀寫那樣，讀到最新版本，那么是強一致性。
• 分布式事務(wù)中的強一致性，是指事務(wù)進行的過程中，用戶讀取的數(shù)據(jù)始終滿足業(yè)務(wù)約束，目前在實際應(yīng)用中的方案，都無法做到強一致。

上述兩者的強一致性在具體的含義上是不同的，但從用戶的視角看，也有共通性，即能否像單機系統(tǒng)一樣，不需要關(guān)心分布式帶來的新問題。

讀者通常會有另一個疑問，那就是分布式事務(wù)是一個分布式系統(tǒng)，那么在CAP中的一致性如何？

當前Paxos/Raft等分布式共識協(xié)議已經(jīng)在工業(yè)領(lǐng)域有了成熟的實現(xiàn)，當遇見機器故障或網(wǎng)絡(luò)隔離的情況時，可以做到大約幾百個毫秒到幾秒內(nèi)選舉出新的leader，從故障中恢復(fù)。也就是說CAP中，選擇CP，在A上面只有大約幾百個毫秒的不可用時間。

因此對于NewSQL或者分布式事務(wù)這類數(shù)據(jù)敏感性應(yīng)用，一般都選擇CAP中的CP，而犧牲幾百毫秒的A。因此在這方面，分布式事務(wù)是CAP中強一致的。例如我們的dtm分布式事務(wù)框架，將全局事務(wù)進度保存在CP的數(shù)據(jù)庫中（云廠商大多提供了CP的數(shù)據(jù)庫）

總結(jié)

本文詳盡的分析了分布式事務(wù)中一致性相關(guān)的問題，在確認沒有強一致性方案的情況下，分析了弱一致性分類及理論上可能的強一致方案。

作者：葉東富

來源：segmentfault.com/a/1190000041106277

版權(quán)申明：內(nèi)容來源網(wǎng)絡(luò)，僅供分享學(xué)習(xí)，版權(quán)歸原創(chuàng)者所有。除非無法確認，我們都會標明作者及出處，如有侵權(quán)煩請告知，我們會立即刪除并表示歉意。謝謝!

干貨分享
最近將個人學(xué)習(xí)筆記整理成冊，使用PDF分享。關(guān)注我，回復(fù)如下代碼，即可獲得百度盤地址，無套路領(lǐng)取！
?001：《Java并發(fā)與高并發(fā)解決方案》學(xué)習(xí)筆記；?002：《深入JVM內(nèi)核——原理、診斷與優(yōu)化》學(xué)習(xí)筆記；?003：《Java面試寶典》?004：《Docker開源書》?005：《Kubernetes開源書》?006：《DDD速成（領(lǐng)域驅(qū)動設(shè)計速成）》?007：全部?008：加技術(shù)群討論
加個關(guān)注不迷路
喜歡就點個"在看"唄^_^