分布式事務消息隊列解決方案

2020-09-10 世説新語

1.如果有A,B,C三個方法,A,B方法在同一個微服務,C方法在另外一個微服務

2.在A方法和B方法中間加入通知C的消息顯然是不科學的,因為B如果失敗了,C是不應該提交的

3.如果在A和B方法後面加上通知C的消息也不行，因為如果A,B一起提交失敗了,那麼C也是不應該通知的

4.把A和B放在同一個方法裡面,把通知C的放在一個方法裡面,A,B提交了之後再通知C是否可行呢

5.其實也是不行的,因為通知C可能會失敗啊,如果發送的通知失敗了,也是個問題

6.所以把通知放在A,B之前,先發送一個事務消息到rocketMq,rocketMq不會馬上通知C

7.等A,B成功執行了之後,再通知rocketMq,把這條事務消息處理了,那麼才會通知C

8.如果A,B成功執行之後,通知rocketMq的時候消息發送失敗了怎麼辦呢

9.這個時候rocketMq會有個查詢機制,查詢客戶端的事務有沒有提交,如果有提交那麼通知C

10.消息隊列解決分布式事務簡單有效,但是出現失敗的可能性比其他分布式事務的解決方案差點

11.消息隊列解決方案還有一種是記錄本地消息表,失敗一直重發,也可以解決分布式事務

12.比如充值的操作,錢已經到帳了,但是因為網絡的問題回調失敗,那麼可以用延時隊列實現多久重發

13.如果重發失敗了,繼續向隊列裡面寫數據,這種分布式解決方案時效太差,但是實現簡單

相關焦點

  • 基於RabbitMQ消息隊列的分布式事務解決方案
    極速了解MQ 介紹Rabbitmg用於解決分布式事務必須掌握的5個核心概念 一款分布式消息中間件，基於erlang語言開發， 具備語言級別的高並發處理能力。和Spring框架是同一家公司。
  • 分布式事務解決方案常見誤區與實用建議
    前言最近，工作中要為現在的老系統做拆分和升級，剛好遇到了分布式事務、冪等控制、異步消息亂序和補償方案等問題，剛好基於實踐結合個人的看法記錄一下一些方案和思路。目前業界提供的解決方案業界目前主流的分布式事務解決方案主要有：多階段提交方案（2PC、3PC）、補償事務（TCC）和消息事務（主要是RocketMQ，基本思想也是多階段提交方案，並且基於中間提供件輪詢和重試，其他消息隊列中間件並沒有實現分布式事務）。
  • 面試官：談談對分布式事務的一點理解和解決方案
    目前業界提供的解決方案業界目前主流的分布式事務解決方案主要有：多階段提交方案（2PC、3PC）、補償事務（TCC）和消息事務（主要是RocketMQ，基本思想也是多階段提交方案，並且基於中間提供件輪詢和重試，其他消息隊列中間件並沒有實現分布式事務）。
  • 5分鐘理解架構師必備的：分布式事務解決方案
    分布式下，我想要強一致性為了保證分布式事務的正確性，目前網際網路領域有幾種流行的解決方案，但是大部分都沒有像XA事務一樣形成標準的工業規範。但是這些方案在某些特定的行業或者業務場景下卻得到了越來越多的開發者的認可。
  • cn-rmq 1.0.1 發布,基於可靠消息的分布式事務解決方案
    RMQ（reliable-message-queue）是基於可靠消息的分布式事務解決方案。
  • 字節跳動面試官這樣問消息隊列：分布式事務、重複消費、順序消費
    撈一下上一期，簡單的介紹了一下消息隊列的基礎知識，裡面有消息隊列的應用場景，以及使用之後可能帶來的問題，但是上期沒對怎麼解決這些問題做回答，因為要控制篇幅嘛（明明是自己覺得MQ寫不了多少期，要多懟一期出來！
  • 如何選擇分布式事務解決方案?
    阿里妹導讀：分布式事務中涉及的參與者分布在異步網絡中，參與者通過網絡通信來達到分布式一致性，網絡通信不可避免出現失敗、超時的情況，因此分布式事務的實現比本地事務面臨更多的困難。本文歸納總結五種分布式事務解決方案，並剖析其特點。較長，同學們可收藏後再看。文末福利：Java 程式設計師學習清單。
  • 「吊打面試,擊中要害」分布式事務解決方案
    分布式事務解決方案有很多種，最要包括基於XA協議的兩階段提交方案、本地消息表方案、TCC事務補償型方案、可靠消息最終一致性方案、盡最大努力通知型方案等。面試的時候不可能長篇大論，所以能答上下面這三種方案就七八不離十。
  • 5種分布式事務解決方案優缺點對比
    背景分布式事務是企業集成中的一個技術難點，也是每一個分布式系統架構中都會涉及到的一個東西，特別是在微服務架構中，幾乎可以說是無法避免。 Basically Available（基本可用） Soft state（軟狀態） Eventually consistent（最終一致性）解決方案01 兩階段提交（2PC）兩階段提交2PC是分布式事務中最強大的事務類型之一，兩段提交就是分兩個階段提交，第一階段詢問各個事務數據源是否準備好，第二階段才真正將數據提交給事務數據源
  • Spring全家桶、Dubbo、分布式、消息隊列後端必備全套開源項目
    Kafka 入門》 對應 lab-03《Kafka 書單整理》ActiveMQ《ActiveMQ 極簡入門》分布式事務專欄目前分布式事務的解決方案有AT 方案《Spring Boot 分布式事務 Seata 入門》的「2.
  • 消息隊列之事務消息，RocketMQ 和 Kafka是如何？
    今天我們來談一談消息隊列的事務消息，一說起事務相信大家都不陌生，腦海裡蹦出來的就是 ACID。通常我們理解的事務就是為了一些更新操作要麼都成功，要麼都失敗，不會有中間狀態的產生，而 ACID 是一個嚴格的事務實現的定義，不過在單體系統時候一般都不會嚴格的遵循 ACID 的約束來實現事務，更別說分布式系統了。
  • 開源分布式事務解決方案-Seata,1.0.0版正式發布
    題圖 from pixabay什麼是分布式事務分布式事務就是指事務的參與者、支持事務的伺服器、資源伺服器以及事務管理器分別位於不同的分布式系統的不同節點之上。簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的伺服器上，且屬於不同的應用，分布式事務需要保證這些小操作要麼全部成功，要麼全部失敗。
  • 分布式事務的七種實現方案匯總
    而阿里提供的RocketMQ則在解決了消息的順序性和重複消息冪等性的基礎上，實現了對事務的支持（詳見參考博客5）。因而基於RocketMQ，就可以實現分布式事務（詳見參考博客6）。實際上，參考博客6中給出了兩套基於消息服務的實現方案：第一，基於本地消息服務的方案，針對的是消息中間件本身不支持事務的場景，需要從應用設計的角度實現消息數據的可靠性；第二，基於獨立消息服務的方案，針對的是消息中間件本身支持事務的場景。
  • 消息隊列之事務消息，RocketMQ 和 Kafka是如何做的？
    今天我們來談一談消息隊列的事務消息，一說起事務相信大家都不陌生，腦海裡蹦出來的就是 ACID。通常我們理解的事務就是為了一些更新操作要麼都成功，要麼都失敗，不會有中間狀態的產生，而 ACID 是一個嚴格的事務實現的定義，不過在單體系統時候一般都不會嚴格的遵循 ACID 的約束來實現事務，更別說分布式系統了。
  • 分布式消息隊列的避坑指南
    當消息隊列遇上分布式，就變成了分布式消息隊列，也就是說請求在消費隊列發給了多個伺服器節點，所有伺服器節點的消息隊列之和就是請求數。在分布式中最高頻的問題便是數據一致性問題，多個伺服器節點因為時間空間的不一致從而接收到的數據、傳出去的數據都不一樣，在消息隊列中最高頻的問題便是生產消費不一致，從而導致數據丟失等。
  • 微服務架構下分布式事務解決方案——阿里GTS
    分布式事務已經成為微服務落地最大的阻礙，也是最具挑戰性的一個技術難題。 為此，本文將深入和大家探討微服務架構下，分布式事務的各種解決方案，並重點為大家解讀阿里巴巴提出的分布式事務解決方案----GTS。
  • 「技術貼」微服務中臺技術解析之分布式事務方案和實踐
    MySQL給出的解決方案是多版本並發控制（MVCC），然而不是所有的資料庫都支持這一特性。控制並發的另一條思路是消除並發，化並為串，一般通過搶佔鎖或者使用隊列來實現。考慮到等待鎖而產生的性能損耗以及鎖順序不一致導致的互鎖問題，優先考慮使用隊列。Durability：指成功提交到系統的事務不能中途丟失，即實現數據持久化。
  • 基於MQ的分布式事務方案，斷電了咋辦
    涉及到分布式、微服務，面試一定會問分布式事務的處理方案，強一致性這種就不說了，很好奇現在是否還有企業在分布式系統中使用強一致性。最終一致性的實現，例如2PC、TCC本文就不說了，性能上，實現成本上都不理想。我從工作中以及跟朋友交流接觸到的消息來看，採用MQ較多。這就衍生出一個被問到很多次的問題：給MQ發消息失敗了怎麼辦，例如MQ伺服器斷電了。
  • 微服務架構下分布式事務處理方案選擇和對比
    3.跨服務由於Web Service服務本身無狀態，即使是同一個資料庫提供給處理的兩個WebService服務，在進行調用和組合的時候也屬於分布式事務控制。對於分布式事務的主流解決方法，主要包括了XA兩階段提交，事務補償和基於BASE的最終一致性（可靠消息傳輸），首先再對這三種方法做下簡單描述。
  • RocketMQ 和 Kafka 是如何實現分布式事務消息？
    今天我們來談一談消息隊列的事務消息，一說起事務相信大家都不陌生，腦海裡蹦出來的就是 ACID。通常我們理解的事務就是為了一些更新操作要麼都成功，要麼都失敗，不會有中間狀態的產生，而 ACID 是一個嚴格的事務實現的定義，不過在單體系統時候一般都不會嚴格的遵循 ACID 的約束來實現事務，更別說分布式系統了。