RocketMq是一個由阿里巴巴開源的消息中間件，脫胎去阿里每部使用的MetaQ，在設計上借鑑了Kafka。
2012年開源，2017年成為apache頂級項目。
rocketmq的概念模型
入門一項新技術，首先認識它的核心概念。
這三者是RocketMq中最最基本的概念。Producer是消息的生產者。Consumer是消息的消費者。消息通過Topic進行傳遞。Topic存放的是消息的邏輯地址。
具體來說是Producer將消息發往具體的Topic。Consumer訂閱Topic，主動拉取或被動接受消息。
實際上，Topic還需要拆封出更多概念
這張圖裡有兩個生產者，ProducerA和ProducerB。定義了兩個Topic-TopicA和TopicB。ProducerA會發送兩種消息。
TopicA有3個MessageQueue，MessageQueue記錄的是消息的物理存儲地址（在consumelog裡的位置），分佈在兩個broker上。Broker是一個集群部署架構上的概念，可以理解為對應的物理機器。最右邊是ConsumerGroup，每一組下又有多個Consumer，實際上也就是啟動的用來消費的JVM。一個Consumer可以訂閱多個不同的Topic。這裡我有話要說，雖然從代碼層面上支持這種訂閱。但是強烈不建議一個Consumer訂閱多個不同的Topic。推薦用法是一組ConsumerGroup只訂閱一種Topic。
另外多組ConsumerGroup之間，對於同一個Topic是廣播訂閱的。（翻譯一下就是說：Topic的一條消息會廣播給所有訂閱的ConsumerGroup，就是每個ConsumerGroup都會收到），但是在一個ConsumerGroup內部給個Consumer是負載消費消息的，（翻譯一下就是：一條消息在一個group內只會被一個Consumer消費）
存儲模型
下面看看Rocketmq的消息實際是怎麼存儲的？
左邊的是CommitLog。這個是真正存儲消息的地方。可以看出RocketMQ所有生產者的消息都是往這一個地方存的。
右邊是ConsumeQueue。這是一個邏輯隊列。和上文中Topic下的messageQueue是一一對應的。消費者是直接和ConsumeQueue打交道。ConsumeQueue記錄了消費位點，這個消費位點關聯了commitlog的位置。所以即使ConsumeQueue出問題，只要commitlog還在，消息就沒丟，可以恢復出來。還可以通過修改消費位點來重放或跳過一些消息。
部署模型
在部署RocketMQ時，會部署兩種角色。NameServer和Broker。NameServer主要做路由服務。生產者發送消息時，首先向NameServer拿到Topic的路由信息，即這個Topic在哪些Broker上有。Consumer也是一樣，需要知道消費隊列的路由情況。當然不是每次收發消息都去NameServer查詢一遍，簡單的說只有第一次初始化，和以後發送或這首出現問題時需要查詢一下。
Broker一般我們會部署主備兩個節點。
RocketMq沒有選舉，broker的角色是在部署時就人工確定好的。如果主掛了，備不會自動切換為主。
對於一個2主2備的集群來說，如果掛了一個主，是沒有問題的。只要另一個主上你之前也創建了Topic，那麼發送的消息流量會導流到存活的主節點上，業務代碼端是無影響的。
閱讀更多 IT技術圈 的文章
