在生產階段，首先給佇列傳送乙個半訊息，半訊息是一分全量訊息，只是在確認之前，不會被消費者發現，第二步實現本地事務，根據本地事務決定佇列上的訊息提交還是回滾，在本地事務完成之後給佇列傳送的訊息提交發生問題，佇列沒有收到提交或者回滾的命令，kafka會直接丟擲異常讓使用者自己處理，rocketmq有自己的訊息反查機制，它會輪詢去查哪些訊息還沒有得到確認，回去調使用者實現的乙個反查介面，來處理這條訊息的狀態。
大部分訊息佇列都會提供***機制，利用佇列的有序性，在***裡給每條訊息前面加乙個自增的標誌，在消費是檢測標誌是否是連續的就可以查出哪條訊息丟失了。
對於主題來說，保證不了嚴格的有序性，那麼在傳遞訊息上要設定給那個佇列上傳送訊息，檢查這個對應佇列的有序性，如果有多個生產者對應乙個佇列，那麼需要帶上生產者的標誌，檢查時檢查對應生產者的標誌順序。
訊息佇列實現分布式事務
訊息佇列中的 事務 主要解決的是訊息生產者和訊息消費者的資料一致性問題。電商下單步驟 1 生成訂單 2 刪除購物車 在分布式系統中，任何乙個步驟都有可能失敗，可能出現訂單資料與購物車資料不一致的情況，比如說 1 建立了訂單，沒有清理購物車 2 訂單沒建立成功，購物車裡面的商品卻被清掉了。訂單系統給訊...
使用事件和訊息佇列實現分布式事務
原文 不同於單一架構應用 monolith 分布式環境下,進行事務操作將變得困難,因為分布式環境通常會有多個資料來源,只用本地資料庫事務難以保證多個資料來源資料的一致性.這種情況下,可以使用兩階段或者三階段提交協議來完成分布式事務.但是使用這種方式一般來說效能較差,因為事務管理器需要在多個資料來源之...
介紹下用訊息佇列實現分布式事務
在oie的時代，上層應用開發人員總是認為資料庫足夠強大，所以很多業務可以做的非常簡單。比如a轉賬50元給b這個過程，只要寫乙個簡單sql語句塊就ok了。開始事務 a賬戶減去50 b賬戶增加50 提交事務。這個實現簡單明瞭，a賬戶錢減少的同時b賬戶的錢得到增加。但是當系統規模逐步擴大的時候，只能不斷要...