分佈式事務(3)---RocketMQ實現分佈式事務原理

分佈式事務(3)—RocketMQ實現分佈式事務原理

以前講過有關分佈式事務2PC、3PC、TCC的理論知識,博客地址：

一、分佈式事務(1)---2PC和3PC原理

二、分佈式事務(2）---TCC原理

這篇講有關RocketMQ實現分佈式事務的理論知識，下篇也會示例 經過SpringCloud來實例RocketMQ實現分佈式事務的項目。

1、舉個分佈式事務場景

列子：假設 A 給 B 轉 100塊錢，同時它們不是同一個服務上。

目標：就是 A 減100塊錢，B 加100塊錢。

實際狀況可能有四種：

1）就是A帳戶減100 （成功），B帳戶加100 （成功）

2）就是A帳戶減100（失敗），B帳戶加100 （失敗）

3）就是A帳戶減100（成功），B帳戶加100 （失敗）

4）就是A帳戶減100 （失敗），B帳戶加100 （成功）

這裏 第1和第2 種狀況是可以保證事務的一致性的，可是 第3和第4 是沒法保證事務的一致性的。

那咱們來看下RocketMQ是如何來保證事務的一致性的。

2、RocketMQ實現分佈式事務原理

RocketMQ雖然以前也支持分佈式事務，但並無開源，等到RocketMQ 4.3才正式開源。

一、基礎概念

最終一致性

RocketMQ是一種最終一致性的分佈式事務，就是說它保證的是消息最終一致性，而不是像2PC、3PC、TCC那樣強一致分佈式事務，至於爲何說它是最終一致性事務下面會詳細說明。

Half Message(半消息)

是指暫不能被Consumer消費的消息。Producer 已經把消息成功發送到了 Broker 端，但此消息被標記爲暫不能投遞狀態，處於該種狀態下的消息稱爲半消息。須要 Producer

對消息的二次確認後，Consumer才能去消費它。

消息回查

因爲網絡閃段，生產者應用重啓等緣由。致使 Producer 端一直沒有對 Half Message(半消息) 進行 二次確認。這是Brock服務器會定時掃描長期處於半消息的消息，會

主動詢問 Producer端 該消息的最終狀態(Commit或者Rollback),該消息即爲 消息回查。

二、分佈式事務交互流程

理解這張阿里官方的圖，就能理解RocketMQ分佈式事務的原理了。

咱們來講明下上面這張圖

一、A服務先發送個Half Message給Brock端，消息中攜帶 B服務 即將要+100元的信息。

二、當A服務知道Half Message發送成功後，那麼開始第3步執行本地事務。

三、執行本地事務(會有三種狀況一、執行成功。二、執行失敗。三、網絡等緣由致使沒有響應)

4.1)、若是本地事務成功，那麼Product像Brock服務器發送Commit,這樣B服務就能夠消費該message。

4.2)、若是本地事務失敗，那麼Product像Brock服務器發送Rollback,那麼就會直接刪除上面這條半消息。

4.3)、若是由於網絡等緣由遲遲沒有返回失敗仍是成功，那麼會執行RocketMQ的回調接口,來進行事務的回查。

從上面流程能夠得知 只有A服務本地事務執行成功 ，B服務才能消費該message。

而後咱們再來思考幾個問題？

爲何要先發送Half Message(半消息)

我以爲主要有兩點

1）能夠先確認 Brock服務器是否正常 ，若是半消息都發送失敗了 那說明Brock掛了。

2）能夠經過半消息來回查事務，若是半消息發送成功後一直沒有被二次確認，那麼就會回查事務狀態。

什麼狀況會回查

也會有兩種狀況

1）執行本地事務的時候，因爲忽然網絡等緣由一直沒有返回執行事務的結果(commit或者rollback)致使最終返回UNKNOW，那麼就會回查。

2) 本地事務執行成功後，返回Commit進行消息二次確認的時候的服務掛了，在重啓服務那麼這個時候在brock端
   它仍是個Half Message(半消息)，這也會回查。

特別注意: 若是回查，那麼必定要先查看當前事務的執行狀況，再看是否須要從新執行本地事務。

想象下若是出現第二種狀況而引發的回查，若是不先查看當前事務的執行狀況，而是直接執行事務，那麼就至關於成功執行了兩個本地事務。

爲何說MQ是最終一致性事務

經過上面這幅圖，咱們能夠看出，在上面舉例事務不一致的兩種狀況中，永遠不會發生

A帳戶減100 （失敗），B帳戶加100 （成功）

由於：若是A服務本地事務都失敗了，那B服務永遠不會執行任何操做，由於消息壓根就不會傳到B服務。

那麼 A帳戶減100 （成功），B帳戶加100 （失敗） 會不會可能存在的。

答案是會的

由於A服務只負責當我消息執行成功了，保證消息可以送達到B,至於B服務接到消息後最終執行結果A並無論。

那B服務失敗怎麼辦？

若是B最終執行失敗，幾乎能夠判定就是代碼有問題因此才引發的異常，由於消費端RocketMQ有重試機制，若是不是代碼問題通常重試幾回就能成功。

若是是代碼的緣由引發屢次重試失敗後，也沒有關係，將該異常記錄下來，由人工處理，人工兜底處理後，就可讓事務達到最終的一致性。

只要本身變優秀了，其餘的事情纔會跟着好起來（上將7）