793
Aliware-MQ消息隊列技術架構與最佳實踐
在阿裏雲生態日，阿裏巴巴中間件產品專家不銘分享了《Aliware-MQ消息隊列》。他從功能特性、技術架構、最佳實踐、案例分析四個方麵進行了分享。在分享中，他主要介紹了Aliware-MQ的線性擴展技術、存儲模型、負載均衡、數據流、刷盤策略、高可靠/高可用方案進行了介紹，並通過案例進行了具體實踐分享。
以下內容根據直播視頻整理而成。
功能特性
Aliware-MQ是什麼？它是企業級互聯網架構的核心產品，基於高可用分布式集群技術，支持海量高並發，支持萬億級消息流轉（雙十一的萬億數據），支持海量的消息堆積，支持高可靠/高可用方案，提供運維、監控等一套完整的配套服務。
Aliware-MQ的功能特性如上圖所示。它支持四種消息：普通消息、順序消息、定時消息、事務消息。管理方麵支持消息查詢、消息回溯、全鏈路軌跡（消息發出到接收經過的鏈路）、監控報警機製。熔斷機製是指把有問題的節點自動熔斷，發送到可靠性最高的機器上。消息重投機製是指發送失敗後重新投遞消息，最多支持十六次的重投。
Aliware-MQ的功能架構圖如上圖所示。左邊是控製台的管理，右邊的接入方式支持TCP協議、HTTP協議和MQTT協議（麵向手機終端的協議）。服務端包括了消息發送和訂閱。
Open API是MQ提供給用戶的管控方式，用於實現一係列資源管理和運維功能。把控製台功能包裝成API對外提供，用戶可以通過Open API查詢所需要的任何東西，主要用來做運維管控。
上圖是今年推出的Aliware-MQ移動物聯網套件。之前的客戶端，不管上遊、下遊發或收都不麵向用戶端，而是麵向服務器。而移動互聯網套件可以直接麵向手機、汽車等移動設備，可以直接通過網關把消息係統打通。
技術架構
消息係統是基於隊列的。隊列要保證數據安全，要支持高並發、高性能讀寫，要足夠大，要支持足夠多數量。
上圖中Producer是消息發送集群，下遊是Consumer消費者集群，Broker是服務器，所有的消息都發送到服務器上，Name Server集群和VK功能類似，用來做服務發現。消息發送需要從Name Server獲取到，訂閱Topic時需要知道消息從哪裏取同樣需要Name Server。Broker上的Topic信息會定時向Name Server注冊，Producer和Consumer在交互之前會從Name Server上獲取目標。其中，master是主機，slave是備機，主備之間會做數據同步（異步和同步兩種方式），一個master可以布多個節點。如果擴容的話，直接布一台master即可，它會自動將Topic注冊到Name Server上。
Aliware-MQ所有數據存儲在Commit Log裏，實現上就相當於一個文件夾，每次會生成一個1G的文件，不管哪個Topic寫消息都會直接存入這個文件中，直到存滿。做索引的目的是為了區分每個Topic。上圖中有5個隊列，每個隊列會生成定長的文件，會告訴我們這個Topic在哪個文件中。
Aliware-MQ的負載均衡比較簡單。如果有5個隊列，在消息量比較大的時候會平均分配到這5個隊列中。消費負載均衡策略也比較簡單，如果有兩個訂閱者，而總共有5個隊列，那麼其中一個消費兩個，另一個消費三個。當隊列數量小於訂閱者數量時，需要根據業務實際情況手動將隊列數量調大。
消息寫進來先放在Java堆裏，然後再到內存。對於用戶，如果消息都在內存裏，那麼直接讀走。但是有一種可能，消息堆積比較久，已經存儲在了磁盤中，此時就需要從磁盤裏加載數據，然後從內存中讀取出來。如果一台機器上的用戶量比較大，都在讀取磁盤，磁盤IO占用比較高（可能達到100%），所以針對堆積比較多的業務需要單獨劃出來保證業務上不互相影響。
Aliware-MQ的刷盤策略包括兩個：異步寫，沒有刷盤就返回成功；同步寫，一定是消息刷到磁盤中才會返回成功。
Aliware-MQ的高可靠方案如上圖所示。主備機有兩種方案：一是備機不切，如果主機掛掉了，備機上有主機掛掉之前的全部數據，所有在主機上還未消費的事情都可以在備機上來讀，備機不會切換成主機，隻對外提供讀的方案；二是備機可切，當主機掛掉之後，備機會切換為主機同時對外提供讀和寫的功能。主備同步的方案也有兩種：一是同步；二是異步地同步，在主機宕機後可能出現一定的消息丟失。
最佳實踐
對於Producer，有消息的失敗補償機製，一台機器發送失敗之後會默認往另外兩台機器再嚐試，如果三次都失敗了才會把最終的失敗結果傳回；可追蹤機製，通過trace功能把整條鏈路追蹤出來；One-way發送，沒有返回接口，發出來是不可靠的，發出來就算成功。對於Consumer，需要做冪等性，沒辦法保證消息完全不重複，所以將其交給用戶來做；做批量處理和並發性。
案例分析
Aliware-MQ的普通消息最大4M，消息越小，性能越高；定時消息可以實現消息的延時或者定時投遞，最長40天；事務消息可以兩階段提交、解決分布式事務問題；順序消息可以采用全局順序、分區順序，嚴格保證消息的順序。
Aliware-MQ的使用場景包括：係統間異步解耦、分布式事務、異構數據複製與分發、雙十一大促的削峰填穀、大規模機器的Cache同步、日誌服務、IM實時通信、實時計算分析。
削峰填穀
雙十一時有一個案例：內部有一個係統TP是做交易的，每一次下單都會在TP裏麵創建一筆訂單，創建好訂單後會調用物流LC接口，物流訂單創建成功後又會調用交易接口。此過程中，交易TP和菜鳥LC是耦合的，但是從業務角度來看，實際上物流訂單的創建是可以有一定延遲的。所以消息係統需要解耦，訂單創建完成之後發一條消息到MQ，LC根據自己的業務需求去MQ來拉消息，這樣就可以用少量的機器完成任務。
MQ順序消息
MQ順序消息分為兩種情況：全局順序，對於指定的一個Topic，所有消息將按照嚴格的先入先出的順序，進行順發布和順序消費；分區順序，對於指定的一個Topic，所有消息根據shardingkey進行區塊分區，同一個分區內的消息將按照嚴格的先入先出的順序，進行順發布和順序消費，可以保證一個消息被一個進程消費。
其中一個應用是，雙十一要做買賣家的消息同步，即把買家數據同步到賣家庫，具體來說根據seller_id做hash寫到MQ的不同隊列裏麵去，消費方來拉取每一個seller_id的消息，找到自己對應的賣家庫進行同步。
分布式事務
一個交易係統下單之後，會發一條消息到MQ裏麵，購物車會接收消息把購物車裏的狀態清空。如果此時消息發送失敗，購物車就沒法清空。麵對這種情況，開始時先發送一條半事務消息，交易係統開始下單，所有事情做完之後再將半事務提交，隻有主動提交成功消息隊列才會將這條消息實際發送給用戶。如果下單過程失敗可以主動回滾這條消息，購物車和消息隊列可以做到沒有髒數據。
大規模機器的Cache同步
雙十一大促時，各個分會場會有玲琅滿目的商品，每件商品的價格都會實時變化。使用緩存技術也無法滿足對商品價格的訪問需求，緩存服務器網卡跑滿。訪問較多次商品價格查詢影響會場頁麵的打開速度。此時需要提供一種廣播機製，一條消息本來隻可以被集群的一台機器消費，如果使用廣播模式，那麼這條消息會被所有節點消費一次，相當於把價格信息同步到需要的每台機器上，取代緩存的作用。
實時計算
主要是做一個消息總線，業務係統自動采集數據，把消息分發達下遊的實時計算係統中，根據實時計算結果給業務方做服務。
MQ應用案例
上圖是管易用戶通過MQ來做訂單的流轉、商品庫存、實時監控的案例。
最後更新：2017-06-17 13:33:31