|
作者：楊曉冬 來自： www.cnblogs.com/savorboard/
分布式事務是企業(yè)集成中的一個技術難點，也是每一個分布式系統(tǒng)架構中都會涉及到的一個東西，特別是在微服務架構中，幾乎可以說是無法避免。 在說分布式事務之前，我們先從數(shù)據(jù)庫事務說起。 數(shù)據(jù)庫事務可能大家都很熟悉，在開發(fā)過程中也會經(jīng)常使用到。但是即使如此，可能對于一些細節(jié)問題，很多人仍然不清楚。比如很多人都知道數(shù)據(jù)庫事務的幾個特性： 原子性(Atomicity )、一致性( Consistency )、隔離性或獨立性( Isolation)和持久性(Durabilily)，簡稱就是ACID。但是再往下比如問到隔離性指的是什么的時候可能就不知道了，或者是知道隔離性是什么但是再問到數(shù)據(jù)庫實現(xiàn)隔離的都有哪些級別，或者是每個級別他們有什么區(qū)別的時候可能就不知道了。 本文并不打算介紹這些數(shù)據(jù)庫事務的這些東西，有興趣可以搜索一下相關資料。不過有一個知識點我們需要了解，就是假如數(shù)據(jù)庫在提交事務的時候突然斷電，那么它是怎么樣恢復的呢？ 為什么要提到這個知識點呢？ 因為分布式系統(tǒng)的核心就是處理各種異常情況，這也是分布式系統(tǒng)復雜的地方，因為分布式的網(wǎng)絡環(huán)境很復雜，這種“斷電”故障要比單機多很多，所以我們在做分布式系統(tǒng)的時候，最先考慮的就是這種情況。這些異?？赡苡?機器宕機、網(wǎng)絡異常、消息丟失、消息亂序、數(shù)據(jù)錯誤、不可靠的TCP、存儲數(shù)據(jù)丟失、其他異常等等... 我們接著說本地事務數(shù)據(jù)庫斷電的這種情況，它是怎么保證數(shù)據(jù)一致性的呢？我們使用SQL Server來舉例，我們知道我們在使用 SQL Server 數(shù)據(jù)庫是由兩個文件組成的，一個數(shù)據(jù)庫文件和一個日志文件，通常情況下，日志文件都要比數(shù)據(jù)庫文件大很多。數(shù)據(jù)庫進行任何寫入操作的時候都是要先寫日志的，同樣的道理，我們在執(zhí)行事務的時候數(shù)據(jù)庫首先會記錄下這個事務的redo操作日志，然后才開始真正操作數(shù)據(jù)庫，在操作之前首先會把日志文件寫入磁盤，那么當突然斷電的時候，即使操作沒有完成，在重新啟動數(shù)據(jù)庫時候，數(shù)據(jù)庫會根據(jù)當前數(shù)據(jù)的情況進行undo回滾或者是redo前滾，這樣就保證了數(shù)據(jù)的強一致性。 接著，我們就說一下分布式事務。 當我們的單個數(shù)據(jù)庫的性能產(chǎn)生瓶頸的時候，我們可能會對數(shù)據(jù)庫進行分區(qū)，這里所說的分區(qū)指的是物理分區(qū)，分區(qū)之后可能不同的庫就處于不同的服務器上了，這個時候單個數(shù)據(jù)庫的ACID已經(jīng)不能適應這種情況了，而在這種ACID的集群環(huán)境下，再想保證集群的ACID幾乎是很難達到，或者即使能達到那么效率和性能會大幅下降，最為關鍵的是再很難擴展新的分區(qū)了，這個時候如果再追求集群的ACID會導致我們的系統(tǒng)變得很差，這時我們就需要引入一個新的理論原則來適應這種集群的情況，就是 CAP 原則或者叫CAP定理，那么CAP定理指的是什么呢？ CAP定理是由加州大學伯克利分校Eric Brewer教授提出來的，他指出WEB服務無法同時滿足一下3個屬性：
具體地講在分布式系統(tǒng)中，在任何數(shù)據(jù)庫設計中，一個Web應用至多只能同時支持上面的兩個屬性。顯然，任何橫向擴展策略都要依賴于數(shù)據(jù)分區(qū)。因此，設計人員必須在一致性與可用性之間做出選擇。 這個定理在迄今為止的分布式系統(tǒng)中都是適用的！ 為什么這么說呢？ 這個時候有同學可能會把數(shù)據(jù)庫的2PC（兩階段提交）搬出來說話了。OK，我們就來看一下數(shù)據(jù)庫的兩階段提交。 對數(shù)據(jù)庫分布式事務有了解的同學一定知道數(shù)據(jù)庫支持的2PC，又叫做 XA Transactions。
其中，XA 是一個兩階段提交協(xié)議，該協(xié)議分為以下兩個階段：
其中，如果有任何一個數(shù)據(jù)庫否決此次提交，那么所有數(shù)據(jù)庫都會被要求回滾它們在此事務中的那部分信息。這樣做的缺陷是什么呢? 咋看之下我們可以在數(shù)據(jù)庫分區(qū)之間獲得一致性。 如果CAP 定理是對的，那么它一定會影響到可用性。 如果說系統(tǒng)的可用性代表的是執(zhí)行某項操作相關所有組件的可用性的和。那么在兩階段提交的過程中，可用性就代表了涉及到的每一個數(shù)據(jù)庫中可用性的和。我們假設兩階段提交的過程中每一個數(shù)據(jù)庫都具有99.9%的可用性，那么如果兩階段提交涉及到兩個數(shù)據(jù)庫，這個結果就是99.8%。根據(jù)系統(tǒng)可用性計算公式，假設每個月43200分鐘，99.9%的可用性就是43157分鐘, 99.8%的可用性就是43114分鐘，相當于每個月的宕機時間增加了43分鐘。 以上，可以驗證出來，CAP定理從理論上來講是正確的，CAP我們先看到這里，等會再接著說。 在分布式系統(tǒng)中，我們往往追求的是可用性，它的重要程序比一致性要高，那么如何實現(xiàn)高可用性呢？ 前人已經(jīng)給我們提出來了另外一個理論，就是BASE理論，它是用來對CAP定理進行進一步擴充的。BASE理論指的是：
BASE理論是對CAP中的一致性和可用性進行一個權衡的結果，理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據(jù)自身的業(yè)務特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性（Eventual consistency）。 有了以上理論之后，我們來看一下分布式事務的問題。 在分布式系統(tǒng)中，要實現(xiàn)分布式事務，無外乎那幾種解決方案。 和上一節(jié)中提到的數(shù)據(jù)庫XA事務一樣，兩階段提交就是使用XA協(xié)議的原理，我們可以從下面這個圖的流程來很容易的看出中間的一些比如commit和abort的細節(jié)。 兩階段提交這種解決方案屬于犧牲了一部分可用性來換取的一致性。在實現(xiàn)方面，在 .NET 中，可以借助 TransactionScop 提供的 API 來編程實現(xiàn)分布式系統(tǒng)中的兩階段提交，比如WCF中就有實現(xiàn)這部分功能。不過在多服務器之間，需要依賴于DTC來完成事務一致性，Windows下微軟搞的有MSDTC服務，Linux下就比較悲劇了。 另外說一句，TransactionScop 默認不能用于異步方法之間事務一致，因為事務上下文是存儲于當前線程中的，所以如果是在異步方法，需要顯式的傳遞事務上下文。 優(yōu)點： 盡量保證了數(shù)據(jù)的強一致，適合對數(shù)據(jù)強一致要求很高的關鍵領域。（其實也不能100%保證強一致） 缺點： 實現(xiàn)復雜，犧牲了可用性，對性能影響較大，不適合高并發(fā)高性能場景，如果分布式系統(tǒng)跨接口調用，目前 .NET 界還沒有實現(xiàn)方案。 TCC 其實就是采用的補償機制，其核心思想是：針對每個操作，都要注冊一個與其對應的確認和補償（撤銷）操作。它分為三個階段：
舉個例子，假入 Bob 要向 Smith 轉賬，思路大概是：
優(yōu)點： 跟2PC比起來，實現(xiàn)以及流程相對簡單了一些，但數(shù)據(jù)的一致性比2PC也要差一些 缺點： 缺點還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應用層的一種補償方式，所以需要程序員在實現(xiàn)的時候多寫很多補償?shù)拇a，在一些場景中，一些業(yè)務流程可能用TCC不太好定義及處理。 本地消息表這種實現(xiàn)方式應該是業(yè)界使用最多的，其核心思想是將分布式事務拆分成本地事務進行處理，這種思路是來源于ebay。我們可以從下面的流程圖中看出其中的一些細節(jié)： 基本思路就是： 消息生產(chǎn)方，需要額外建一個消息表，并記錄消息發(fā)送狀態(tài)。消息表和業(yè)務數(shù)據(jù)要在一個事務里提交，也就是說他們要在一個數(shù)據(jù)庫里面。然后消息會經(jīng)過MQ發(fā)送到消息的消費方。如果消息發(fā)送失敗，會進行重試發(fā)送。 消息消費方，需要處理這個消息，并完成自己的業(yè)務邏輯。此時如果本地事務處理成功，表明已經(jīng)處理成功了，如果處理失敗，那么就會重試執(zhí)行。如果是業(yè)務上面的失敗，可以給生產(chǎn)方發(fā)送一個業(yè)務補償消息，通知生產(chǎn)方進行回滾等操作。 生產(chǎn)方和消費方定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發(fā)送一遍。如果有靠譜的自動對賬補賬邏輯，這種方案還是非常實用的。 這種方案遵循BASE理論，采用的是最終一致性，筆者認為是這幾種方案里面比較適合實際業(yè)務場景的，即不會出現(xiàn)像2PC那樣復雜的實現(xiàn)(當調用鏈很長的時候，2PC的可用性是非常低的)，也不會像TCC那樣可能出現(xiàn)確認或者回滾不了的情況。 優(yōu)點： 一種非常經(jīng)典的實現(xiàn)，避免了分布式事務，實現(xiàn)了最終一致性。在 .NET中 有現(xiàn)成的解決方案。 缺點： 消息表會耦合到業(yè)務系統(tǒng)中，如果沒有封裝好的解決方案，會有很多雜活需要處理。 有一些第三方的MQ是支持事務消息的，比如RocketMQ，他們支持事務消息的方式也是類似于采用的二階段提交，但是市面上一些主流的MQ都是不支持事務消息的，比如 RabbitMQ 和 Kafka 都不支持。 以阿里的 RocketMQ 中間件為例，其思路大致為： 第一階段Prepared消息，會拿到消息的地址。
也就是說在業(yè)務方法內要想消息隊列提交兩次請求，一次發(fā)送消息和一次確認消息。如果確認消息發(fā)送失敗了RocketMQ會定期掃描消息集群中的事務消息，這時候發(fā)現(xiàn)了Prepared消息，它會向消息發(fā)送者確認，所以生產(chǎn)方需要實現(xiàn)一個check接口，RocketMQ會根據(jù)發(fā)送端設置的策略來決定是回滾還是繼續(xù)發(fā)送確認消息。這樣就保證了消息發(fā)送與本地事務同時成功或同時失敗。 遺憾的是，RocketMQ并沒有 .NET 客戶端。 優(yōu)點： 實現(xiàn)了最終一致性，不需要依賴本地數(shù)據(jù)庫事務。 缺點： 實現(xiàn)難度大，主流MQ不支持，沒有.NET客戶端，RocketMQ事務消息部分代碼也未開源。 Saga事務模型又叫做長時間運行的事務（Long-running-transaction）, 它是由普林斯頓大學的H.Garcia-Molina等人提出，它描述的是另外一種在沒有兩階段提交的的情況下解決分布式系統(tǒng)中復雜的業(yè)務事務問題。 我們這里說的是一種基于 Sagas 機制的工作流事務模型，這個模型的相關理論目前來說還是比較新的，以至于百度上幾乎沒有什么相關資料。 該模型其核心思想就是拆分分布式系統(tǒng)中的長事務為多個短事務，或者叫多個本地事務，然后由 Sagas 工作流引擎負責協(xié)調，如果整個流程正常結束，那么就算是業(yè)務成功完成，如果在這過程中實現(xiàn)失敗，那么Sagas工作流引擎就會以相反的順序調用補償操作，重新進行業(yè)務回滾。 比如我們一次關于購買旅游套餐業(yè)務操作涉及到三個操作，他們分別是預定車輛，預定賓館，預定機票，他們分別屬于三個不同的遠程接口?？赡軓奈覀兂绦虻慕嵌葋碚f他們不屬于一個事務，但是從業(yè)務角度來說是屬于同一個事務的。 他們的執(zhí)行順序如上圖所示，所以當發(fā)生失敗時，會依次進行取消的補償操作。 因為長事務被拆分了很多個業(yè)務流，所以 Sagas 事務模型最重要的一個部件就是工作流或者你也可以叫流程管理器（Process Manager），工作流引擎和Process Manager雖然不是同一個東西，但是在這里，他們的職責是相同的。在選擇工作流引擎之后，最終的代碼也許看起來是這樣的 SagaBuilder saga = SagaBuilder.newSaga('trip') .activity('Reserve car', ReserveCarAdapter.class) .compensationActivity('Cancel car', CancelCarAdapter.class) .activity('Book hotel', BookHotelAdapter.class) .compensationActivity('Cancel hotel', CancelHotelAdapter.class) .activity('Book flight', BookFlightAdapter.class) .compensationActivity('Cancel flight', CancelFlightAdapter.class) .end() .triggerCompensationOnAnyError();camunda.getRepositoryService().createDeployment() .addModelInstance(saga.getModel()) .deploy(); 優(yōu)缺點這里我們就不說了，因為這個理論比較新，目前市面上還沒有什么解決方案，即使是 Java 領域，我也沒有搜索的太多有用的信息。 上面介紹的那些分布式事務的處理方案你在其他地方或許也可以看到，但是并沒有相關的實際代碼或者是開源代碼，所以算不上什么干貨，下面就放干貨了。 在 .NET 領域，似乎沒有什么現(xiàn)成的關于分布式事務的解決方案，或者說是有但未開源。具筆者了解，有一些公司內部其實是有這種解決方案的，但是也是作為公司的一個核心產(chǎn)品之一，并未開源... 鑒于以上原因，所以就打算自己寫一個并且開源出來，所以從17年初就開始做這個事情，然后花了大半年的時間在一直不斷完善，就是下面這個 CAP。 Github CAP： https://github.com/dotnetcore/CAP 這里的 CAP 就不是 CAP 理論了，而是一個 .NET 分布式事務解決方案的名字。 詳細介紹： http://www.cnblogs.com/savorboard/p/cap.html 相關文檔： http://www.cnblogs.com/savorboard/p/cap-document.html 夸張的是，這個解決方案是具有可視化界面（Dashboard）的，你可以很方面的看到哪些消息執(zhí)行成功，哪些消息執(zhí)行失敗，到底是發(fā)送失敗還是處理失敗，一眼便知。 最夸張的是，這個解決方案的可視化界面還提供了實時動態(tài)圖表，這樣不但可以看到實時的消息發(fā)送及處理情況，連當前的系統(tǒng)處理消息的速度都可以看到，還可以看到過去24小時內的歷史消息吞吐量。 最最夸張的是，這個解決方案的還幫你集成了 Consul 做分布式節(jié)點發(fā)現(xiàn)和注冊還有心跳檢查，你隨時可以看到其他的節(jié)點的狀況。 最最最夸張的是，你以為你看其他節(jié)點的數(shù)據(jù)要登錄到其他節(jié)點的Dashboard控制臺看？錯了，你隨便打開其中任意一個節(jié)點的Dashboard，點一下就可以切換到你想看的節(jié)點的控制臺界面了，就像你看本地的數(shù)據(jù)一樣，他們是完全去中心化的。 你以為這些就夠了？不，遠遠不止：
這下你以為我說完了？ 不！ 你完全可以把 CAP 當做一個 EventBus 來使用，CAP具有優(yōu)秀的消息處理能力，不要擔心瓶頸會在CAP，那是永遠不可能， 因為你隨時可以在配置中指定CAP處理的消息使用的進程數(shù)， 只要你的數(shù)據(jù)庫配置足夠高... |
|
|
來自： 萬皇之皇 > 《IT互聯(lián)》
