MQ是消息服務(wù)中間件，基于高可用分布式集群技術(shù)，是消費模式基于發(fā)布訂閱模式的消息系統(tǒng)。支持Java，C++以及.NET，PHP，Python，為分布式應(yīng)用系統(tǒng)提供異步解耦、削峰填谷的能力，具備海量消息堆積、高吞吐、可靠重試等特性。具有消息查詢，消息回溯(不是消息撤回，也不支持消息撤回)，消息軌跡查詢，堆積監(jiān)控報警功能。
MQ協(xié)議支持接入方式 : TCP、HTTP(RESTful 風(fēng)格)、MQTT。MQ支持公網(wǎng)訪問，但可用性較低。
MQ應(yīng)用場景 : 分布式事務(wù)，物聯(lián)網(wǎng)應(yīng)用，實時計算(將產(chǎn)生的數(shù)據(jù)實時流入到實時計算引擎來實現(xiàn))，同步大規(guī)模緩存。
實時計算引擎一般有 : Spark / Storm / EMR / ARMS / BeamRunner。
MQ擁有管理工具 : Web控制臺，Open API，mqadmin命令集。擁有微消息隊列(LMQ)，RocketMQ消息隊列，Kafka消息隊列，跨域中繼服務(wù)(CRS)等組件。
Web控制臺提供消息查詢、消息軌跡查詢、重置消費位點、資源統(tǒng)計、監(jiān)控報警等操作。消息查詢有三種方式 :** 根據(jù)Message ID(精確查詢)，Message Key(模糊查詢)以及Topic查詢(范圍查詢)，HTTP消息目前只支持Message ID和Topic兩種查詢方式。**
消息軌跡查詢只支持TCP和HTTP協(xié)議，可追蹤消息從生產(chǎn)者發(fā)出到消費者消費的整個鏈路中各個相關(guān)節(jié)點的時間地點。
重置消費位點可跳過堆積的消息，即不想消費這部分消息，或者只想消費某個時間點后的消息（這些消息不論之前是否消費過）。
資源報表可對消息發(fā)送和消息消費的數(shù)據(jù)進行統(tǒng)計，暫不支持HTTP消費數(shù)據(jù)的統(tǒng)計查詢。
監(jiān)控報警一般用在消息堆積數(shù)或者延遲時間超過閾值之后，對報警接收人發(fā)送短信，如果發(fā)現(xiàn)消息堆積很多，可檢查閾值是否設(shè)置過小導(dǎo)致消息堆積，可調(diào)整業(yè)務(wù)代碼或者對消費者進行擴容，可使用jstack查看是否消費線程阻塞。
微消息隊列(LMQ)基于MQTT(Message Queuing Telemetry Transport 消息隊列遙測傳輸)協(xié)議，標準協(xié)議端口為1883，支持加密SSL，WebSocket，F(xiàn)lash接入方式。協(xié)議重要部分主要分為 : MQ Core Service(負責(zé)底層的消息存儲和分發(fā))，MQ私有協(xié)議服務(wù)器以及MQTT協(xié)議網(wǎng)關(guān)服務(wù)器(負責(zé)對客戶端提供服務(wù)和協(xié)議轉(zhuǎn)換)。主要使用場景有 : 直播互動、車聯(lián)網(wǎng)、金融支付、即時聊天等。協(xié)議相關(guān) : QoS(Quality of Service)指代消息傳輸?shù)姆?wù)質(zhì)量。它包括QoS0(最多分發(fā)一次)、QoS1(至少達到一次)和QoS2(僅分發(fā)一次)三種級別。cleanSession標識客戶端建立TCP連接后是否關(guān)心之前狀態(tài)(true or false)。
MQTT可進行實例管理(查看消息收發(fā)TPS、同時在線連接數(shù)、訂閱關(guān)系數(shù)等信息，可設(shè)置實例報警)，可申請MQTT Topic，可為Topic申請MQTT Group ID(一組邏輯功能完全一致的節(jié)點共用的組名，代表一類相同功能的設(shè)備，必須擁有Topic的讀寫權(quán)限)?？蛇M行簽名計算和簽名生成。
MQTT可獲取離線消息，可主動拉取離線消息，客戶端每次拉取消息數(shù)量最多為30條，拉取請求的最大頻率限制為5次/秒。離線消息優(yōu)先級低，對其進行有限和最終能處理即可，要求比較實時。
MQTT可獲取客戶端上下線事件(上下線事件觸發(fā)時，會向后端MQ推送一條上下線消息，通過訂閱這條消息獲取)，上下線事件類型一般放在MQ的Tag中，有三種狀態(tài) : connect(客戶端上線)，disconnect(客戶端主動斷開連接)，tcpclean(實際的TCP連接斷開)。tcpclean代表客戶端網(wǎng)絡(luò)層連接的真實斷開，判斷客戶端下線請使用tcpclean事件。
MQTT通過Token鑒權(quán)服務(wù)向客戶端提供訪問權(quán)限?？蛻舳诵枰捎肕QTT控制報文以同步發(fā)送模式并且QoS必須為1，來上傳Token。客戶端應(yīng)該對Token做好持久化，監(jiān)聽Proxy下推的Token失效的通知消息，Token失效必須重新申請。
LMQ的Topic，ClientId長度最大為64個字符，消息大小最大為64K，消息保存時間最長為3天，單個客戶端訂閱Topic數(shù)量最大為30個(超過該限制數(shù)量的Topic會被丟棄)，消息順序性為上行順序。
跨域中繼服務(wù)(CRS，跨域哦，實現(xiàn)服務(wù)發(fā)布與訂閱，實現(xiàn)不同網(wǎng)絡(luò)的服務(wù)互通)提供三種MQ消息發(fā)送方式 :可靠同步發(fā)送(發(fā)出消息響應(yīng)后才能發(fā)下一個消息，應(yīng)用場景廣，如重要通知郵件、報名短信通知、營銷短信系統(tǒng))，可靠異步發(fā)送(不需要等待響應(yīng)即可發(fā)下一個消息，應(yīng)用場景一般是耗時長，對RT響應(yīng)敏感的業(yè)務(wù)，如視頻上傳后通知轉(zhuǎn)碼服務(wù)，轉(zhuǎn)碼后通知推送轉(zhuǎn)碼結(jié)果)，One Way(單向發(fā)送，不需要響應(yīng)的方式，耗時超短，對可靠性要求不高的場景使用，如日志收集)。
MQ消息系統(tǒng)中，資源分為消息(Message)，消息生產(chǎn)者(Producer)，消息消費者(Consumer)，消息主題(Topic)。Producer ID(生產(chǎn)者ID)，Consumer ID(消費者ID)，Topic名稱，都必須全局唯一。
MQ消息是消息隊列中信息傳遞的載體，按類型分一般有四種 : 無序消息(普通消息，定時消息，事務(wù)消息)，全局順序消息，分區(qū)順序消息，Kafka消息。MQ在網(wǎng)絡(luò)抖動、應(yīng)用處理超時等異常情況下，無法保證消息不重復(fù)，但是能保證消息不丟失。MQ消息在服務(wù)器保存最長時間為3天，消息Body長度限制為256K，華北2地域支持4MB大消息。
MQ消息主題是消息的一級歸類，消息發(fā)布者將消息發(fā)送到某個消息主題（Topic），而消息訂閱者訂閱該Topic來獲取和消費消息(第一次訂閱新的Topic有延遲，之后不會)，一個Topic只能對應(yīng)一個Producer ID(一個Topic只屬于一個生產(chǎn)者，但一個生產(chǎn)者可以有多個Topic，關(guān)系為N:1)，一個Topic可以對應(yīng)多個Consumer ID(一個Topic可屬于多個消費者，一個消費者可以訂閱多個Topic，關(guān)系為N:N)。Topic不能跨域使用。即Producer ID和Topic必須在同一個域內(nèi)，Consumer ID和Topic必須在同一個域內(nèi)。
RocketMQ常見使用方式 : 訂閱關(guān)系一致，集群消費和廣播消費，消息過濾，消息重試，消費冪等。
訂閱關(guān)系由Topic+Tag組成，這兩者必須一致即為訂閱關(guān)系一致。
集群是相同Consumer ID的訂閱者(實例)屬于同一個集群，同一個集群下的訂閱者消費邏輯必須完全一致，訂閱者在邏輯上可以認為是一個消費節(jié)點。
集群消費模式：MQ認為任意一條消息只需要被集群內(nèi)的任意一個消費者處理即可。
例如某個 Topic 有 9 條消息，一個 Consumer ID 有 3 個 Consumer 實例，那么在集群消費模式下每個實例平均分攤，只消費其中的 3 條消息。
廣播消費模式：MQ將每條消息推送給集群內(nèi)所有注冊過的客戶端，保證消息至少被每臺機器消費一次。但消費失敗后不做重試操作。
例如某個 Topic 有 9 條消息，一個 Consumer ID 有 3 個 Consumer 實例，那么在廣播消費模式下每個實例都會各自消費 9 條消息
消費細節(jié) : 啟動Consumer(消費者)時，可通過ConsumeThreadNums屬性來設(shè)置消費線程數(shù)。如果Consumer ID(消費者)是第一次啟動，會忽略啟動之前發(fā)送的消息(忽略歷史消息)，從啟動之后發(fā)送的消息開始消費，如果是第二次啟動，那么從上次消費的位置開始消費。如果想從特定位置開始消費，請使用重置消費位點功能(只針對Consumer ID下的特定Topic，不影響其他Consumer ID)。
消息重試 : 只針對集群消費方式生效，廣播方式不提供失敗重試特性。默認允許每條消息最多重試16次(可自定義)重試16次后，仍然失敗，則消息丟棄。一條消息無論重試多少次，這些重試消息的Message ID不會改變。
重試方式為有三種 : 1 . 返回Action.ReconsumeLater（推薦）；2 . 返回 Null ；3 . 拋出異常。
消費冪等 : 分為發(fā)送時消息重復(fù)(Message ID不同，發(fā)送到服務(wù)端時由于網(wǎng)絡(luò)閃斷或者客戶端宕機導(dǎo)致服務(wù)端應(yīng)答給客戶端失敗，生產(chǎn)者意識到發(fā)送失敗再次發(fā)送)，投遞時消息重復(fù)(Message ID相同，消息已經(jīng)投遞到消費者，客戶端給服務(wù)端應(yīng)答時網(wǎng)絡(luò)閃斷，為保證消息被消費一次，服務(wù)端再次投遞之前被處理的消息)。
消費者按照Tag對消息進行過濾，確保消費者最終只消費到他關(guān)心的消息類型。
RocketMQ特色消息類型 : 定時消息和延時消息，順序消息，事務(wù)消息。幾種消息是不同的消息類型，是互斥關(guān)系，不能疊加在一起使用(即消息不能是既是順序消息，又支持定時和事務(wù)消息)。
定時消息 : 推遲到當前時間點之后的某一個時間定時投遞到消費者Consumer進行消費的消息。需要明確指定時間點(必須在當前時間點之后)。
延時消息 : (從發(fā)送該延時消息的當前時間開始)延遲一定時間后投遞給消費者Consumer進行消費的消息。需要指定延遲時間長度。延時消息只支持TCP接入的Java語言。
定時/延時消息，通過參數(shù)setStartDeliverTime設(shè)置當前時間戳之后的某個時刻(必須在40天以內(nèi)，超過40天消息發(fā)送失敗)，如果這個參數(shù)在當前時間戳之前，消息將立刻被投遞。如果有消息堆積，定時、延時消息會排在堆積消息后面，不能嚴格按照配置的時間進行投遞。設(shè)置定時/延時消息的投遞時間后，依然受3天的消息保存時長限制(即投遞時間點之后仍沒有被消費，3天后消息被刪除)。
順序消息 : 同一個Topic內(nèi)保證順序，由順序發(fā)布和順序消費兩部分組成。分為全局順序，和分區(qū)順序兩種類型。順序消息只支持可靠同步發(fā)送方式，不支持異步發(fā)送。順序消息支持集群消費，不支持廣播消費。順序消息支持MQ所有公共云Region和金融云Region。對于HTTP協(xié)議接入的，只支持順序消息發(fā)送，暫不支持順序消息消費。
全局順序消息 : 所有消息按照嚴格的先進先出（FIFO）的順序進行發(fā)布和消費(性能一般)。
分區(qū)順序消息 : 所有消息根據(jù)sharding key(順序消息中用來區(qū)分不同分區(qū)的關(guān)鍵字段)進行區(qū)塊分區(qū)。同一個分區(qū)內(nèi)的消息按照嚴格的FIFO順序進行發(fā)布和消費(性能較高)。
事務(wù)消息 : 實現(xiàn)類似X/Open XA的分布事務(wù)功能，達到分布式事務(wù)的最終一致。事務(wù)消息的Producer ID不能與其他類型消息的Producer ID共用。半消息 : 事務(wù)消息流程中暫不能投遞的消息，發(fā)送方已經(jīng)將消息成功發(fā)送到了MQ服務(wù)端，但是服務(wù)端未收到生產(chǎn)者對該消息的二次確認，此時該消息被標記成"暫不能投遞"狀態(tài)，處于該種狀態(tài)下的消息即半消息。