分佈式消息中間件 — MQ

消息隊列（Message Queue，簡稱 MQ）是阿里巴巴集團中間件技術部自主研發的專業消息中間件。用於保證異構應用之間的消息傳遞。應用程序經過MQ接口進行互連通訊，能夠沒必要關心網絡上的通訊細節，從而將更多的注意力集中於應用自己。

分佈式消息系統做爲實現分佈式系統可擴展、可伸縮性的關鍵組件，須要具備高吞吐量、高可用等特色。

對象

•消息 (Message)
•隊列 (Queue)
•隊列管理器(QueueManager)
•通道 (Channel)
•監聽器(Listener)

關係：隊列管理器是負責嚮應用程序提供消息服務的機構，咱們能夠把隊列管理器比做是數據庫，隊列是其中的一張表，消息表中的一條記錄。

一、消息(Message)

消息是 WebSphereMQ中最小的概念，本質上就是一條數據，它能被一個或多個應用程序所理解，是應用程序之間傳遞的信息載體。

消息能夠大體分紅兩部分：應用數據體和消息數據頭。消息數據頭是對消息屬性的描述，這段信息每每被隊列管理器用來肯定對消息的處理。消息數據頭能夠由應用程序或系統的消息服務程序共同產生，它包含了消息在傳送中的必要信息，如目標隊列管理器的名字，目標隊列的名字，以及消息的其它一些屬性。

消息能夠分紅持久(Persistent)消息和非持久 (Non-Persistent)消息。所謂「持久」的意思，就是在 WebSphere MQ 隊列管理器重啓動後，消息是否仍然能保持。

二、隊列 (Queue)：分本地隊列、遠程隊列、模型隊列

本地隊列按功能可分紅初始化隊列，傳輸隊列，目標隊列和死信隊列。

–初始化隊列用作消息觸發功能。
–傳輸隊列只是暫存待傳的消息，條件許可的狀況下，經過管道將消息傳送其它的隊列管理器。
–目標隊列是消息的目的地，能夠長期存放消息。
–若是消息不能送達目標隊列，也不能再路由出去，則被自動放入死信隊列保存。

遠程隊列
–用來指定遠端隊列管理器中的隊列。使用了遠程隊列定義，程序就不須要知道目標隊列的位置。

模型隊列
-定義了一套本地隊列的屬性集合，一旦打開模型隊列，隊列管理器會按這些屬性動態地建立出一個本地隊列。

三、隊列管理器(QueueManager)

WebSphere MQ中的隊列管理器能夠含有不少個隊列，但一個隊列只能屬於一個隊列管理器。一個操做系統平臺能夠建立一個隊列管理器，也能夠建立多個隊列管理器。隊列管理器、隊列、通道等等都是WebSphere MQ的對象，全部的對象都有各自的屬性，有些屬性必須在對象建立的時候指定，有些能夠在建立之後更改。

四、通道 (Channel)

通道是兩個隊列管理器之間的一種單向的點對點的通訊鏈接，消息在通道中只能單向流動。若是須要雙向交流，能夠創建一對通道，一來一去。站在隊列管理器的角度，這一對通道能夠按消息的流向分紅輸入通道和輸出通道。經過配置，對於放入本地傳輸隊列中的消息，隊列管理器會自動將其經過輸出通道發出，送入對方的遠程目標隊列。

五、監聽器(Listener)

同步接收消息：同步讀取即主動讀取方式

異步接收消息異步讀取則須要設定Listener，在消息到達後，自動調用Listener的onMessage()方法。

JMS開發

jms即Java消息服務（JavaMessage Service）應用程序接口，是一個Java平臺中關於面向消息中間件（MOM）的API，用於在兩個應用程序之間，或分佈式系統中發送消息，進行異步通訊。

•JMS 中有一系列的類：ConnectionFactory，Connection，Session，MessageProducer，MessageConsumer，Message

•在 JMS 編程時，程序首先要找出ConnectionFactory，以此建立Connection，再創建Session，之後全部的操做都以Session 爲基礎。找出Queue 或Queue (統稱Destination)，以此建立QueueSender或QueuePublisher (統稱MessageProducer)，在該對象上發送或發佈消息。也能夠在Destination 基礎上建立QueueReceiver 或 QueueSubscriber (統稱MessageConsumer)，在該對象上接收或訂閱消息。

如何用消息系統避免分佈式事務

前陣子從支付寶轉帳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;

如何確保支付寶餘額寶收支平衡呢？

有人說這個很簡單嘛，能夠用事務解決。

很是正確，若是你使用spring的話一個註解就能搞定上述事務功能。

若是系統規模較小，數據表都在一個數據庫實例上，上述本地事務方式能夠很好地運行，可是若是系統規模較大，好比支付寶帳戶表和餘額寶帳戶表顯然不會在同一個數據庫實例上，他們每每分佈在不一樣的物理節點上，這時本地事務已經失去用武之地。
既然本地事務失效，分佈式事務天然就登上舞臺。

分佈式事務—兩階段提交協議

兩階段提交協議（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）事務時間相對於變長了，鎖定的資源的時間也變長了，形成資源等待時間也增長好多！
正是因爲分佈式事務存在很嚴重的性能問題，大部分高併發服務都在避免使用，每每經過其餘途徑來解決數據一致性問題。

使用消息隊列來避免分佈式事務

若是仔細觀察生活的話，生活的不少場景已經給了咱們提示。

好比在北京頗有名的姚記炒肝點了炒肝並付了錢後，他們並不會直接把你點的炒肝給你，而是給你一張小票，而後讓你拿着小票到出貨區排隊去取。爲何他們要將付錢和取貨兩個動做分開呢？緣由不少，其中一個很重要的緣由是爲了使他們接待能力加強（併發量更高）。

仍是回到咱們的問題，只要這張小票在，你最終是能拿到炒肝的。同理轉帳服務也是如此，當支付寶帳戶扣除1萬後，咱們只要生成一個憑證（消息）便可，這個憑證（消息）上寫着「讓餘額寶帳戶增長 1萬」，只要這個憑證（消息）能可靠保存，咱們最終是能夠拿着這個憑證（消息）讓餘額寶帳戶增長1萬的，即咱們能依靠這個憑證（消息）完成最終一致性。

如何可靠保存憑證（消息）

有兩種方法：

業務與消息耦合的方式

支付寶在完成扣款的同時，同時記錄消息數據，這個消息數據與業務數據保存在同一數據庫實例裏（消息記錄表表名爲message）。

上述事務能保證只要支付寶帳戶裏被扣了錢，消息必定能保存下來。
當上述事務提交成功後，咱們經過實時消息服務將此消息通知餘額寶，餘額寶處理成功後發送回覆成功消息，支付寶收到回覆後刪除該條消息數據。

業務與消息解耦方式

上述保存消息的方式使得消息數據和業務數據緊耦合在一塊兒，從架構上看不夠優雅，並且容易誘發其餘問題。爲了解耦，能夠採用如下方式。

1）支付寶在扣款事務提交以前，向實時消息服務請求發送消息，實時消息服務只記錄消息數據，而不真正發送，只有消息發送成功後纔會提交事務；

2）當支付寶扣款事務被提交成功後，向實時消息服務確認發送。只有在獲得確認發送指令後，實時消息服務才真正發送該消息；

3）當支付寶扣款事務提交失敗回滾後，向實時消息服務取消發送。在獲得取消發送指令後，該消息將不會被髮送；

4）對於那些未確認的消息或者取消的消息，須要有一個消息狀態確認系統定時去支付寶系統查詢這個消息的狀態並進行更新。爲何須要這一步驟，舉個例子：假設在第2步支付寶扣款事務被成功提交後，系統掛了，此時消息狀態並未被更新爲「確認發送」，從而致使消息不能被髮送。

優勢：消息數據獨立存儲，下降業務系統與消息系統間的耦合；

缺點：一次消息發送須要兩次請求；業務處理服務須要實現消息狀態回查接口。

如何解決消息重複投遞的問題

還有一個很嚴重的問題就是消息重複投遞，以咱們支付寶轉帳到餘額寶爲例，若是相同的消息被重複投遞兩次，那麼咱們餘額寶帳戶將會增長2萬而不是1萬了。

爲何相同的消息會被重複投遞？好比餘額寶處理完消息msg後，發送了處理成功的消息給支付寶，正常狀況下支付寶應該要刪除消息msg，但若是支付寶這時候悲劇的掛了，重啓後一看消息msg還在，就會繼續發送消息msg。

解決方法很簡單，在餘額寶這邊增長消息應用狀態表（message_apply），通俗來講就是個帳本，用於記錄消息的消費狀況，每次來一個消息，在真正執行以前，先去消息應用狀態表中查詢一遍，若是找到說明是重複消息，丟棄便可，若是沒找到才執行，同時插入到消息應用狀態表（同一事務）。

在此我向你們推薦一個架構學習交流羣。交流學習羣號：478030634 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

基於事務消息的MQ方案是目前公認的較爲理想的分佈式事務解決方案，各大電商都在應用這一方案。種方式適合的業務場景普遍，並且比較可靠。不過這種方式技術實現的難度比較大。目前主流的開源MQ（ActiveMQ、RabbitMQ、Kafka）均未實現對事務消息的支持，因此需二次開發或者新造輪子。