經常使用的分佈式事務解決方案

衆所周知,數據庫能實現 本地事務,也就是在 同一個數據庫中,你能夠容許一組操做要麼全都正確執行,要麼全都不執行。這裏特別強調了 本地事務,也就是目前的數據庫只能支持同一個數據庫中的事務。但如今的系統每每採用微服務架構,業務系統擁有獨立的數據庫,所以就出現了跨多個數據庫的事務需求,這種事務即爲「分佈式事務」。那麼在目前數據庫不支持跨庫事務的狀況下,咱們應該如何實現分佈式事務呢?本文首先會爲你們梳理分佈式事務的基本概念和理論基礎,而後介紹幾種目前經常使用的分佈式事務解決方案。廢話很少說,那就開始
 

什麼是事務?

事務由一組操做構成,咱們但願這組操做可以所有正確執行,若是這一組操做中的任意一個步驟發生錯誤,那麼就須要回滾以前已經完成的操做。也就是同一個事務中的全部操做,要麼全都正確執行,要麼全都不要執行。html

事務的四大特性 ACID

說到事務,就不得不提一下事務著名的四大特性。web

  • 原子性: 原子性要求,事務是一個不可分割的執行單元,事務中的全部操做要麼全都執行,要麼全都不執行。算法

  • 一致性: 一致性要求,事務在開始前和結束後,數據庫的完整性約束沒有被破壞。數據庫

  • 隔離性: 事務的執行是相互獨立的,它們不會相互干擾,一個事務不會看到另外一個正在運行過程當中的事務的數據。緩存

  • 持久性: 持久性要求,一個事務完成以後,事務的執行結果必須是持久化保存的。即便數據庫發生崩潰,在數據庫恢復後事務提交的結果仍然不會丟失。安全

注意:事務只能保證數據庫的高可靠性,即數據庫自己發生問題後,事務提交後的數據仍然能恢復;而若是不是數據庫自己的故障,如硬盤損壞了,那麼事務提交的數據可能就丟失了。這屬於『高可用性』的範疇。所以,事務只能保證數據庫的『高可靠性』,而『高可用性』須要整個系統共同配合實現。服務器

事務的隔離級別

這裏擴展一下,對事務的隔離性作一個詳細的解釋。網絡

在事務的四大特性ACID中,要求的隔離性是一種嚴格意義上的隔離,也就是多個事務是串行執行的,彼此之間不會受到任何干擾。這確實可以徹底保證數據的安全性,但在實際業務系統中,這種方式性能不高。所以,數據庫定義了四種隔離級別,隔離級別和數據庫的性能是呈反比的,隔離級別越低,數據庫性能越高,而隔離級別越高,數據庫性能越差。架構

事務併發執行會出現的問題

咱們先來看一下在不一樣的隔離級別下,數據庫可能會出現的問題:併發

  1. 更新丟失 當有兩個併發執行的事務,更新同一行數據,那麼有可能一個事務會把另外一個事務的更新覆蓋掉。 當數據庫沒有加任何鎖操做的狀況下會發生。

  2. 髒讀 一個事務讀到另外一個還沒有提交的事務中的數據。 該數據可能會被回滾從而失效。 若是第一個事務拿着失效的數據去處理那就發生錯誤了。

  3. 不可重複讀 不可重複度的含義:一個事務對同一行數據讀了兩次,卻獲得了不一樣的結果。它具體分爲以下兩種狀況:

    • 虛讀:在事務1兩次讀取同一記錄的過程當中,事務2對該記錄進行了修改,從而事務1第二次讀到了不同的記錄。
    • 幻讀:事務1在兩次查詢的過程當中,事務2對該表進行了插入、刪除操做,從而事務1第二次查詢的結果發生了變化。

不可重複讀 與 髒讀 的區別? 髒讀讀到的是還沒有提交的數據,而不可重複讀讀到的是已經提交的數據,只不過在兩次讀的過程當中數據被另外一個事務改過了。

數據庫的四種隔離級別

數據庫一共有以下四種隔離級別:

  1. Read uncommitted 讀未提交: 在該級別下,一個事務對一行數據修改的過程當中,不容許另外一個事務對該行數據進行修改,但容許另外一個事務對該行數據讀。 所以本級別下,不會出現更新丟失,但會出現髒讀、不可重複讀。

  2. Read committed 讀提交: 在該級別下,未提交的寫事務不容許其餘事務訪問該行,所以不會出現髒讀;可是讀取數據的事務容許其餘事務的訪問該行數據,所以會出現不可重複讀的狀況。

  3. Repeatable read 重複讀: 在該級別下,讀事務禁止寫事務,但容許讀事務,所以不會出現同一事務兩次讀到不一樣的數據的狀況(不可重複讀),且寫事務禁止其餘一切事務。

  4. Serializable 序列化: 該級別要求全部事務都必須串行執行,所以能避免一切因併發引發的問題,但效率很低。

隔離級別越高,越能保證數據的完整性和一致性,可是對併發性能的影響也越大。對於多數應用程序,能夠優先考慮把數據庫系統的隔離級別設爲Read Committed。它可以避免髒讀取,並且具備較好的併發性能。儘管它會致使不可重複讀、幻讀和第二類丟失更新這些併發問題,在可能出現這類問題的個別場合,能夠由應用程序採用悲觀鎖或樂觀鎖來控制。


什麼是分佈式事務?

到此爲止,所介紹的事務都是基於單數據庫的本地事務,目前的數據庫僅支持單庫事務,並不支持跨庫事務。而隨着微服務架構的普及,一個大型業務系統每每由若干個子系統構成,這些子系統又擁有各自獨立的數據庫。每每一個業務流程須要由多個子系統共同完成,並且這些操做可能須要在一個事務中完成。在微服務系統中,這些業務場景是廣泛存在的。此時,咱們就須要在數據庫之上經過某種手段,實現支持跨數據庫的事務支持,這也就是你們常說的「分佈式事務」。

這裏舉一個分佈式事務的典型例子——用戶下單過程。 當咱們的系統採用了微服務架構後,一個電商系統每每被拆分紅以下幾個子系統:商品系統、訂單系統、支付系統、積分系統等。整個下單的過程以下:

  1. 用戶經過商品系統瀏覽商品,他看中了某一項商品,便點擊下單
  2. 此時訂單系統會生成一條訂單
  3. 訂單建立成功後,支付系統提供支付功能
  4. 當支付完成後,由積分系統爲該用戶增長積分

上述步驟二、三、4須要在一個事務中完成。對於傳統單體應用而言,實現事務很是簡單,只需將這三個步驟放在一個方法A中,再用Spring的@Transactional註解標識該方法便可。Spring經過數據庫的事務支持,保證這些步驟要麼全都執行完成,要麼全都不執行。但在這個微服務架構中,這三個步驟涉及三個系統,涉及三個數據庫,此時咱們必須在數據庫和應用系統之間,經過某項黑科技,實現分佈式事務的支持。

CAP理論

CAP理論說的是:在一個分佈式系統中,最多隻能知足C、A、P中的兩個需求。

CAP的含義:

  • C:Consistency 一致性 同一數據的多個副本是否實時相同。
  • A:Availability 可用性 可用性:必定時間內 & 系統返回一個明確的結果 則稱爲該系統可用。
  • P:Partition tolerance 分區容錯性 將同一服務分佈在多個系統中,從而保證某一個系統宕機,仍然有其餘系統提供相同的服務。

CAP理論告訴咱們,在分佈式系統中,C、A、P三個條件中咱們最多隻能選擇兩個。那麼問題來了,究竟選擇哪兩個條件較爲合適呢?

對於一個業務系統來講,可用性和分區容錯性是必需要知足的兩個條件,而且這二者是相輔相成的。業務系統之因此使用分佈式系統,主要緣由有兩個:

  • 提高總體性能 當業務量猛增,單個服務器已經沒法知足咱們的業務需求的時候,就須要使用分佈式系統,使用多個節點提供相同的功能,從而總體上提高系統的性能,這就是使用分佈式系統的第一個緣由。

  • 實現分區容錯性 單一節點 或 多個節點處於相同的網絡環境下,那麼會存在必定的風險,萬一該機房斷電、該地區發生天然災害,那麼業務系統就全面癱瘓了。爲了防止這一問題,採用分佈式系統,將多個子系統分佈在不一樣的地域、不一樣的機房中,從而保證系統高可用性。

這說明分區容錯性是分佈式系統的根本,若是分區容錯性不能知足,那使用分佈式系統將失去意義。

此外,可用性對業務系統也尤其重要。在大談用戶體驗的今天,若是業務系統時常出現「系統異常」、響應時間過長等狀況,這使得用戶對系統的好感度大打折扣,在互聯網行業競爭激烈的今天,相同領域的競爭者不甚枚舉,系統的間歇性不可用會立馬致使用戶流向競爭對手。所以,咱們只能經過犧牲一致性來換取系統的可用性分區容錯性。這也就是下面要介紹的BASE理論。

BASE理論

CAP理論告訴咱們一個悲慘但不得不接受的事實——咱們只能在C、A、P中選擇兩個條件。而對於業務系統而言,咱們每每選擇犧牲一致性來換取系統的可用性和分區容錯性。不過這裏要指出的是,所謂的「犧牲一致性」並非徹底放棄數據一致性,而是犧牲強一致性換取弱一致性。下面來介紹下BASE理論。

  • BA:Basic Available 基本可用
    • 整個系統在某些不可抗力的狀況下,仍然可以保證「可用性」,即必定時間內仍然可以返回一個明確的結果。只不過「基本可用」和「高可用」的區別是:
      • 「必定時間」能夠適當延長 當舉行大促時,響應時間能夠適當延長
      • 給部分用戶返回一個降級頁面 給部分用戶直接返回一個降級頁面,從而緩解服務器壓力。但要注意,返回降級頁面仍然是返回明確結果。
  • S:Soft State:柔性狀態 同一數據的不一樣副本的狀態,能夠不須要實時一致。
  • E:Eventual Consisstency:最終一致性 同一數據的不一樣副本的狀態,能夠不須要實時一致,但必定要保證通過必定時間後仍然是一致的。

酸鹼平衡

ACID可以保證事務的強一致性,即數據是實時一致的。這在本地事務中是沒有問題的,在分佈式事務中,強一致性會極大影響分佈式系統的性能,所以分佈式系統中遵循BASE理論便可。但分佈式系統的不一樣業務場景對一致性的要求也不一樣。如交易場景下,就要求強一致性,此時就須要遵循ACID理論,而在註冊成功後發送短信驗證碼等場景下,並不須要實時一致,所以遵循BASE理論便可。所以要根據具體業務場景,在ACID和BASE之間尋求平衡。

分佈式事務協議

下面介紹幾種實現分佈式事務的協議。

兩階段提交協議 2PC

分佈式系統的一個難點是如何保證架構下多個節點在進行事務性操做的時候保持一致性。爲實現這個目的,二階段提交算法的成立基於如下假設:

  • 該分佈式系統中,存在一個節點做爲協調者(Coordinator),其餘節點做爲參與者(Cohorts)。且節點之間能夠進行網絡通訊。
  • 全部節點都採用預寫式日誌,且日誌被寫入後即被保持在可靠的存儲設備上,即便節點損壞不會致使日誌數據的消失。
  • 全部節點不會永久性損壞,即便損壞後仍然能夠恢復。

1. 第一階段(投票階段):

  1. 協調者節點向全部參與者節點詢問是否能夠執行提交操做(vote),並開始等待各參與者節點的響應。
  2. 參與者節點執行詢問發起爲止的全部事務操做,並將Undo信息和Redo信息寫入日誌。(注意:若成功這裏其實每一個參與者已經執行了事務操做)
  3. 各參與者節點響應協調者節點發起的詢問。若是參與者節點的事務操做實際執行成功,則它返回一個"贊成"消息;若是參與者節點的事務操做實際執行失敗,則它返回一個"停止"消息。

2. 第二階段(提交執行階段):

當協調者節點從全部參與者節點得到的相應消息都爲"贊成"時:

  1. 協調者節點向全部參與者節點發出"正式提交(commit)"的請求。
  2. 參與者節點正式完成操做,並釋放在整個事務期間內佔用的資源。
  3. 參與者節點向協調者節點發送"完成"消息。
  4. 協調者節點受到全部參與者節點反饋的"完成"消息後,完成事務。

若是任一參與者節點在第一階段返回的響應消息爲"停止",或者 協調者節點在第一階段的詢問超時以前沒法獲取全部參與者節點的響應消息時:

  1. 協調者節點向全部參與者節點發出"回滾操做(rollback)"的請求。
  2. 參與者節點利用以前寫入的Undo信息執行回滾,並釋放在整個事務期間內佔用的資源。
  3. 參與者節點向協調者節點發送"回滾完成"消息。
  4. 協調者節點受到全部參與者節點反饋的"回滾完成"消息後,取消事務。

無論最後結果如何,第二階段都會結束當前事務。

 

二階段提交看起來確實可以提供原子性的操做,可是不幸的事,二階段提交仍是有幾個缺點的:

  1. 執行過程當中,全部參與節點都是事務阻塞型的。當參與者佔有公共資源時,其餘第三方節點訪問公共資源不得不處於阻塞狀態。
  2. 參與者發生故障。協調者須要給每一個參與者額外指定超時機制,超時後整個事務失敗。(沒有多少容錯機制)
  3. 協調者發生故障。參與者會一直阻塞下去。須要額外的備機進行容錯。(這個能夠依賴後面要講的Paxos協議實現HA)
  4. 二階段沒法解決的問題:協調者再發出commit消息以後宕機,而惟一接收到這條消息的參與者同時也宕機了。那麼即便協調者經過選舉協議產生了新的協調者,這條事務的狀態也是不肯定的,沒人知道事務是否被已經提交。

爲此,Dale Skeen和Michael Stonebraker在「A Formal Model of Crash Recovery in a Distributed System」中提出了三階段提交協議(3PC)。 

三階段提交協議 3PC

與兩階段提交不一樣的是,三階段提交有兩個改動點。

  • 引入超時機制。同時在協調者和參與者中都引入超時機制。
  • 在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段以前各參與節點的狀態是一致的。

也就是說,除了引入超時機制以外,3PC把2PC的準備階段再次一分爲二,這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。

1. CanCommit階段

3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者發送commit請求,參與者若是能夠提交就返回Yes響應,不然返回No響應。

  1. 事務詢問 協調者向參與者發送CanCommit請求。詢問是否能夠執行事務提交操做。而後開始等待參與者的響應。
  2. 響應反饋 參與者接到CanCommit請求以後,正常狀況下,若是其自身認爲能夠順利執行事務,則返回Yes響應,並進入預備狀態。不然反饋No

2. PreCommit階段

協調者根據參與者的反應狀況來決定是否能夠記性事務的PreCommit操做。根據響應狀況,有如下兩種可能。 假如協調者從全部的參與者得到的反饋都是Yes響應,那麼就會執行事務的預執行。

  1. 發送預提交請求 協調者向參與者發送PreCommit請求,並進入Prepared階段。

  2. 事務預提交 參與者接收到PreCommit請求後,會執行事務操做,並將undo和redo信息記錄到事務日誌中。

  3. 響應反饋 若是參與者成功的執行了事務操做,則返回ACK響應,同時開始等待最終指令。

假若有任何一個參與者向協調者發送了No響應,或者等待超時以後,協調者都沒有接到參與者的響應,那麼就執行事務的中斷。

  1. 發送中斷請求 協調者向全部參與者發送abort請求。

  2. 中斷事務 參與者收到來自協調者的abort請求以後(或超時以後,仍未收到協調者的請求),執行事務的中斷。

3. doCommit階段 該階段進行真正的事務提交,也能夠分爲如下兩種狀況。

該階段進行真正的事務提交,也能夠分爲如下兩種狀況。

3.1 執行提交

  1. 發送提交請求 協調接收到參與者發送的ACK響應,那麼他將從預提交狀態進入到提交狀態。並向全部參與者發送doCommit請求。
  2. 事務提交 參與者接收到doCommit請求以後,執行正式的事務提交。並在完成事務提交以後釋放全部事務資源。
  3. 響應反饋 事務提交完以後,向協調者發送Ack響應。
  4. 完成事務 協調者接收到全部參與者的ack響應以後,完成事務。

3.2 中斷事務 協調者沒有接收到參與者發送的ACK響應(多是接受者發送的不是ACK響應,也可能響應超時),那麼就會執行中斷事務。

  1. 發送中斷請求 協調者向全部參與者發送abort請求

  2. 事務回滾 參與者接收到abort請求以後,利用其在階段二記錄的undo信息來執行事務的回滾操做,並在完成回滾以後釋放全部的事務資源。

  3. 反饋結果 參與者完成事務回滾以後,向協調者發送ACK消息

  4. 中斷事務 協調者接收到參與者反饋的ACK消息以後,執行事務的中斷。

 

 

分佈式事務的解決方案

分佈式事務的解決方案有以下幾種:

  • 全局消息
  • 基於可靠消息服務的分佈式事務
  • TCC
  • 最大努力通知

方案1:全局事務(DTP模型)

全局事務基於DTP模型實現。DTP是由X/Open組織提出的一種分佈式事務模型——X/Open Distributed Transaction Processing Reference Model。它規定了要實現分佈式事務,須要三種角色:

  • AP:Application 應用系統 它就是咱們開發的業務系統,在咱們開發的過程當中,可使用資源管理器提供的事務接口來實現分佈式事務。

  • TM:Transaction Manager 事務管理器

    • 分佈式事務的實現由事務管理器來完成,它會提供分佈式事務的操做接口供咱們的業務系統調用。這些接口稱爲TX接口。
    • 事務管理器還管理着全部的資源管理器,經過它們提供的XA接口來同一調度這些資源管理器,以實現分佈式事務。
    • DTP只是一套實現分佈式事務的規範,並無定義具體如何實現分佈式事務,TM能夠採用2PC、3PC、Paxos等協議實現分佈式事務。
  • RM:Resource Manager 資源管理器

    • 可以提供數據服務的對象均可以是資源管理器,好比:數據庫、消息中間件、緩存等。大部分場景下,數據庫即爲分佈式事務中的資源管理器。
    • 資源管理器可以提供單數據庫的事務能力,它們經過XA接口,將本數據庫的提交、回滾等能力提供給事務管理器調用,以幫助事務管理器實現分佈式的事務管理。
    • XA是DTP模型定義的接口,用於向事務管理器提供該資源管理器(該數據庫)的提交、回滾等能力。
    • DTP只是一套實現分佈式事務的規範,RM具體的實現是由數據庫廠商來完成的。
  1. 有沒有基於DTP模型的分佈式事務中間件?
  1. DTP模型有啥優缺點?

方案2:基於可靠消息服務的分佈式事務

這種實現分佈式事務的方式須要經過消息中間件來實現。假設有A和B兩個系統,分別能夠處理任務A和任務B。此時系統A中存在一個業務流程,須要將任務A和任務B在同一個事務中處理。下面來介紹基於消息中間件來實現這種分佈式事務。

title
  • 在系統A處理任務A前,首先向消息中間件發送一條消息
  • 消息中間件收到後將該條消息持久化,但並不投遞。此時下游系統B仍然不知道該條消息的存在。
  • 消息中間件持久化成功後,便向系統A返回一個確認應答;
  • 系統A收到確認應答後,則能夠開始處理任務A;
  • 任務A處理完成後,向消息中間件發送Commit請求。該請求發送完成後,對系統A而言,該事務的處理過程就結束了,此時它能夠處理別的任務了。 但commit消息可能會在傳輸途中丟失,從而消息中間件並不會向系統B投遞這條消息,從而系統就會出現不一致性。這個問題由消息中間件的事務回查機制完成,下文會介紹。
  • 消息中間件收到Commit指令後,便向系統B投遞該消息,從而觸發任務B的執行;
  • 當任務B執行完成後,系統B向消息中間件返回一個確認應答,告訴消息中間件該消息已經成功消費,此時,這個分佈式事務完成。

上述過程能夠得出以下幾個結論:

  1. 消息中間件扮演者分佈式事務協調者的角色。
  2. 系統A完成任務A後,到任務B執行完成之間,會存在必定的時間差。在這個時間差內,整個系統處於數據不一致的狀態,但這短暫的不一致性是能夠接受的,由於通過短暫的時間後,系統又能夠保持數據一致性,知足BASE理論。

上述過程當中,若是任務A處理失敗,那麼須要進入回滾流程,以下圖所示:

title
  • 若系統A在處理任務A時失敗,那麼就會向消息中間件發送Rollback請求。和發送Commit請求同樣,系統A發完以後即可以認爲回滾已經完成,它即可以去作其餘的事情。
  • 消息中間件收到回滾請求後,直接將該消息丟棄,而不投遞給系統B,從而不會觸發系統B的任務B。

此時系統又處於一致性狀態,由於任務A和任務B都沒有執行。

上面所介紹的Commit和Rollback都屬於理想狀況,但在實際系統中,Commit和Rollback指令都有可能在傳輸途中丟失。那麼當出現這種狀況的時候,消息中間件是如何保證數據一致性呢?——答案就是超時詢問機制。

title

系統A除了實現正常的業務流程外,還需提供一個事務詢問的接口,供消息中間件調用。當消息中間件收到一條事務型消息後便開始計時,若是到了超時時間也沒收到系統A發來的Commit或Rollback指令的話,就會主動調用系統A提供的事務詢問接口詢問該系統目前的狀態。該接口會返回三種結果:

  • 提交 若得到的狀態是「提交」,則將該消息投遞給系統B。
  • 回滾 若得到的狀態是「回滾」,則直接將條消息丟棄。
  • 處理中 若得到的狀態是「處理中」,則繼續等待。

消息中間件的超時詢問機制可以防止上游系統因在傳輸過程當中丟失Commit/Rollback指令而致使的系統不一致狀況,並且能下降上游系統的阻塞時間,上游系統只要發出Commit/Rollback指令後即可以處理其餘任務,無需等待確認應答。而Commit/Rollback指令丟失的狀況經過超時詢問機制來彌補,這樣大大下降上游系統的阻塞時間,提高系統的併發度。

下面來講一說消息投遞過程的可靠性保證。 當上遊系統執行完任務並向消息中間件提交了Commit指令後,即可以處理其餘任務了,此時它能夠認爲事務已經完成,接下來消息中間件**必定會保證消息被下游系統成功消費掉!**那麼這是怎麼作到的呢?這由消息中間件的投遞流程來保證。

消息中間件向下遊系統投遞完消息後便進入阻塞等待狀態,下游系統便當即進行任務的處理,任務處理完成後便向消息中間件返回應答。消息中間件收到確認應答後便認爲該事務處理完畢!

若是消息在投遞過程當中丟失,或消息的確認應答在返回途中丟失,那麼消息中間件在等待確認應答超時以後就會從新投遞,直到下游消費者返回消費成功響應爲止。固然,通常消息中間件能夠設置消息重試的次數和時間間隔,好比:當第一次投遞失敗後,每隔五分鐘重試一次,一共重試3次。若是重試3次以後仍然投遞失敗,那麼這條消息就須要人工干預。

title title

有的同窗可能要問:消息投遞失敗後爲何不回滾消息,而是不斷嘗試從新投遞?

這就涉及到整套分佈式事務系統的實現成本問題。 咱們知道,當系統A將向消息中間件發送Commit指令後,它便去作別的事情了。若是此時消息投遞失敗,須要回滾的話,就須要讓系統A事先提供回滾接口,這無疑增長了額外的開發成本,業務系統的複雜度也將提升。對於一個業務系統的設計目標是,在保證性能的前提下,最大限度地下降系統複雜度,從而可以下降系統的運維成本。

不知你們是否發現,上游系統A向消息中間件提交Commit/Rollback消息採用的是異步方式,也就是當上遊系統提交完消息後即可以去作別的事情,接下來提交、回滾就徹底交給消息中間件來完成,而且徹底信任消息中間件,認爲它必定能正確地完成事務的提交或回滾。然而,消息中間件向下遊系統投遞消息的過程是同步的。也就是消息中間件將消息投遞給下游系統後,它會阻塞等待,等下游系統成功處理完任務返回確認應答後才取消阻塞等待。爲何這二者在設計上是不一致的呢?

首先,上游系統和消息中間件之間採用異步通訊是爲了提升系統併發度。業務系統直接和用戶打交道,用戶體驗尤其重要,所以這種異步通訊方式可以極大程度地下降用戶等待時間。此外,異步通訊相對於同步通訊而言,沒有了長時間的阻塞等待,所以系統的併發性也大大增長。但異步通訊可能會引發Commit/Rollback指令丟失的問題,這就由消息中間件的超時詢問機制來彌補。

那麼,消息中間件和下游系統之間爲何要採用同步通訊呢?

異步能提高系統性能,但隨之會增長系統複雜度;而同步雖然下降系統併發度,但實現成本較低。所以,在對併發度要求不是很高的狀況下,或者服務器資源較爲充裕的狀況下,咱們能夠選擇同步來下降系統的複雜度。 咱們知道,消息中間件是一個獨立於業務系統的第三方中間件,它不和任何業務系統產生直接的耦合,它也不和用戶產生直接的關聯,它通常部署在獨立的服務器集羣上,具備良好的可擴展性,因此沒必要太過於擔憂它的性能,若是處理速度沒法知足咱們的要求,能夠增長機器來解決。並且,即便消息中間件處理速度有必定的延遲那也是能夠接受的,由於前面所介紹的BASE理論就告訴咱們了,咱們追求的是最終一致性,而非實時一致性,所以消息中間件產生的時延致使事務短暫的不一致是能夠接受的。

方案3:最大努力通知(按期校對)

最大努力通知也被稱爲按期校對,其實在方案二中已經包含,這裏再單獨介紹,主要是爲了知識體系的完整性。這種方案也須要消息中間件的參與,其過程以下:

title
  • 上游系統在完成任務後,向消息中間件同步地發送一條消息,確保消息中間件成功持久化這條消息,而後上游系統能夠去作別的事情了;
  • 消息中間件收到消息後負責將該消息同步投遞給相應的下游系統,並觸發下游系統的任務執行;
  • 當下遊系統處理成功後,向消息中間件反饋確認應答,消息中間件即可以將該條消息刪除,從而該事務完成。

上面是一個理想化的過程,但在實際場景中,每每會出現以下幾種意外狀況:

  1. 消息中間件向下遊系統投遞消息失敗
  2. 上游系統向消息中間件發送消息失敗

對於第一種狀況,消息中間件具備重試機制,咱們能夠在消息中間件中設置消息的重試次數和重試時間間隔,對於網絡不穩定致使的消息投遞失敗的狀況,每每重試幾回後消息即可以成功投遞,若是超過了重試的上限仍然投遞失敗,那麼消息中間件再也不投遞該消息,而是記錄在失敗消息表中,消息中間件須要提供失敗消息的查詢接口,下游系統會按期查詢失敗消息,並將其消費,這就是所謂的「按期校對」。

若是重複投遞和按期校對都不能解決問題,每每是由於下游系統出現了嚴重的錯誤,此時就須要人工干預。

對於第二種狀況,須要在上游系統中創建消息重發機制。能夠在上游系統創建一張本地消息表,並將 任務處理過程向本地消息表中插入消息 這兩個步驟放在一個本地事務中完成。若是向本地消息表插入消息失敗,那麼就會觸發回滾,以前的任務處理結果就會被取消。若是這量步都執行成功,那麼該本地事務就完成了。接下來會有一個專門的消息發送者不斷地發送本地消息表中的消息,若是發送失敗它會返回重試。固然,也要給消息發送者設置重試的上限,通常而言,達到重試上限仍然發送失敗,那就意味着消息中間件出現嚴重的問題,此時也只有人工干預才能解決問題。

對於不支持事務型消息的消息中間件,若是要實現分佈式事務的話,就能夠採用這種方式。它可以經過重試機制+按期校對實現分佈式事務,但相比於第二種方案,它達到數據一致性的週期較長,並且還須要在上游系統中實現消息重試發佈機制,以確保消息成功發佈給消息中間件,這無疑增長了業務系統的開發成本,使得業務系統不夠純粹,而且這些額外的業務邏輯無疑會佔用業務系統的硬件資源,從而影響性能。

所以,儘可能選擇支持事務型消息的消息中間件來實現分佈式事務,如RocketMQ。

方案4:TCC(兩階段型、補償型)

TCC即爲Try Confirm Cancel,它屬於補償型分佈式事務。顧名思義,TCC實現分佈式事務一共有三個步驟:

  • Try:嘗試待執行的業務
    • 這個過程並未執行業務,只是完成全部業務的一致性檢查,並預留好執行所需的所有資源
  • Confirm:執行業務
    • 這個過程真正開始執行業務,因爲Try階段已經完成了一致性檢查,所以本過程直接執行,而不作任何檢查。而且在執行的過程當中,會使用到Try階段預留的業務資源。
  • Cancel:取消執行的業務
    • 若業務執行失敗,則進入Cancel階段,它會釋放全部佔用的業務資源,並回滾Confirm階段執行的操做。

下面以一個轉帳的例子來解釋下TCC實現分佈式事務的過程。

假設用戶A用他的帳戶餘額給用戶B發一個100元的紅包,而且餘額系統和紅包系統是兩個獨立的系統。

  • Try

    • 建立一條轉帳流水,並將流水的狀態設爲交易中
    • 將用戶A的帳戶中扣除100元(預留業務資源)
    • Try成功以後,便進入Confirm階段
    • Try過程發生任何異常,均進入Cancel階段
  • Confirm

    • 向B用戶的紅包帳戶中增長100元
    • 將流水的狀態設爲交易已完成
    • Confirm過程發生任何異常,均進入Cancel階段
    • Confirm過程執行成功,則該事務結束
  • Cancel

    • 將用戶A的帳戶增長100元
    • 將流水的狀態設爲交易失敗

在傳統事務機制中,業務邏輯的執行和事務的處理,是在不一樣的階段由不一樣的部件來完成的:業務邏輯部分訪問資源實現數據存儲,其處理是由業務系統負責;事務處理部分經過協調資源管理器以實現事務管理,其處理由事務管理器來負責。兩者沒有太多交互的地方,因此,傳統事務管理器的事務處理邏輯,僅須要着眼於事務完成(commit/rollback)階段,而沒必要關注業務執行階段。

TCC全局事務必須基於RM本地事務來實現全局事務

TCC服務是由Try/Confirm/Cancel業務構成的, 其Try/Confirm/Cancel業務在執行時,會訪問資源管理器(Resource Manager,下文簡稱RM)來存取數據。這些存取操做,必需要參與RM本地事務,以使其更改的數據要麼都commit,要麼都rollback。

這一點不難理解,考慮一下以下場景:

title

假設圖中的服務B沒有基於RM本地事務(以RDBS爲例,可經過設置auto-commit爲true來模擬),那麼一旦[B:Try]操做中途執行失敗,TCC事務框架後續決定回滾全局事務時,該[B:Cancel]則須要判斷[B:Try]中哪些操做已經寫到DB、哪些操做尚未寫到DB:假設[B:Try]業務有5個寫庫操做,[B:Cancel]業務則須要逐個判斷這5個操做是否生效,並將生效的操做執行反向操做。

不幸的是,因爲[B:Cancel]業務也有n(0<=n<=5)個反向的寫庫操做,此時一旦[B:Cancel]也中途出錯,則後續的[B:Cancel]執行任務更加繁重。由於,相比第一次[B:Cancel]操做,後續的[B:Cancel]操做還須要判斷先前的[B:Cancel]操做的n(0<=n<=5)個寫庫中哪幾個已經執行、哪幾個尚未執行,這就涉及到了冪等性問題。而對冪等性的保障,又極可能還須要涉及額外的寫庫操做,該寫庫操做又會由於沒有RM本地事務的支持而存在相似問題。。。可想而知,若是不基於RM本地事務,TCC事務框架是沒法有效的管理TCC全局事務的。

反之,基於RM本地事務的TCC事務,這種狀況則會很容易處理:[B:Try]操做中途執行失敗,TCC事務框架將其參與RM本地事務直接rollback便可。後續TCC事務框架決定回滾全局事務時,在知道「[B:Try]操做涉及的RM本地事務已經rollback」的狀況下,根本無需執行[B:Cancel]操做。

換句話說,基於RM本地事務實現TCC事務框架時,一個TCC型服務的cancel業務要麼執行,要麼不執行,不須要考慮部分執行的狀況。

TCC事務框架應該提供Confirm/Cancel服務的冪等性保障

通常認爲,服務的冪等性,是指針對同一個服務的屢次(n>1)請求和對它的單次(n=1)請求,兩者具備相同的反作用。

在TCC事務模型中,Confirm/Cancel業務可能會被重複調用,其緣由不少。好比,全局事務在提交/回滾時會調用各TCC服務的Confirm/Cancel業務邏輯。執行這些Confirm/Cancel業務時,可能會出現如網絡中斷的故障而使得全局事務不能完成。所以,故障恢復機制後續仍然會從新提交/回滾這些未完成的全局事務,這樣就會再次調用參與該全局事務的各TCC服務的Confirm/Cancel業務邏輯。

既然Confirm/Cancel業務可能會被屢次調用,就須要保障其冪等性。 那麼,應該由TCC事務框架來提供冪等性保障?仍是應該由業務系統自行來保障冪等性呢? 我的認爲,應該是由TCC事務框架來提供冪等性保障。若是僅僅只是極個別服務存在這個問題的話,那麼由業務系統來負責也是能夠的;然而,這是一類公共問題,毫無疑問,全部TCC服務的Confirm/Cancel業務存在冪等性問題。TCC服務的公共問題應該由TCC事務框架來解決;並且,考慮一下由業務系統來負責冪等性須要考慮的問題,就會發現,這無疑增大了業務系統的複雜度。

參考文獻


原文連接: http://www.javashuo.com/article/p-gmenruaf-gp.html
相關文章
相關標籤/搜索