分散式事務之MQ可靠訊息
使用MQ可靠訊息能夠解決分散式事務的最終一致性,但不是實時一致(強一致性)。所以使用時要注意應用場景。
MQ可靠訊息:
1.預發訊息:MQ傳送訊息之前把訊息的資訊先存到資料庫中留底,設定一個欄位狀態為待確認。(作用:能夠知道這條訊息是否傳送成功,可進行人工補償)
2.進行業務操作
3.向MQ傳送訊息,傳送成功後把預發訊息的狀態改為傳送中(表示成功傳送),如果失敗就不需要修改
應用場景:充值業務 訂單->賬務
充值成功後
第一步,將訊息的資訊先存到資料庫中留底,設定一個欄位狀態為待確認(預發訊息)
第二步,修改充值的訂單狀態為充值功能
第三步,傳送MQ訊息到賬務系統,通知賬務系統記錄訂單的賬務明細
特殊MQ可靠訊息保證事務的場景:使用者短時間多筆消費 訂單->賬戶扣款
如果消費時,先修改訂單狀態,再扣款。有10筆訂單的消費狀態都修成了成功,但是賬戶的餘額不夠錢扣除10筆訂單。這樣就會出問題了
解決的方案:使用者消費時,先扣款再修改訂單
不能使用MQ可靠訊息保證事務的場景:交易完成後既要 扣款 也要 減庫存。這種場場景要使用強一致性事務
相關推薦
分散式事務之MQ可靠訊息
使用MQ可靠訊息能夠解決分散式事務的最終一致性,但不是實時一致(強一致性)。所以使用時要注意應用場景。 MQ可靠訊息: 1.預發訊息:MQ傳送訊息之前把訊息的資訊先存到資料庫中留底,設定一個欄位狀態為待確認。(作用:能夠知道這條訊息是否傳送成功,可進行人工補償) 2.進行業務操作 3
分散式事務:基於可靠訊息服務
微服務倡導將複雜的單體應用拆分為若干個功能簡單、鬆耦合的服務,而於此同時就會引入多個服務之間的分散式事務的問題。 眾所周知,資料庫能實現本地事務,也就是說在同一個資料庫中,可以保證事務的原子性,就是全部成功或者失敗,上篇文章也寫過簡單的多資料來源事務的解決方案(類似3PC) 但現在的系統往往採用
分散式事務之可靠訊息
什麼是可靠訊息? 為什麼我們需要它,為什麼我們要強調可靠? 生產方 訊息傳送出去了,如果生產方收到了訊息的正常反饋,那麼我們就可以知道訊息的確切的狀態。 如果訊息無響應 或者超時了呢? 有多個情況, 1 訊息未到達mq,傳送途中 就某些原因丟失了, 2 訊息送達mq,但是mq處理未完成就丟失(這裡又可
分散式事務之——基於訊息中介軟體實現
環境需求:假如某人有5個女朋友(有點複雜),每天晚上都會給他的女朋友打電話說晚安,那麼每給一個女朋友打電話,其他女朋友都要進入等待狀態。一個一個打下去。。。等打到最後一個已經是凌晨了,對方都睡了。那麼有什麼辦法可以解決呢?此時這個人可以利用微信公眾號將自己甜言蜜語放進公眾號
分散式事務之本地訊息表
什麼是分散式事務 分散式事務就是指事務的參與者、支援事務的伺服器、資源伺服器以及事務管理器分別位於不同的分散式系統的不同節點之上。簡單的說,就是一次大的操作由不同的小操作組成,這些小的操作分佈在不同的伺服器上,且屬於不同的應用,分散式事務需要保證這些小操作要麼全部成功,要麼全部失敗。本質上來說,分散式事務就
分散式事務之最終一致的Mq實現
問題的起源 分散式系統的特性 對分散式系統有過研究的讀者,可能聽說過“CAP定律”、“Base理論”等,非常巧的是,化學理論中ACID是酸、Base恰好是鹼。這裡我們不對這些概念做過多的解釋,有興趣的讀者可以檢視相關參考資料。 這裡針對一致性我
如何用訊息系統避免分散式事務? 如何用訊息系統避免分散式事務?
如何用訊息系統避免分散式事務? 前陣子從支付寶轉賬1萬塊錢到餘額寶,這是日常生活的一件普通小事,但作為網際網路研發人員的職業病,我就思考支付寶扣除1萬之後,如果系統掛掉怎麼辦,這時餘額寶賬戶並沒有增加1萬,資料就會出現不一致狀況了。 上述場景在各個型別的系統中都能找
分散式事務之——tcc-transaction分散式TCC型事務框架搭建與實戰案例【轉】
一、背景 有一定分散式開發經驗的朋友都知道,產品/專案/系統最初為了能夠快速迭代上線,往往不太注重產品/專案/系統的高可靠性、高效能與高擴充套件性,採用單體應用和單例項資料庫的架構方式快速迭代開發;當產品/專案/系統做到一定規模的時候,原有的系統架構則不足以支撐義務發展需要,往往相同的業務則需要
【轉】分散式事務之TCC服務設計和實現注意事項
1、TCC簡介 TCC是一種比較成熟的分散式事務解決方案,可用於解決跨庫操作的資料一致性問題; TCC是服務化的兩階段程式設計模型,其Try、Confirm、Cancel 3個方法均由業務編碼實現; 其中Try操作作為一階段,負責資源的檢查和預留,Confirm操作作為二階段提交操作,執行真正的業務,C
分散式事務(1)訊息傳送一致性解決方案
訊息傳送一致性 是指產生訊息的業務動作與訊息傳送的一致。(如果業務操作成功,那麼由這個業務操作所產生的訊息一定要成功投遞出去,否則就丟訊息) 訊息傳送一致性如何保障: 場景: 1.業務處理成功,執行傳送訊息的時候 應用故障,導致沒有傳送訊息(後續服務沒有收到訊息處理業務
分散式事務之——MySQL對XA事務的支援
MySQL 從5.0.3開始支援XA分散式事務,且只有InnoDB儲存引擎支援。MySQL Connector/J 從5.0.0版本之後開始直接提供對XA的支援。 需要注意的是, 在DTP模型中,mysql屬於資源管理器(RM)。而一個完整的分散式事務中,一般會存在多個RM
分散式事務之TCC
TCC本質上也是一種二階段協議,不同在於TCC需要與具體業務耦合,下面首先看下TCC步驟: 所有事務參與方都需要實現try,confirm,cancle介面。 事務發起方向事務協調器發起事務請求,事務協調器呼叫所有事務參與者的try方法完成資源的預留,這時候
跟我學分散式事務之2PC和3PC
分散式一致性回顧 在分散式系統中,為了保證資料的高可用,通常,我們會將資料保留多個副本(replica),這些副本會放置在不同的物理的機器上。為了對使用者提供正確的增\刪\改\差等語義,我們需要保證這些放置在不同物理機器上的副本是一致的。 為了解決這種分散式一致性問題
分散式事務之TCC與XA
TCC與XA/JTA對比 XA是資源層面的分散式事務,強一致性,在兩階段提交的整個過程中,一直會持有資源的鎖。基於資料庫鎖實現。 TCC是業務層面的分散式事務,最終一致性,不會一直持有資源的鎖。(第
Spring Cloud Alibaba | 微服務分散式事務之Seata
Spring Cloud Alibaba | 微服務分散式事務之Seata 本篇實戰所使用Spring有關版本: SpringBoot:2.1.7.RELEASE Spring Cloud:Greenwich.SR2 Spring CLoud Alibaba:2.1.0.RELEASE 1. 概述 在構建
微服務分散式事務之LCN、TCC
在[億級流量架構之分散式事務解決方案對比](https://www.cnblogs.com/Courage129/p/14443653.html)中, 已經簡單闡明瞭從本機事務到分散式事務的演變過程, 文章的最後簡單說明了TCC事務, 這兒將會深入瞭解TCC事務是原理, 以及理論支援, 最後會用Demo舉例實
分散式事務解決方案之訊息最終一致性(可靠訊息服務)下篇
背景:1.支付成功 通知訂單完成2.訂單完成,通知會計記賬上游訂單服務,必須開放可查詢訂單狀態介面,判斷訊息是否可以傳送下游會計消費成功後,必須回撥訊息服務,ACK操作(約束:冪等性。 例如:訊息id等)流程:訂單服務: 預儲存訊息 -> 訂單完成 ->
Rocket MQ 4.3.0分散式事務訊息初析
前言 從4.3.0版本開始支援事務訊息,這是一個令人振奮的訊息,線上目前4.2.0,在正式投產使用之前先進性簡單分析。幫助使用者實現類似 X/Open XA 的分佈事務功能,通過 MQ 事務訊息能達到分散式事務的最終一致。 基礎概念 事務訊息:MQ 提供類似 X/Open XA
使用kafka訊息佇列解決分散式事務(可靠訊息最終一致性方案-本地訊息服務)
微服務框架Spring Cloud介紹 Part1: 使用事件和訊息佇列實現分散式事務 本文轉自:http://skaka.me/blog/2016/04/21/springcloud1/ 不同於單一架構應用(Monolith), 分散式環境下, 進行事務操作將變得困難,
分散式事務解決方案(二)【基於可靠訊息的最終一致性】
2. 最終一致性(基於可靠訊息) 2.1 訊息傳送的一致性 指產生訊息的業務動作與訊息傳送的一致。(也就是說,如果業務操作成功,那麼由這個業務操作所產生的訊息一定要成功投遞出去,否則就丟訊息) 2.1.1 如何保障訊息傳送一致性 處理方式1