訊息佇列實現分散式事務
前陣子從支付寶轉賬1萬塊錢到餘額寶，這是日常生活的一件普通小事，但作為網際網路研發人員的職業病，我就思考支付寶扣除1萬之後，如果系統掛掉怎麼辦，這時餘額寶賬戶並沒有增加1萬，資料就會出現不一致狀況了。
上述場景在各個型別的系統中都能找到相似影子，比如在電商系統中，當有使用者下單後，除了在訂單表插入一條記錄外，對應商品表的這個商品數量必須減1吧，怎麼保證？！在搜尋廣告系統中，當用戶點選某廣告後，除了在點選事件表中增加一條記錄外，還得去商家賬戶表中找到這個商家並扣除廣告費吧，怎麼保證？！等等，相信大家或多或多少都能碰到相似情景。
本質上問題可以抽象為：當一個表資料更新後，怎麼保證另一個表的資料也必須要更新成功。
1 本地事務
還是以支付寶轉賬餘額寶為例，假設有
- 支付寶賬戶表：A（id，userId，amount）
- 餘額寶賬戶表：B（id，userId，amount）
- 使用者的userId=1；
從支付寶轉賬1萬塊錢到餘額寶的動作分為兩步：
- 1）支付寶表扣除1萬：update A set amount=amount-10000 where userId=1;
- 2）餘額寶表增加1萬：update B set amount=amount+10000 where userId=1;
如何確保支付寶餘額寶收支平衡呢？
有人說這個很簡單嘛，可以用事務解決。
| 12345 | Begin transactionupdateAset |
非常正確，如果你使用spring的話一個註解就能搞定上述事務功能。
Java| 1 2 3 4 5 | @Transactional(rollbackFor=Exception.class) publicvoidupdate(){ updateATable();//更新A表 updateBTable();//更新B表 } |
如果系統規模較小，資料表都在一個數據庫例項上，上述本地事務方式可以很好地執行，但是如果系統規模較大，比如支付寶賬戶表和餘額寶賬戶表顯然不會在同一個資料庫例項上，他們往往分佈在不同的物理節點上，這時本地事務已經失去用武之地。
既然本地事務失效，分散式事務自然就登上舞臺。
2 分散式事務—兩階段提交協議
兩階段提交協議（Two-phase Commit，2PC）經常被用來實現分散式事務。一般分為協調器C和若干事務執行者Si兩種角色，這裡的事務執行者就是具體的資料庫，協調器可以和事務執行器在一臺機器上。
1） 我們的應用程式（client）發起一個開始請求到TC；
2） TC先將<prepare>訊息寫到本地日誌，之後向所有的Si發起<prepare>訊息。以支付寶轉賬到餘額寶為例，TC給A的prepare訊息是通知支付寶資料庫相應賬目扣款1萬，TC給B的prepare訊息是通知餘額寶資料庫相應賬目增加1w。為什麼在執行任務前需要先寫本地日誌，主要是為了故障後恢復用，本地日誌起到現實生活中憑證 的效果，如果沒有本地日誌（憑證），出問題容易死無對證；
3） Si收到<prepare>訊息後，執行具體本機事務，但不會進行commit，如果成功返回<yes>，不成功返回<no>。同理，返回前都應把要返回的訊息寫到日誌裡，當作憑證。
4） TC收集所有執行器返回的訊息，如果所有執行器都返回yes，那麼給所有執行器發生送commit訊息，執行器收到commit後執行本地事務的commit操作；如果有任一個執行器返回no，那麼給所有執行器傳送abort訊息，執行器收到abort訊息後執行事務abort操作。
注：TC或Si把傳送或接收到的訊息先寫到日誌裡，主要是為了故障後恢復用。如某一Si從故障中恢復後，先檢查本機的日誌，如果已收到<commit >，則提交，如果<abort >則回滾。如果是<yes>，則再向TC詢問一下，確定下一步。如果什麼都沒有，則很可能在<prepare>階段Si就崩潰了，因此需要回滾。
現如今實現基於兩階段提交的分散式事務也沒那麼困難了，如果使用java，那麼可以使用開源軟體atomikos(http://www.atomikos.com/)來快速實現。
不過但凡使用過的上述兩階段提交的同學都可以發現效能實在是太差，根本不適合高併發的系統。為什麼？
- 1）兩階段提交涉及多次節點間的網路通訊，通訊時間太長！
- 2）事務時間相對於變長了，鎖定的資源的時間也變長了，造成資源等待時間也增加好多！
正是由於分散式事務存在很嚴重的效能問題，大部分高併發服務都在避免使用，往往通過其他途徑來解決資料一致性問題。
3 使用訊息佇列來避免分散式事務
如果仔細觀察生活的話，生活的很多場景已經給了我們提示。
比如在北京很有名的姚記炒肝點了炒肝並付了錢後，他們並不會直接把你點的炒肝給你，而是給你一張小票，然後讓你拿著小票到出貨區排隊去取。為什麼他們要將付錢和取貨兩個動作分開呢？原因很多，其中一個很重要的原因是為了使他們接待能力增強（併發量更高）。
還是回到我們的問題，只要這張小票在，你最終是能拿到炒肝的。同理轉賬服務也是如此，當支付寶賬戶扣除1萬後，我們只要生成一個憑證（訊息）即可，這個憑證（訊息）上寫著“讓餘額寶賬戶增加 1萬”，只要這個憑證（訊息）能可靠儲存，我們最終是可以拿著這個憑證（訊息）讓餘額寶賬戶增加1萬的，即我們能依靠這個憑證（訊息）完成最終一致性。
3.1 如何可靠儲存憑證（訊息）
有兩種方法：
3.1.1 業務與訊息耦合的方式
支付寶在完成扣款的同時，同時記錄訊息資料，這個訊息資料與業務資料儲存在同一資料庫例項裡（訊息記錄表表名為message）。
| 12345 | Begin transactionupdateAset amount=amount-10000where userId=1;insert into message(userId,amount,status)values(1,10000,1);Endtransactioncommit; |
上述事務能保證只要支付寶賬戶裡被扣了錢，訊息一定能儲存下來。
當上述事務提交成功後，我們通過實時訊息服務將此訊息通知餘額寶，餘額寶處理成功後傳送回覆成功訊息，支付寶收到回覆後刪除該條訊息資料。
3.1.2 業務與訊息解耦方式
上述儲存訊息的方式使得訊息資料和業務資料緊耦合在一起，從架構上看不夠優雅，而且容易誘發其他問題。為了解耦，可以採用以下方式。
1）支付寶在扣款事務提交之前，向實時訊息服務請求傳送訊息，實時訊息服務只記錄訊息資料，而不真正傳送，只有訊息傳送成功後才會提交事務；
2）當支付寶扣款事務被提交成功後，向實時訊息服務確認傳送。只有在得到確認傳送指令後，實時訊息服務才真正傳送該訊息；
3）當支付寶扣款事務提交失敗回滾後，向實時訊息服務取消傳送。在得到取消傳送指令後，該訊息將不會被髮送；
4）對於那些未確認的訊息或者取消的訊息，需要有一個訊息狀態確認系統定時去支付寶系統查詢這個訊息的狀態並進行更新。為什麼需要這一步驟，舉個例子：假設在第2步支付寶扣款事務被成功提交後，系統掛了，此時訊息狀態並未被更新為“確認傳送”，從而導致訊息不能被髮送。
優點：訊息資料獨立儲存，降低業務系統與訊息系統間的耦合；
缺點：一次訊息傳送需要兩次請求；業務處理服務需要實現訊息狀態回查介面。
3.2 如何解決訊息重複投遞的問題
還有一個很嚴重的問題就是訊息重複投遞，以我們支付寶轉賬到餘額寶為例，如果相同的訊息被重複投遞兩次，那麼我們餘額寶賬戶將會增加2萬而不是1萬了。
為什麼相同的訊息會被重複投遞？比如餘額寶處理完訊息msg後，傳送了處理成功的訊息給支付寶，正常情況下支付寶應該要刪除訊息msg，但如果支付寶這時候悲劇的掛了，重啟後一看訊息msg還在，就會繼續傳送訊息msg。
解決方法很簡單，在餘額寶這邊增加訊息應用狀態表（message_apply），通俗來說就是個賬本，用於記錄訊息的消費情況，每次來一個訊息，在真正執行之前，先去訊息應用狀態表中查詢一遍，如果找到說明是重複訊息，丟棄即可，如果沒找到才執行，同時插入到訊息應用狀態表（同一事務）。
| 1 2 3 4 5 6 7 8 |
foreachmsg
inqueue
Begin
transaction
select
count(*)ascnt
from
message_apply
where
msg_id=msg.msg_id;
ifcnt==0then
updateBset
amount=amount+10000where
userId=1;
insert
into
message_apply(msg_id)values(msg.msg_id);
Endtransaction
commit
相關推薦[轉載]使用訊息佇列實現分散式事務-公認較為理想的分散式事務解決方案前陣子從支付寶轉賬1萬塊錢到餘額寶，這是日常生活的一件普通小事，但作為網際網路研發人員的職業病，我就思考支付寶扣除1萬之後，如果系統掛掉怎麼辦，這時餘額寶賬戶並沒有增加1萬，資料就會出現不一致狀況了。 上述場景在各個型別的系統中都能找到相似影子，比如在電商系統中，當有使用者下單後，除了在訂單表插 介紹下用訊息佇列實現分散式事務在OIE的時代， 上層應用開發人員總是認為資料庫足夠強大， 所以很多業務可以做的非常簡單。 比如A轉賬50元給B這個過程， 只要寫一個簡單sql語句塊就ok了。 開始事務； A賬戶減去50 B賬戶增加50 提交事務。 使用訊息佇列實現分散式事務-公認較為理想的分散式事務解決方案（三）Begin transaction update A set amount=amount-10000 where userId=1; update B set amount=amount+10000 where userId=1; End t 訊息佇列實現分散式事務前陣子從支付寶轉賬1萬塊錢到餘額寶，這是日常生活的一件普通小事，但作為網際網路研發人員的職業病，我就思考支付寶扣除1萬之後，如果系統掛掉怎麼辦，這時餘額寶賬戶並沒有增加1萬，資料就會出現不一致狀況了。 上述場景在各個型別的系統中都能找到相似影子，比如在電商系統中，當有使 Spring Boot中使用WebSocket總結（三）：使用訊息佇列實現分散式WebSocket在上一篇文章（www.zifangsky.cn/1359.html）中我介紹了服務端如何給指定使用者的客戶端傳送訊息，並如何處理對方不線上的情況。在這篇文章中我們繼續思考另外一個重要的問題，那就是：如果我們的專案是分散式環境，登入的使用者被Nginx的反向代理分配到多個不同伺服器，那麼在其中一個伺服器建立了W 使用kafka訊息佇列解決分散式事務(可靠訊息最終一致性方案-本地訊息服務)微服務框架Spring Cloud介紹 Part1: 使用事件和訊息佇列實現分散式事務 本文轉自：http://skaka.me/blog/2016/04/21/springcloud1/ 不同於單一架構應用(Monolith), 分散式環境下, 進行事務操作將變得困難, # 訊息佇列解決分散式事務訊息佇列解決分散式事務 本地訊息表：通常處於同一張資料表，通過事務觸發器就能實現，但無法解決兩張表處於不同的資料庫問題 begin transaction: update User set account = account - 100 where userId = 'A' i 【原創】老生常談——利用訊息佇列處理分散式事務引言 這篇說說分散式事務的問題。企業現在的架構都由傳統的架構轉向了微服務架構，如下圖所示: 那麼，都不可避免的會遇到跨資料庫呼叫的，分散式事務問題！ 目前，業內解決分散式事務問題，都基本不用JTA這種強一致性的解決方案，基本是採用如下兩套方案 基於TCC的事務框架 訊息佇列 藉助訊息佇列解決分散式事務先介紹一下RabbitMQ的基本概念 核心概念 Queue：真正儲存資料的地方 Exchange接受請求，轉存資料 Bind：收到請求後儲存到哪裡 訊息生產者：傳送資料的應用 訊息消費者：取出資料處理的應用 Bind的幾種分發規則：Direct、Topic、Fanout Fano 用訊息系統實現分散式事務從支付寶轉賬1萬塊錢到餘額寶，這是日常生活的一件普通小事，但作為網際網路研發人員的職業病，我就思考支付寶扣除1萬之後，如果系統掛掉怎麼辦，這時餘額寶賬戶並沒有增加1萬，資料就會出現不一致狀況了。 上述場景在各個型別的系統中都能找到相似影子，比如在電商系統中，當有使用者下單後，除 叢集與負載均衡系列(7)——訊息佇列之分散式事務XA協議： 為了解決分散式事務，各大廠家資料庫都提供了xa協議介面。什麼是XA協議，就是通過多階段提交，確保資料一致性。以兩階段提交為例 第一階段為準備階段， 使用訊息佇列規避分散式事務問題前陣子從支付寶轉賬10000元到餘額寶，這是日常生活的一件普通小事，但作為網際網路研發人員的職業病，我就思考支付寶扣除1萬之後，如果系統掛掉怎麼辦，這時餘額寶賬戶並沒有增加10000，資料就會出現不一致狀況了。這樣的場景在各個型別的系統中都能找到相似的影子，比如在電商系統中，當有使用者下單後，除了在訂單表插入 RocketMq在閹割訊息回查checkTransactionState後實現分散式事務利用rocketMQ解決分散式事務 在rocketMQ中生產者有三種角色 NormalProducer（普通）、OrderProducer（順序）、TransactionProducer（事務） 根據名字大概可以看出各個代表著什麼作用，我們這裡用 Trans 分散式延遲訊息佇列實現分析與設計介紹 延遲佇列，顧名思義它是一種帶有延遲功能的訊息佇列。 那麼，是在什麼場景下我才需要這樣的佇列呢？ 很多時候我們會有延時處理一個任務的需求，比如說： 2個小時後給使用者傳送簡訊。 15分鐘後關閉網路連線。 2分鐘後再次嘗試回撥。 下面我們來分別探討一下幾種實現方案： Ja Netty構建分散式訊息佇列實現原理淺析（十六）在本人的上一篇部落格文章：Netty構建分散式訊息佇列（AvatarMQ）設計指南之架構篇 中，重點向大家介紹了AvatarMQ主要構成模組以及目前存在的優缺點。最後以一個生產者、消費者傳遞訊息的例子，具體演示了AvatarMQ所具備的基本訊息路由功能。而本文的寫作 如何用訊息系統避免分散式事務？ 如何用訊息系統避免分散式事務？如何用訊息系統避免分散式事務？ 前陣子從支付寶轉賬1萬塊錢到餘額寶，這是日常生活的一件普通小事，但作為網際網路研發人員的職業病，我就思考支付寶扣除1萬之後，如果系統掛掉怎麼辦，這時餘額寶賬戶並沒有增加1萬，資料就會出現不一致狀況了。 上述場景在各個型別的系統中都能找 System V訊息佇列實現的檔案伺服器（不跨網路）可能是定時的部分有問題吧，導致客戶端無法接收資料，不過我感覺思想是沒錯的。。。先pull上吧，以後發現錯誤再改 參考資料：UNP卷二 message.h #ifndef _MESSAGE_H #define _MESSAGE_H #include<stdio.h> #i 關於利用MQ實現分散式事務的想法【轉】轉自：https://www.jianshu.com/p/bafb09954f18 假設：訊息服務不丟訊息 場景 服務A 服務B 服務C 訊息服務Q 虛擬碼 服務A中 transaction{ A本地事務 B.callB(); C.callC(); A本地事務 利用訊息佇列實現簡單聊天程式本篇利用訊息佇列的特性實現簡單的聊天程式，msgsnd傳送資料，msgrcv接收資料來實現聊天功能，訊息佇列詳情。 資料接收端msgrcv //這是一個以system V訊息佇列實現的聊天程式客戶端 //// 1.建立訊息佇列 //// 2.從訊息佇列中獲取一個數據，打印出來 /// PHP訊息佇列實現及應用：訊息佇列概念介紹在網際網路專案開發者經常會遇到『給使用者群發簡訊』、『訂單系統有大量的日誌需要記錄』或者在秒殺業務的時候伺服器無法承受瞬間併發的壓力。 這種情況下，我們怎麼保證系統正常有效的執行呢？ 這個時候，我們可以引入一個叫『訊息佇列』的概念來解決上面的需求。 訊息佇列的概 |