在阿裡雲生态日，阿裡巴巴中間件産品專家不銘分享了《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順序消息分為兩種情況：全局順序，對于指定的一個topic，所有消息将按照嚴格的先入先出的順序，進行順釋出和順序消費；分區順序，對于指定的一個topic，所有消息根據shardingkey進行區塊分區，同一個分區内的消息将按照嚴格的先入先出的順序，進行順釋出和順序消費，可以保證一個消息被一個程序消費。
其中一個應用是，雙十一要做買賣家的消息同步，即把買家資料同步到賣家庫，具體來說根據seller_id做hash寫到mq的不同隊列裡面去，消費方來拉取每一個seller_id的消息，找到自己對應的賣家庫進行同步。
一個交易系統下單之後，會發一條消息到mq裡面，購物車會接收消息把購物車裡的狀态清空。如果此時消息發送失敗，購物車就沒法清空。面對這種情況，開始時先發送一條半事務消息，交易系統開始下單，所有事情做完之後再将半事務送出，隻有主動送出成功消息隊列才會将這條消息實際發送給使用者。如果下單過程失敗可以主動復原這條消息，購物車和消息隊列可以做到沒有髒資料。
雙十一大促時，各個分會場會有玲琅滿目的商品，每件商品的價格都會實時變化。使用緩存技術也無法滿足對商品價格的通路需求，緩存伺服器網卡跑滿。通路較多次商品價格查詢影響會場頁面的打開速度。此時需要提供一種廣播機制，一條消息本來隻可以被叢集的一台機器消費，如果使用廣播模式，那麼這條消息會被所有節點消費一次，相當于把價格資訊同步到需要的每台機器上，取代緩存的作用。
主要是做一個消息總線，業務系統自動采集資料，把消息分發達下遊的實時計算系統中，根據實時計算結果給業務方做服務。
上圖是管易使用者通過mq來做訂單的流轉、商品庫存、實時監控的案例。
車聯網的平台利用mqtt把車輛上的所有資訊搜集起來通過内置在車輛上的子產品發送到mq的服務端，服務端可以給下遊做推送訂閱服務，也可以進行實時的資料分析處理。