消息隊列之-RocketMQ入門

• 2020 年 9 月 8 日
• 筆記

簡介

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

• 官網：//rocketmq.apache.org/
• 快速入門：//rocketmq.apache.org/docs/quick-start/
• 阿里雲幫助文檔：//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 //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. 啟動成功後，訪問地址//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://rocketmq.apache.org/docs/motivation/
• alibaba://help.aliyun.com/document_detail/29532.html
• //my.oschina.net/buru1kan/blog/1814356
• //xiajunhust.github.io/2016/11/12/RocketMQ源碼學習之一-MAC系統單機環境搭建/

結語

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