訊息佇列之-RocketMQ入門

簡介

RocketMQ是阿里開源的訊息中介軟體，目前已經捐獻個Apache基金會，它是由Java語言開發的，具備高吞吐量、高可用性、適合大規模分散式系統應用等特點，經歷過雙11的洗禮，實力不容小覷。

• 官網：https://rocketmq.apache.org/
• 快速入門：https://rocketmq.apache.org/docs/quick-start/
• 阿里雲幫助文件：https://help.aliyun.com/document_detail/29532.html

RocketMQ中文文件

本文分三篇,分別從概念原理，叢集搭建，Java接入實戰，順序訊息和事務訊息講解
本篇內容參照官方文件(Alibaba,apache),原文講的很簡白,本篇引用,不做贅述.

基本概念及優勢

rocketmq是一個基於釋出訂閱佇列模型的訊息中介軟體,具有高可用,高效能,高實時,天然分散式等特點,(支撐過數次Alibaba雙十一),能保證訊息嚴格有序,億級訊息堆積等,設計模型和傳統的訊息中介軟體一樣,如下(不包含協議)

物理部署結構

由上圖結構,rocketmq由四大部分組成(叢集模式):
NameServer Cluster(名稱伺服器),
Broker Cluster(代理),
Producer Cluster(生產者),
Consumer Cluster(消費者);
它們中的每一個都可以水平擴充套件，而不會出現單點故障。如上截圖所示

NameServer
名稱伺服器提供輕量級服務發現和路由。每個名稱伺服器記錄完整的路由資訊，提供相應的讀寫服務，支援快速儲存擴充套件

NameServer是一個幾乎無狀態的功能齊全的伺服器，主要包括兩個功能：
1.broker 管理，nameserver 接受來自broker叢集的註冊資訊並提供心跳來檢測他們是否可用。
2.路由管理 每一個nameserver都持有關於broker叢集和佇列的全部路由資訊，用來向客戶端提供查詢。
我們知道 ，rocketMQ客戶端（生產者/消費者）會從nameserver查詢佇列的路由資訊.
有四種方式能夠讓客戶端湖區到nameserver的地址：
(1).通過程式，像這樣producer.setNamesrvAddr(“ip:port”)(最實用)
(2).java 配置項，這麼用rocketmq.namesrv.addr
(3).環境變數 NAMESRV_ADDR
(4).HTTP 端點
其中優先順序:程式>java配置>環境變數>Http端點
Broker
Broker通過提供輕量級主題和佇列機制來處理訊息儲存。它們支援Push和Pull模型，包含容錯機制(2個副本或3個副本)，提供了極強的峰值處理裡能力和按照時間順序儲存數以百萬記的訊息儲存能力，此外，代理提供了災難恢復、豐富的度量統計和警報機制，這些都是在傳統的訊息傳遞系統中缺乏的

broker server負責訊息的儲存傳遞，訊息查詢，保證高可用等等。
像下圖所示，broker server有一些非常重要的子模組：
(1)remoting（遠端） 模組，broker的入口，處理從客戶端發起的請求。
(2)client manager（客戶端管理） 管理各個客戶端（生產者/消費者）還有維護消費者主題訂閱。
(3)store（儲存服務），提供簡單的api來在磁碟保持或者查詢訊息。
(4)HA 高可用服務 提供主從broker的資料同步。
(5)index(索引服務)為訊息建立索引提供訊息快速查詢。

Producer
produce支援分散式部署，分散式的produce通過broker叢集提供的各種負載均衡策略將訊息傳送到broker叢集中。傳送過程支援快速失敗是低延遲的

Consumer
消費者也支援在推送和者拉取模式下分散式部署，支援叢集消費和訊息廣播。提供實時的訊息訂閱機制，能夠滿足大多數消費者的需求.

名詞解釋

Topic

訊息主題，一級訊息型別，通過 Topic 對訊息進行分類。

Tag

訊息標籤，二級訊息型別，用來進一步區分某個 Topic 下的訊息分類。

Producer

訊息生產者，也稱為訊息釋出者，負責生產併傳送訊息。

Producer ID

一類 Producer 的標識，這類 Producer 通常生產併傳送一類訊息，且傳送邏輯一致。

Producer 例項

Producer 的一個物件例項，不同的 Producer 例項可以執行在不同程式內或者不同機器上。Producer 例項執行緒安全，可在同一程式內多執行緒之間共享。

Consumer

訊息消費者，也稱為訊息訂閱者，負責接收並消費訊息。

Consumer ID

一類 Consumer 的標識，這類 Consumer 通常接收並消費一類訊息，且消費邏輯一致。

Consumer 例項

Consumer 的一個物件例項，不同的 Consumer 例項可以執行在不同程式內或者不同機器上。一個 Consumer 例項內配置執行緒池消費訊息。

叢集消費

一個 Consumer ID 所標識的所有 Consumer 平均分攤消費訊息。例如某個 Topic 有 9 條訊息，一個 Consumer ID 有 3 個 Consumer 例項，那麼在叢集消費模式下每個例項平均分攤，只消費其中的 3 條訊息。

廣播消費

一個 Consumer ID 所標識的所有 Consumer 都會各自消費某條訊息一次。例如某個 Topic 有 9 條訊息，一個 Consumer ID 有 3 個 Consumer 例項，那麼在廣播消費模式下每個例項都會各自消費 9 條訊息。

定時訊息

Producer 將訊息傳送到 MQ 服務端，但並不期望這條訊息立馬投遞，而是推遲到在當前時間點之後的某一個時間投遞到 Consumer 進行消費，該訊息即定時訊息。

延時訊息

Producer 將訊息傳送到 MQ 服務端，但並不期望這條訊息立馬投遞，而是延遲一定時間後才投遞到 Consumer 進行消費，該訊息即延時訊息。

事務訊息

MQ 提供類似 X/Open XA 的分佈事務功能，通過 MQ 事務訊息能達到分散式事務的最終一致。

順序訊息

MQ 提供的一種按照順序進行釋出和消費的訊息型別, 分為全域性順序訊息和分割槽順序訊息。

順序釋出

對於指定的一個 Topic，客戶端將按照一定的先後順序進行傳送訊息。

順序消費

對於指定的一個 Topic，按照一定的先後順序進行接收訊息，即先傳送的訊息一定會先被客戶端接收到。

全域性順序訊息

對於指定的一個 Topic，所有訊息按照嚴格的先入先出（FIFO）的順序進行釋出和消費。

分割槽順序訊息

對於指定的一個 Topic，所有訊息根據 sharding key 進行區塊分割槽。同一個分割槽內的訊息按照嚴格的 FIFO 順序進行釋出和消費。Sharding key 是順序訊息中用來區分不同分割槽的關鍵欄位，和普通訊息的 key 是完全不同的概念。

訊息堆積

Producer 已經將訊息傳送到 MQ 服務端，但由於 Consumer 消費能力有限，未能在短時間內將所有訊息正確消費掉，此時在 MQ 服務端儲存著未被消費的訊息，該狀態即訊息堆積。

訊息過濾

訂閱者可以根據訊息標籤（Tag）對訊息進行過濾，確保訂閱者最終只接收被過濾後的訊息型別。訊息過濾在 MQ 服務端完成。

訊息軌跡

在一條訊息從釋出者發出到訂閱者消費處理過程中，由各個相關節點的時間、地點等資料匯聚而成的完整鏈路資訊。通過訊息軌跡，使用者能清晰定位訊息從釋出者發出，經由 MQ 服務端，投遞給訊息訂閱者的完整鏈路，方便定位排查問題。

重置消費位點

以時間軸為座標，在訊息持久化儲存的時間範圍內（預設3天），重新設定訊息訂閱者對其訂閱 Topic 的消費進度，設定完成後訂閱者將接收設定時間點之後由訊息釋出者傳送到 MQ 服務端的訊息。

訊息型別

普通訊息

指沒特性的訊息,僅僅是個訊息,區別於有特性的定時和延時訊息、順序訊息和事務訊息.
傳送普通訊息有三種方式:

1. 可靠同步傳送
   原理：同步傳送是指訊息傳送方發出資料後，會在收到接收方發回響應之後才發下一個資料包的通訊方式。
   應用場景：此種方式應用場景非常廣泛，例如重要通知郵件、報名簡訊通知、營銷簡訊系統等。
2. 可靠非同步傳送
   原理：非同步傳送是指傳送方發出資料後，不等接收方發回響應，接著傳送下個資料包的通訊方式。 MQ 的非同步傳送，需要使用者實現非同步傳送回撥介面（SendCallback）。訊息傳送方在傳送了一條訊息後，不需要等待伺服器響應即可返回，進行第二條訊息傳送。傳送方通過回撥介面接收伺服器響應，並對響應結果進行處理。
   應用場景：非同步傳送一般用於鏈路耗時較長，對 RT 響應時間較為敏感的業務場景，例如使用者視訊上傳後通知啟動轉碼服務，轉碼完成後通知推送轉碼結果等。
3. 單向（Oneway）傳送
   原理：單向（Oneway）傳送特點為傳送方只負責傳送訊息，不等待伺服器回應且沒有回撥函式觸發，即只傳送請求不等待應答。 此方式傳送訊息的過程耗時非常短，一般在微秒級別。
   應用場景：適用於某些耗時非常短，但對可靠性要求並不高的場景，例如日誌收集。

定時訊息和延時訊息

定時訊息：Producer 將訊息傳送到 MQ 服務端，但並不期望這條訊息立馬投遞，而是推遲到在當前時間點之後的某一個時間投遞到 Consumer 進行消費，該訊息即定時訊息。
延時訊息：Producer 將訊息傳送到 MQ 服務端，但並不期望這條訊息立馬投遞，而是延遲一定時間後才投遞到 Consumer 進行消費，該訊息即延時訊息。
適用場景
訊息生產和消費有時間視窗要求：比如在電商交易中超時未支付關閉訂單的場景，在訂單建立時會傳送一條 MQ 延時訊息。這條訊息將會在30分鐘以後投遞給消費者，消費者收到此訊息後需要判斷對應的訂單是否已完成支付。 如支付未完成，則關閉訂單。如已完成支付則忽略。
通過訊息觸發一些定時任務，比如在某一固定時間點向使用者傳送提醒訊息。
使用方式
定時訊息和延時訊息的使用在程式碼編寫上存在略微的區別：
傳送定時訊息需要明確指定訊息傳送時間點之後的某一時間點作為訊息投遞的時間點。
傳送延時訊息時需要設定一個延時時間長度，訊息將從當前傳送時間點開始延遲固定時間之後才開始投遞。

順序訊息

順序訊息（FIFO 訊息）是 MQ 提供的一種嚴格按照順序進行釋出和消費的訊息型別。 順序訊息指訊息釋出和訊息消費都按順序進行。
順序釋出：對於指定的一個 Topic，客戶端將按照一定的先後順序傳送訊息。
順序消費：對於指定的一個 Topic，按照一定的先後順序接收訊息，即先傳送的訊息一定會先被客戶端接收到。
全域性順序 : 對於指定的一個 Topic，所有訊息按照嚴格的先入先出（FIFO）的順序進行釋出和消費。

全域性順序適用場景
效能要求不高，所有的訊息嚴格按照 FIFO 原則進行訊息釋出和消費的場景
分割槽順序
對於指定的一個 Topic，所有訊息根據 sharding key 進行區塊分割槽。 同一個分割槽內的訊息按照嚴格的 FIFO 順序進行釋出和消費。 Sharding key 是順序訊息中用來區分不同分割槽的關鍵欄位，和普通訊息的 Key 是完全不同的概念。

適用場景
效能要求高，以 sharding key 作為分割槽欄位，在同一個區塊中嚴格的按照 FIFO 原則進行訊息釋出和消費的場景。

示例
【例一】使用者註冊需要傳送發驗證碼，以使用者 ID 作為 sharding key， 那麼同一個使用者傳送的訊息都會按照先後順序來發布和訂閱。

【例二】電商的訂單建立，以訂單 ID 作為 sharding key，那麼同一個訂單相關的建立訂單訊息、訂單支付訊息、訂單退款訊息、訂單物流訊息都會按照先後順序來發布和訂閱。

阿里巴巴集團內部電商系統均使用分割槽順序訊息，既保證業務的順序，同時又能保證業務的高效能。

2.4 事務訊息
常見的分散式事務解決方案有：最終一致性，兩階段／三界階段提交，TCC，本地訊息表等。這些解決方案中，最終一致性的效能最好。可以通過RocketMQ實現最終一致性。
RocketMQ事務訊息實現方式:
事務訊息：MQ 提供類似 X/Open XA 的分佈事務功能，通過 MQ 事務訊息能達到分散式事務的最終一致。
半訊息：暫不能投遞的訊息，傳送方已經將訊息成功傳送到了 MQ 服務端，但是服務端未收到生產者對該訊息的二次確認，此時該訊息被標記成“暫不能投遞”狀態，處於該種狀態下的訊息即半訊息。
訊息回查：由於網路閃斷、生產者應用重啟等原因，導致某條事務訊息的二次確認丟失，MQ 服務端通過掃描發現某條訊息長期處於“半訊息”時，需要主動向訊息生產者詢問該訊息的最終狀態（Commit 或是 Rollback），該過程即訊息回查。

這篇講的挺細緻:分散式開放訊息系統(RocketMQ)的原理與實踐

訊息模型

叢集消費

叢集： MQ 約定使用相同 Consumer ID 的訂閱者屬於同一個叢集。同一個叢集下的訂閱者消費邏輯必須完全一致（包括 Tag 的使用），這些訂閱者在邏輯上可以認為是一個消費節點。

叢集消費當使用叢集消費模式時，MQ 認為任意一條訊息只需要被叢集內的任意一個消費者處理即可

適用場景和注意事項
消費端叢集化部署，每條訊息只需要被處理一次。
由於消費進度在服務端維護，可靠性更高。
叢集消費模式下，每一條訊息都只會被分發到一臺機器上處理
叢集消費模式下，不保證每一次失敗重投的訊息路由到同一臺機器上，因此處理訊息時不應該做任何確定性假設。

廣播消費

當使用廣播消費模式時，MQ 會將每條訊息推送給叢集內所有註冊過的客戶端，保證訊息至少被每臺機器消費一次。

適用場景和注意事項
廣播消費模式下不支援順序訊息。
每條訊息都需要被相同邏輯的多臺機器處理。
消費進度在客戶端維護，出現重複的概率稍大於叢集模式。
廣播模式下，MQ 保證每條訊息至少被每臺客戶端消費一次，但是並不會對消費失敗的訊息進行失敗重投，因此業務方需要關注消費失敗的情況。
廣播模式下，客戶端第一次啟動時預設從最新訊息消費。客戶端的消費進度是被持久化在客戶端本地的隱藏檔案中，因此不建議刪除該隱藏檔案，否則會丟失部分訊息。
廣播模式下，每條訊息都會被大量的客戶端重複處理，因此推薦儘可能使用叢集模式。
目前僅 Java 客戶端支援廣播模式。
廣播模式下服務端不維護消費進度，所以 MQ 控制檯不支援訊息堆積查詢和堆積報警功能。

點對點(P2P)

點對點（Point to Point, 簡稱 P2P），顧名思義，是一對一的訊息傳遞模式，即只有一個訊息傳送者和一個訊息接收者。而釋出/訂閱（Pub/Sub）通常用於一對多或多對多的訊息群發場景，擁有一個或多個訊息傳送者和多個訊息接收者。

在點對點（P2P）模型中，傳送者傳送訊息時已經明確該訊息預期的接收方資訊，並明確該訊息只需要被特定的單個客戶端消費。傳送者傳送訊息時通過 Topic 資訊直接指定接收者，接收者無需提前進行訂閱即可獲取該訊息。
點對點模式可以節省接收方註冊訂閱關係的成本，而且收發訊息的鏈路有單獨的優化，推送延遲更低。
P2P和pub/sub的區別:
傳送訊息時，Pub/Sub 模式需要按照和接收端約定好的 Topic 傳送訊息，而 P2P 模式下無需事先約定傳輸訊息的 Topic，傳送端可以直接按照規範傳送訊息到目標的接收客戶端。
接收訊息時，Pub/Sub 模式需要按照和傳送端約定好的 Topic 提前訂閱才能收到訊息，而 P2P 模式下無需事先訂閱，可以簡化接收端的程式邏輯，並節省訂閱的成本。

訊息過濾

訊息過濾可在broker和consumer端過濾,一般在consumer上過濾,因為單訊息量大時,broker壓力過重,影響吞吐量
做好過濾得明確為什麼要產生這樣的訊息,明確topic和tag設計的側重.
Topic：訊息主題，通過 Topic 對不同的業務訊息進行分類；
Tag：訊息標籤，用來進一步區分某個 Topic 下的訊息分類，MQ 允許消費者按照Tag 對訊息進行過濾，確保消費者最終只消費到他關注的訊息型別。
topic是一級標籤,tag是二級標籤.
使用準則:
1.訊息型別是否一致,事務訊息,順序訊息等
2.業務相關性:沒有直接關聯的話應用多個topic,例如訂單,物流,支付,而男裝訂單,女裝訂單則可以使用tag
3.訊息量級是否相當：A訊息是萬億量級,B訊息是輕量級但要求實時性高,即便A和B符合準則1,2,也挺該使用不同topic,避免B訊息被 "拖累"

刷盤策略

先看下影響訊息可靠性的幾種情況：

1.Broker正常關閉
2.Broker異常Crash
3.OS Crash
4.機器掉電，但是能立即恢復供電情況。
5.機器無法開機（可能是cpu、主機板、記憶體等關鍵裝置損壞）
6.磁碟裝置損壞。
1,2,3,4四種情況都屬於硬體資源可立即恢復情況,非同步複製的話,可以保證99%的訊息不丟失.5,6屬於單點故障,同步刷盤可保證所有訊息不丟失

非同步複製(非同步刷盤)

當叢集做了主從配置(多主多從),producer向master傳送訊息,master立馬返回,此後根據設定的策略,slave從master上pull訊息,進行同步,當master掛了後,slave不會主動提升為master,但仍可訂閱

同步雙寫

producer向master傳送訊息,只有master和slave都寫入成功時,才返回.效能較非同步略低,適用於對訊息嚴格的業務,比如帶money

安裝與使用

1. 環境要求：
   64bit OS, Linux/Unix/Mac is recommended;
   64bit JDK 1.8+;
   Maven 3.2.x;
   Git;
   4g+ free disk for Broker server
2. 下載編譯
   Click here to download the 4.4.0 source release.

> unzip rocketmq-all-4.4.0-source-release.zip
> cd rocketmq-all-4.4.0/
> mvn -Prelease-all -DskipTests clean install -U
> cd distribution/target/apache-rocketmq

3. 啟動 Name Server

  > nohup sh bin/mqnamesrv &
  > tail -f ~/logs/rocketmqlogs/namesrv.log
  The Name Server boot success...

⚠️注意事項：若在啟動過程中檢視日誌報錯如下：

ERROR: Please set the JAVA_HOME variable in your environment, We need Java(x64)! !!

開啟啟動指令碼runserver.sh以及runbroker.sh檔案，發現有如下三行：

[ ! -e "$JAVA_HOME/bin/java" ] && JAVA_HOME=$HOME/jdk/java
[ ! -e "$JAVA_HOME/bin/java" ] && JAVA_HOME=/usr/java
[ ! -e "$JAVA_HOME/bin/java" ] && error_exit "Please set the JAVA_HOME variable in your environment, We need java(x64)!"

這裡預設設定java安裝路徑為$HOME/jdk/java,其中第二行是阿里巴巴集團內部伺服器上的java目錄，若報以上錯誤，將這一行註釋掉。然後第一行的JAVA_HOME的值改為自己機器的Java安裝目錄。然後再次起送mqnameserver以及mqbroker，觀察日誌發現啟動成功：
特別是MAC OS

tips:
MAC OS reference :MAC OS Start

4. 啟動 Broker

  > nohup sh bin/mqbroker -n localhost:9876 &
  > tail -f ~/logs/rocketmqlogs/broker.log 
  The broker[%s, 172.30.30.233:10911] boot success...

啟動自動建立topic

nohup sh mqbroker -n localhost:9876 autoCreateTopicEnable=true &

5. 傳送消費訊息

6. 關閉 Servers

> sh bin/mqshutdown broker
The mqbroker(36695) is running...
Send shutdown request to mqbroker(36695) OK

> sh bin/mqshutdown namesrv
The mqnamesrv(36664) is running...
Send shutdown request to mqnamesrv(36664) OK

RocketMQ外掛

RocketMQ-Console

RocketMQ-Console是RocketMQ專案的擴充套件外掛，是一個圖形化管理控制檯，提供Broker叢集狀態檢視，Topic管理，Producer、Consumer狀態展示，訊息查詢等常用功能，這個功能在安裝好RocketMQ後需要額外單獨安裝、執行。

1. 進入rocketmq-externals專案GitHub地址，如下圖，可看到RocketMQ專案的諸多擴充套件專案，其中就包含我們需要下載的rocketmq-console。
2. 使用git命令下載專案原始碼，由於我們僅需要rocketmq-console，故下載此專案對應分支即可。

$ git clone -b release-rocketmq-console-1.0.0 https://github.com/apache/rocketmq-externals.git

3. 進入專案資料夾並按照實際情況修改對應配置檔案

server.contextPath=
server.port=8080
#spring.application.index=true
spring.application.name=rocketmq-console
spring.http.encoding.charset=UTF-8
spring.http.encoding.enabled=true
spring.http.encoding.force=true
logging.config=classpath:logback.xml
#if this value is empty,use env value rocketmq.config.namesrvAddr  NAMESRV_ADDR | now, you can set it in ops page.default localhost:9876
rocketmq.config.namesrvAddr=localhost:9876
#if you use rocketmq version < 3.5.8, rocketmq.config.isVIPChannel should be false.default true
rocketmq.config.isVIPChannel=
#rocketmq-console's data path:dashboard/monitor
rocketmq.config.dataPath=/tmp/rocketmq-console/data
#set it false if you don't want use dashboard.default true
rocketmq.config.enableDashBoardCollect=true

Name Server地址預設為空，註釋說可以在啟動專案後在後臺配置，經測試，後臺配置切換失敗，有報錯，所以打包前需修改配置檔案明確給出Name Server地址，或者啟動服務的時候給出rocketmq.config.namesrvAddr引數值。
4. 將專案打成jar包，並執行jar檔案。

$ mvn clean package -Dmaven.test.skip=true
$ java -jar target/rocketmq-console-ng-1.0.0.jar
#如果配置檔案沒有填寫Name Server
$ java -jar target/rocketmq-console-ng-1.0.0.jar --rocketmq.config.namesrvAddr='127.0.0.1:9876'

5. 啟動成功後，訪問地址http://localhost:8080/rocketmq, 即可進入管理後臺操作。

RocketMQ命令列管理工具(CLI Admin Tool)

命令列管理工具（CLI Admin Tool）對RocketMQ叢集的管理提供了更多精細化的管理命令，命令列的方式對操作人員的要求稍高一些，當然，掌握了使用方法，就會簡單高效很多。命令列管理工具無需額外安裝，已經包含在${RocketMQ_HOME}/bin資料夾下面。

上面已經講過命令列管理工具已經包含在RocketMQ專案中，我們進入專案下的bin資料夾，並執行命令bash mqadmin:

The most commonly used mqadmin commands are:
   updateTopic          Update or create topic
   deleteTopic          Delete topic from broker and NameServer.
   updateSubGroup       Update or create subscription group
   deleteSubGroup       Delete subscription group from broker.
   updateBrokerConfig   Update broker's config
   updateTopicPerm      Update topic perm
   topicRoute           Examine topic route info
   topicStatus          Examine topic Status info
   topicClusterList     get cluster info for topic
   brokerStatus         Fetch broker runtime status data
   queryMsgById         Query Message by Id
   queryMsgByKey        Query Message by Key
   queryMsgByUniqueKey  Query Message by Unique key
   queryMsgByOffset     Query Message by offset
   printMsg             Print Message Detail
   printMsgByQueue      Print Message Detail
   sendMsgStatus        send msg to broker.
   brokerConsumeStats   Fetch broker consume stats data
   producerConnection   Query producer's socket connection and client version
   consumerConnection   Query consumer's socket connection, client version and subscription
   consumerProgress     Query consumers's progress, speed
   consumerStatus       Query consumer's internal data structure
   cloneGroupOffset     clone offset from other group.
   clusterList          List all of clusters
   topicList            Fetch all topic list from name server
   updateKvConfig       Create or update KV config.
   deleteKvConfig       Delete KV config.
   wipeWritePerm        Wipe write perm of broker in all name server
   resetOffsetByTime    Reset consumer offset by timestamp(without client restart).
   updateOrderConf      Create or update or delete order conf
   cleanExpiredCQ       Clean expired ConsumeQueue on broker.
   cleanUnusedTopic     Clean unused topic on broker.
   startMonitoring      Start Monitoring
   statsAll             Topic and Consumer tps stats
   allocateMQ           Allocate MQ
   checkMsgSendRT       check message send response time
   clusterRT            List All clusters Message Send RT
   getNamesrvConfig     Get configs of name server.
   updateNamesrvConfig  Update configs of name server.
   getBrokerConfig      Get broker config by cluster or special broker!
   queryCq              Query cq command.
   sendMessage          Send a message
   consumeMessage       Consume message

上面清單中左邊為命令名稱，右邊為命令含義的解釋，可以看到，大部分我們常用的功能已包含其中，具體如何使用這些命令，可以通過執行bash mqadmin help 來了解細節，我們以常用命令updateTopic為例，執行bash mqadmin help updateTopic,列印如下資訊：

usage: mqadmin updateTopic [-b <arg>] [-c <arg>] [-h] [-n <arg>] [-o <arg>] [-p <arg>] [-r <arg>] [-s <arg>]
       -t <arg> [-u <arg>] [-w <arg>]
 -b,--brokerAddr <arg>       create topic to which broker
 -c,--clusterName <arg>      create topic to which cluster
 -h,--help                   Print help
 -n,--namesrvAddr <arg>      Name server address list, eg: 192.168.0.1:9876;192.168.0.2:9876
 -o,--order <arg>            set topic's order(true|false)
 -p,--perm <arg>             set topic's permission(2|4|6), intro[2:W 4:R; 6:RW]
 -r,--readQueueNums <arg>    set read queue nums
 -s,--hasUnitSub <arg>       has unit sub (true|false)
 -t,--topic <arg>            topic name
 -u,--unit <arg>             is unit topic (true|false)
 -w,--writeQueueNums <arg>   set write queue nums

可以看見，剛才新建的TopicTest以及一些系統預設的topic。如果想學習瞭解這些命令的原始碼實現可以點選檢視這裡。

參考

• apache:http://rocketmq.apache.org/docs/motivation/
• alibaba:https://help.aliyun.com/document_detail/29532.html
• https://my.oschina.net/buru1kan/blog/1814356
• http://xiajunhust.github.io/2016/11/12/RocketMQ原始碼學習之一-MAC系統單機環境搭建/

結語

歡迎關注微信公眾號『碼仔zonE』，專注於分享Java、雲端計算相關內容，包括SpringBoot、SpringCloud、微服務、Docker、Kubernetes、Python等領域相關技術乾貨，期待與您相遇！