阿里雲消息中間件（MQ）探祕

摘要

阿里巴巴中間技術專家不銘從功能特性、技術架構、最佳實踐、案例分析四個方面進行了《Aliware-MQ消息隊列》的分享。

內容來源：2017年6月4日，阿里巴巴中間件技術部消息中間件技術專家周禮（不銘）在「企業互聯網架構優化升級之路」進行《阿里雲消息中間件（MQ）原理及實踐》演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2513 | 5分鐘閱讀

嘉賓演講視頻回放：t.cn/RHt7T9e

功能特性

Aliware-MQ是阿里雲提供的企業級互聯網架構的核心產品，基於高可用分佈式集羣技術，支持海量高併發和萬億級消息流轉，支持海量的消息堆積，支持高可靠/高可用方案，提供了運維、監控等一系列完整的配套服務。

如上圖所示，從消息的維度來看分爲普通消息、順序消息、定時消息和事務消息等四種消息,不管是發送哪一種消息客戶端都支持熔斷機制，即若是發現發送目標節點有性能問題，客戶端會自動進行熔斷，把有問題的節點排出去，保證消息發往可靠性最高的機器。管理方面已經支持消息的查詢、消息回溯、消息全鏈路軌跡和監控報警機制。性能上MQ已經達到了百億級的堆積能力，毫秒級的投遞延遲，支持萬級節點高併發，集羣水平熱擴縮。消息消費方面，支持失敗後的消息重投機制，失敗的消息會從新投遞到隊列中去，如今最多支持16次重投。

上圖是Aliware-MQ的功能架構。左邊是控制檯的管理，能夠在上面作發佈訂閱管理。右邊目前的接入方式是SDK支持TCP協議，同時也支持HTTP接口，以及面向手機終端的MQTT協議。

OpenAPI是MQ提供給用戶的管控方式，用於實現一系列資源管理和運維功能，用戶能夠經過Open API查詢所須要的任何東西。

上圖中是咱們今年推出的一個MQ移動物聯網套件。以前的客戶端，不論是上游仍是下游收發都是用各自的服務器。可是今年咱們有了移動物聯網套件，能夠直接面向終端設備。好比手機、汽車等移動設備利用移動物聯網套件，經過一個網關就能夠直接和消息系統打通。

技術架構

Aliware-MQ的消息系統是基於隊列。隊列要保證數據安全，是支持高併發和高性能讀寫的最基本元素。

如上圖所示，Producer是消息發送集羣，下游的Consumer是消費者集羣，都依賴於MQ的SDK。Broker是消息服務器，全部的消息都發送到Broker上面；Name Server和ZK功能相似，用來作服務發現。Producer要從Name Server獲取到Topic在哪一個節點上，訂閱Topic時須要知道Topic從哪裏取，一樣須要Name Server。Broker上的Topic信息會定時在Name Server上註冊，Producer和Consumer在交互以前會從Name Server上獲取目標。

圖中的master是主機，slave是備機，主備之間會作數據同步，有異步和同步兩種方式。一個master能夠布多個節點，這個根據本身的成原本決定。若是擴容的話，只要直接布一臺master便可，它會定時地將Topic註冊到Name Server上，發送方和訂閱方也會定時地感知這個過程，整個擴容的過程對於用戶來講大概30秒就能完成。

Aliware-MQ全部數據存儲在Commit Log裏，它在實現上就至關於一個文件夾，每次會生成一個1G的文件。無論哪一個Topic寫過來的消息都會直接寫入這個文件中，這個文件寫滿後再直接寫下一個。

針對每個Topic，要在業務層面對它進行區分，因此咱們作了一層索引。例如在上圖中有5個隊列，每一個隊列都會生成定長的索引文件，經過索引，能夠找到這條消息當前處於哪一個CommitLog文件的某個具體位置中。

這樣存儲結構，保證了不管多少個topic，CommitLog的寫是順序的，能較大的保證MQ的寫入性能。

Aliware-MQ的負載均衡是按照隊列維度來作的，消費的時候會把topic的隊列平均分配給消費實例。好比有2個消費實例，topic隊列是4個，那麼每一個消費實例就消費2個；而若是共有5個隊列，那麼就是是1個消費2個，另1個消費3個。一個隊列同一時間只會被一個消費實例消費，因此當出現隊列數量小於消費實例數量的狀況時，就會有消費實例出現空閒，這個時候能夠根據業務實際狀況手動經過工具將隊列數量調大。

消息寫進來都是先放在Java堆裏，而後再落盤。若是用戶要消費的消息都在內存裏，那麼就能夠很快的讀取到。可是若是用戶消息堆積比較久，消息已經不在內存裏而是存儲在了磁盤中，這個時候就須要去磁盤裏取數據，而後加載到內存裏面讀取出來。

Aliware-MQ的刷盤策略有異步和同步兩種。異步到內存就返回成功，同步寫則必定是消息刷到磁盤中才會返回成功。這種刷盤方式能夠根據業務的具體需求進行配置，從寫入的性能來看，異步寫的性能確定是會比同步的好。

最佳實踐

從發消息的角度來看，若是發送失敗，會有補償機制。MQ的客戶端會作三次重發，一臺機器發送失敗以後會默認往另外兩臺機器再嘗試，若是三次都失敗了纔會把最終的失敗結果傳回，這個時候用戶須要本身對發送異常進行相關處理。

有冪等要求的業務，Consumer在使用的時候須要本身作去重操做，在一些場景下，如客戶端本地等待超時等，是沒法保證消息徹底不重複的，所以用戶在進行系統設計時須要考慮到這一點。

案例分析

Aliware-MQ目前支持的消息最大是4M，消息越小，性能越高。定時消息是支持消息的定時投遞，能夠自行設置要投遞的時間，最長是40天。事務消息經過兩階段的提交的方式，來解決分佈式事務問題。順序消息能夠採用全局順序、分區順序，嚴格保證消息的順序。

Aliware-MQ的使用場景主要有系統間異步解耦、分佈式事務、異構數據複製與分發、雙十一大促的削峯填谷、大規模機器的Cache同步、日誌服務和IM實時通訊以及實時計算分析。

MQ順序消息分爲全局有序和隊列有序。全局有序是從指全部消息發出開始，下游的接收方都是按照順序接收；隊列有序則是將消息進行區塊分區，同一個分區內的消息按照先入先出的順序進行順序消費，保證一個隊列只會被一個進程消費。

當一個交易系統下單以後，會發一條消息到MQ，購物車接收消息把購物車裏的狀態清空。若是這時交易消息發送失敗，購物車就沒法清空，對於數據來講這就是一個髒數據。面對這種狀況咱們有事務消息能夠解決這個問題，在交易開始時先發送一條半事務消息，而後交易系統開始下單，全部事情作完以後再提交半事務，這時只有主動提交成功，消息隊列纔會將這條消息實際發送給用戶。若是交易下單過程失敗，則能夠主動回滾這條消息，購物車和交易系統之間能夠作到沒有髒數據。

雙十一大促時，各個分會場會有玲琅滿目的商品，每件商品的價格都會實時變化。使用緩存技術也沒法知足對商品價格的訪問需求，緩存服務器網卡跑滿。訪問較屢次商品價格查詢影響會場頁面的打開速度。因而MQ提供了一種廣播機制，原本一條消息只會被集羣的一臺機器消費。若是使用廣播模式，那麼這條消息會被集羣下的全部節點消費一次，至關於把價格信息同步到須要的每臺機器上，能夠取代緩存的做用。

實時計算功能主要是作一個消息總線，業務系統自動採集數據，把消息分發達下游的實時計算系統裏，根據實時計算結果來給業務方作服務。

我今天的分享就到這裏，謝謝你們！