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