分布式事務(wù)方案

300本計(jì)算機(jī)編程的經(jīng)典書籍下載

AI全套：Python3+TensorFlow打造人臉識(shí)別智能小程序

最新人工智能資料-Google工程師親授 Tensorflow－入門到進(jìn)階

Java架構(gòu)全階段七期完整

黑馬頭條項(xiàng)目 - Java Springboot2.0（視頻、資料、代碼和講義）14天完整版

Spring核心編程思想

XA/二階段提交

基于XA協(xié)議的二階段提交

所謂的 XA 方案，即：兩階段提交，有一個(gè)事務(wù)管理器的概念，負(fù)責(zé)協(xié)調(diào)多個(gè)數(shù)據(jù)庫（資源管理器）的事務(wù)，事務(wù)管理器先問各個(gè)數(shù)據(jù)庫準(zhǔn)備好了嗎？如果每個(gè)數(shù)據(jù)庫都回 ok，那就正式提交事務(wù)，在各個(gè)數(shù)據(jù)庫上執(zhí)行操作；如果任何其中一個(gè)數(shù)據(jù)庫回答不 ok，那么就回滾事務(wù)。

JTA

JTA只是Java實(shí)現(xiàn)XA事務(wù)的一個(gè)規(guī)范，全稱Java事務(wù)規(guī)范JTA（Java Transaction API) ，我們?nèi)粘Ｊ褂玫?/span>@Transactional。都可以叫JTA事務(wù)管理。實(shí)際上，JTA是基于XA架構(gòu)上建模的，

鏈?zhǔn)?/h4>

對于Spring，還有個(gè)鏈?zhǔn)绞聞?wù)管理，就是聲明一個(gè)ChainedTransactionManager 將所有的數(shù)據(jù)源事務(wù)按順序放到該對象中，則事務(wù)會(huì)按相反的順序來執(zhí)行事務(wù)。事務(wù)依次提交后提交的事務(wù)若出錯(cuò)不能回滾。

1.start message transaction2.receive message3.start database transaction4.update database5.commit database transaction6.commit message transaction   ##當(dāng)這一步出現(xiàn)錯(cuò)誤時(shí)，上面的因?yàn)橐呀?jīng)commit，所以不會(huì)rollback

和JTA比起來，更輕量，但只能單機(jī)用。

參考

這個(gè)方案，很少用，一般來說某個(gè)系統(tǒng)內(nèi)部如果出現(xiàn)跨多個(gè)庫的這么一個(gè)操作，是不合規(guī)的。我可以給大家介紹一下， 現(xiàn)在微服務(wù)，一個(gè)大的系統(tǒng)分成幾十個(gè)甚至幾百個(gè)服務(wù)。一般來說，我們的規(guī)定和規(guī)范，是要求每個(gè)服務(wù)只能操作自己對應(yīng)的一個(gè)數(shù)據(jù)庫。

如果你要操作別的服務(wù)對應(yīng)的庫，不允許直連別的服務(wù)的庫，違反微服務(wù)架構(gòu)的規(guī)范，你隨便交叉胡亂訪問，幾百個(gè)服務(wù)的話，全體亂套，這樣的一套服務(wù)是沒法管理的，沒法治理的，可能會(huì)出現(xiàn)數(shù)據(jù)被別人改錯(cuò)，自己的庫被別人寫掛等情況。

如果你要操作別人的服務(wù)的庫，你必須是通過調(diào)用別的服務(wù)的接口來實(shí)現(xiàn)，絕對不允許交叉訪問別人的數(shù)據(jù)庫。

問題

• 同步阻塞問題：
  二階段提交算法在執(zhí)行過程中，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的。
  也就是說，當(dāng)本地資源管理器占有臨界資源時(shí)，其他資源管理器如果要訪問同一臨界資源，會(huì)處于阻塞狀態(tài)。
• 單點(diǎn)故障問題：基于 XA 的二階段提交算法類似于集中式算法，一旦事務(wù)管理器發(fā)生故障，整個(gè)系統(tǒng)都處于停滯狀態(tài)。
  尤其是在提交階段，一旦事務(wù)管理器發(fā)生故障，資源管理器會(huì)由于等待管理器的消息，而一直鎖定事務(wù)資源，導(dǎo)致整個(gè)系統(tǒng)被阻塞。
• 數(shù)據(jù)不一致問題：在提交階段，當(dāng)協(xié)調(diào)者向參與者發(fā)送 DoCommit 請求之后，如果發(fā)生了局部網(wǎng)絡(luò)異常，或者在發(fā)送提交請求的過程中協(xié)調(diào)者發(fā)生了故障，就會(huì)導(dǎo)致只有一部分參與者接收到了提交請求并執(zhí)行提交操作，但其他未接到提交請求的那部分參與者則無法執(zhí)行事務(wù)提交。
  于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致的問題。

3PC

• 同時(shí)在協(xié)調(diào)者和參與者中引入超時(shí)機(jī)制。
  如果協(xié)調(diào)者或參與者在規(guī)定的時(shí)間內(nèi)沒有接收到來自其他節(jié)點(diǎn)的響應(yīng)，就會(huì)根據(jù)當(dāng)前的狀態(tài)選擇提交或者終止整個(gè)事務(wù)。
• 在第一階段和第二階段中間引入了一個(gè)準(zhǔn)備階段，也就是在提交階段之前，加入了一個(gè)預(yù)提交階段。
  在預(yù)提交階段排除一些不一致的情況，保證在最后提交之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

canCommit

precommit

• 如果所有參與者回復(fù)的都是“Yes”，那么協(xié)調(diào)者就會(huì)執(zhí)行事務(wù)的預(yù)執(zhí)行：

  
  

• 發(fā)送預(yù)提交請求。協(xié)調(diào)者向參與者發(fā)送 PreCommit 請求，進(jìn)入預(yù)提交階段。

• 事務(wù)預(yù)提交。

  參與者接收到 PreCommit 請求后執(zhí)行事務(wù)操作，并將 Undo 和 Redo 信息記錄到事務(wù)日志中。

• 響應(yīng)反饋。

  如果參與者成功執(zhí)行了事務(wù)操作，則返回 ACK 響應(yīng)，同時(shí)開始等待最終指令。

• 假如任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了“No”消息，或者等待超時(shí)之后，協(xié)調(diào)者都沒有收到參與者的響應(yīng)，就執(zhí)行中斷事務(wù)的操作：

  
  

  
  

• 發(fā)送中斷請求。

  協(xié)調(diào)者向所有參與者發(fā)送“Abort”消息。

• 終斷事務(wù)。

  參與者收到“Abort”消息之后，或超時(shí)后仍未收到協(xié)調(diào)者的消息，執(zhí)行事務(wù)的終斷操作。

doCommit

DoCmmit 階段進(jìn)行真正的事務(wù)提交，根據(jù) PreCommit 階段協(xié)調(diào)者發(fā)送的消息，進(jìn)入執(zhí)行提交階段或事務(wù)中斷階段。

• 執(zhí)行提交階段：
  
  
• 發(fā)送提交請求。
  協(xié)調(diào)者接收到所有參與者發(fā)送的 Ack 響應(yīng)，從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)，并向所有參與者發(fā)送 DoCommit 消息。
• 事務(wù)提交。
  參與者接收到 DoCommit 消息之后，正式提交事務(wù)。
  完成事務(wù)提交之后，釋放所有鎖住的資源。
• 響應(yīng)反饋。
  參與者提交完事務(wù)之后，向協(xié)調(diào)者發(fā)送 Ack 響應(yīng)。
• 完成事務(wù)。
  協(xié)調(diào)者接收到所有參與者的 Ack 響應(yīng)之后，完成事務(wù)。
• 事務(wù)中斷階段：
  
  
• 發(fā)送中斷請求。
  協(xié)調(diào)者向所有參與者發(fā)送 Abort 請求。
• 事務(wù)回滾。
  參與者接收到 Abort 消息之后，利用其在 PreCommit 階段記錄的 Undo 信息執(zhí)行事務(wù)的回滾操作，并釋放所有鎖住的資源。
• 反饋結(jié)果。
  參與者完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送 Ack 消息。

TCC

TCC 的全稱是：Try 、 Confirm 、 Cancel 。

• Try 階段：

  這個(gè)階段說的是對各個(gè)服務(wù)的資源做檢測以及對資源進(jìn)行鎖定或者預(yù)留。

• Confirm 階段：

  這個(gè)階段說的是在各個(gè)服務(wù)中執(zhí)行實(shí)際的操作。

• Cancel 階段：

  如果任何一個(gè)服務(wù)的業(yè)務(wù)方法執(zhí)行出錯(cuò)，那么這里就需要進(jìn)行補(bǔ)償，就是執(zhí)行已經(jīng)執(zhí)行成功的業(yè)務(wù)邏輯的回滾操作。

這種方案說實(shí)話幾乎很少人使用。因?yàn)檫@個(gè)事務(wù)回滾實(shí)際上是嚴(yán)重依賴于你自己寫代碼來回滾和補(bǔ)償了，會(huì)造成補(bǔ)償代碼巨大，非常之惡心。等于一個(gè)借口拆成三個(gè)。

一般來說跟錢相關(guān)的，支付、交易，會(huì)用 TCC，嚴(yán)格保證分布式事務(wù)要么全部成功，要么全部自動(dòng)回滾，嚴(yán)格保證資金正確。
而且最好是各個(gè)業(yè)務(wù)執(zhí)行的時(shí)間都比較短。

Sega

金融核心等業(yè)務(wù)可能會(huì)選擇 TCC 方案，以追求強(qiáng)一致性和更高的并發(fā)量，而對于更多的金融核心以下的業(yè)務(wù)系統(tǒng) 往往會(huì)選擇補(bǔ)償事務(wù)，補(bǔ)償事務(wù)處理在 30 多年前就提出了 Saga 理論，隨著微服務(wù)的發(fā)展，近些年才逐步受到大家的關(guān)注。目前業(yè)界比較公認(rèn)的是采用 Saga 作為長事務(wù)的解決方案。

基本原理

業(yè)務(wù)流程中每個(gè)參與者都提交本地事務(wù)，若某一個(gè)參與者失敗，則補(bǔ)償前面已經(jīng)成功的參與者。下圖左側(cè)是正常的事務(wù)流程，當(dāng)執(zhí)行到 T3 時(shí)發(fā)生了錯(cuò)誤，則開始執(zhí)行右邊的事務(wù)補(bǔ)償流程，反向執(zhí)行 T3、T2、T1 的補(bǔ)償服務(wù) C3、C2、C1，將 T3、T2、T1 已經(jīng)修改的數(shù)據(jù)補(bǔ)償?shù)簟?/p>

使用場景

對于一致性要求高、短流程、并發(fā)高 的場景，如：金融核心系統(tǒng)，會(huì)優(yōu)先考慮 TCC 方案。而在另外一些場景下，我們并不需要這么強(qiáng)的一致性，只需要保證最終一致性即可。

比如 很多金融核心以上的業(yè)務(wù)（渠道層、產(chǎn)品層、系統(tǒng)集成層），這些系統(tǒng)的特點(diǎn)是最終一致即可、流程多、流程長、還可能要調(diào)用其它公司的服務(wù)。這種情況如果選擇 TCC 方案開發(fā)的話，一來成本高，二來無法要求其它公司的服務(wù)也遵循 TCC 模式。同時(shí)流程長，事務(wù)邊界太長，加鎖時(shí)間長，也會(huì)影響并發(fā)性能。

所以 Saga 模式的適用場景是：

• 業(yè)務(wù)流程長、業(yè)務(wù)流程多；

• 參與者包含其它公司或遺留系統(tǒng)服務(wù)，無法提供 TCC 模式要求的三個(gè)接口。

優(yōu)勢

• 一階段提交本地事務(wù)，無鎖，高性能；

• 參與者可異步執(zhí)行，高吞吐；

• 補(bǔ)償服務(wù)易于實(shí)現(xiàn)，因?yàn)橐粋€(gè)更新操作的反向操作是比較容易理解的。

缺點(diǎn)

• 不保證事務(wù)的隔離性。

可靠消息最終一致性

流程

1. A 系統(tǒng)先發(fā)送一個(gè) prepared 消息到 mq，如果這個(gè) prepared 消息發(fā)送失敗那么就直接取消操作別執(zhí)行了；
2. 如果這個(gè)消息發(fā)送成功過了，那么接著執(zhí)行本地事務(wù)，如果成功就告訴 mq 發(fā)送確認(rèn)消息，如果失敗就告訴 mq 回滾消息；
3. 如果發(fā)送了確認(rèn)消息，那么此時(shí) B 系統(tǒng)會(huì)接收到確認(rèn)消息，然后執(zhí)行本地的事務(wù)；
4. mq 會(huì)自動(dòng)定時(shí)輪詢所有 prepared 消息回調(diào)你的接口，問你，這個(gè)消息是不是本地事務(wù)處理失敗了，所有沒發(fā)送確認(rèn)的消息，是繼續(xù)重試還是回滾？
   一般來說這里你就可以查下數(shù)據(jù)庫看之前本地事務(wù)是否執(zhí)行，如果回滾了，那么這里也回滾吧。
   這個(gè)就是避免可能本地事務(wù)執(zhí)行成功了，而確認(rèn)消息卻發(fā)送失敗了。
5. 這個(gè)方案里，要是系統(tǒng) B 的事務(wù)失敗了咋辦？
   重試咯，自動(dòng)不斷重試直到成功，如果實(shí)在是不行，要么就是針對重要的資金類業(yè)務(wù)進(jìn)行回滾，比如 B 系統(tǒng)本地回滾后，想辦法通知系統(tǒng) A 也回滾；
   或者是發(fā)送報(bào)警由人工來手工回滾和補(bǔ)償。
6. 這個(gè)還是比較合適的，目前國內(nèi)互聯(lián)網(wǎng)公司大都是這么玩兒的，要不你就用 RocketMQ 支持的，要不你就自己基于類似 ActiveMQ？
   RabbitMQ？
   自己封裝一套類似的邏輯出來，總之思路就是這樣子的。

下單為例

以下單為例

1. 訂單系統(tǒng)把訂單消息發(fā)給消息中間件，消息狀態(tài)標(biāo)記為“待確認(rèn)”。
2. 消息中間件收到消息后，進(jìn)行消息持久化操作，即在消息存儲(chǔ)系統(tǒng)中新增一條狀態(tài)為“待發(fā)送”的消息。
3. 消息中間件返回消息持久化結(jié)果（成功 / 失敗），訂單系統(tǒng)根據(jù)返回結(jié)果判斷如何進(jìn)行業(yè)務(wù)操作。
   失敗，放棄訂單，結(jié)束（必要時(shí)向上層返回失敗結(jié)果）；
   成功，則創(chuàng)建訂單。
4. 訂單操作完成后，把操作結(jié)果（成功 / 失敗）發(fā)送給消息中間件。
5. 消息中間件收到業(yè)務(wù)操作結(jié)果后，根據(jù)結(jié)果進(jìn)行處理：
   失敗，刪除消息存儲(chǔ)中的消息，結(jié)束；
   成功，則更新消息存儲(chǔ)中的消息狀態(tài)為“待發(fā)送（可發(fā)送）”，并執(zhí)行消息投遞。
6. 如果消息狀態(tài)為“可發(fā)送”，則 MQ 會(huì)將消息發(fā)送給支付系統(tǒng)，表示已經(jīng)創(chuàng)建好訂單，需要對訂單進(jìn)行支付。
   支付系統(tǒng)也按照上述方式進(jìn)行訂單支付操作。
7. 訂單系統(tǒng)支付完成后，會(huì)將支付消息返回給消息中間件，中間件將消息傳送給訂單系統(tǒng)。
   訂單系統(tǒng)再調(diào)用庫存系統(tǒng)，進(jìn)行出貨操作。

最大努力通知方案

這個(gè)方案的大致意思就是：

1. 系統(tǒng) A 本地事務(wù)執(zhí)行完之后，發(fā)送個(gè)消息到 MQ；

2. 這里會(huì)有個(gè)專門消費(fèi) MQ 的最大努力通知服務(wù)，這個(gè)服務(wù)會(huì)消費(fèi) MQ 然后寫入數(shù)據(jù)庫中記錄下來，或者是放入個(gè)內(nèi)存隊(duì)列也可以，接著調(diào)用系統(tǒng) B 的接口；

3. 要是系統(tǒng) B 執(zhí)行成功就 ok 了；

   要是系統(tǒng) B 執(zhí)行失敗了，那么最大努力通知服務(wù)就定時(shí)嘗試重新調(diào)用系統(tǒng) B，反復(fù) N 次，最后還是不行就放棄。

總結(jié)

一般來說，最嚴(yán)格的就是TCC。其他常用的是基于消息的最終一致性。

ACID

Base理論

BASE 理論包括基本可用（Basically Available）、柔性狀態(tài)（Soft State）和最終一致性（Eventual Consistency）。

• 基本可用：

  分布式系統(tǒng)出現(xiàn)故障的時(shí)候，允許損失一部分功能的可用性。

  比如，某些電商 618 大促的時(shí)候，會(huì)對一些非核心鏈路的功能進(jìn)行降級處理。

• 柔性狀態(tài)：

  在柔性事務(wù)中，允許系統(tǒng)存在中間狀態(tài)，且這個(gè)中間狀態(tài)不會(huì)影響系統(tǒng)整體可用性。

  比如，數(shù)據(jù)庫讀寫分離，寫庫同步到讀庫（主庫同步到從庫）會(huì)有一個(gè)延時(shí)，其實(shí)就是一種柔性狀態(tài)。

• 最終一致性：

  事務(wù)在操作過程中可能會(huì)由于同步延遲等問題導(dǎo)致不一致，但最終狀態(tài)下，數(shù)據(jù)都是一致的。

可見，BASE 理論為了支持大型分布式系統(tǒng)，通過犧牲強(qiáng)一致性，保證最終一致性，來獲得高可用性，是對 ACID 原則的弱化。具體到今天的三種分布式事務(wù)實(shí)現(xiàn)方式，二階段提交、三階段提交方法，遵循的是 ACID 原則，而消息最終一致性方案遵循的就是 BASE 理論。

看完本文有收獲？請轉(zhuǎn)發(fā)分享給更多人

往期資源：