RocketMQ-初体验RocketMQ(01)_RocketMQ初体验
文章目錄
- RocketMQ的由來
- RocketMQ 版本
- RocketMQ 基本概念
- 消息模型
- 消息生產者(producer)
- 消息消費者（Consumer）
- 主題（Topic）
- 代理服務器（Broker Server）
- 名稱服務（Name Server）
- 拉取式消費（Pull Consumer）
- 推動式消費（Push Consumer）
- 生產者組（Producer Group）
- 消費者組（Consumer Group）
- 集群消費（Clustering）
- 廣播消費（Broadcasting）
- 普通順序消息（Normal Ordered Message）
- 嚴格順序消息（Strictly Ordered Message）
- 消息（Message）
- 標簽（Tag）
- RocketMQ 架構圖
- 四部分組成
- 白話RocketMQ的架構圖
- 消息隊列的作用
- Kafka VS RocketMQ VS RabbitMQ
RocketMQ的由來
09年，淘寶第一個雙十一，那個時候還是IOE的天下（IBM小型機、Oracle數據庫、EMC存儲設備），仍然扛不住雙十一高并發的情況，于是乎阿里巴巴發起了著名的“去IOE”活動， 代之以自己在開源軟件基礎上開發的系統。
發展歷程：
- … ， 漫長的積累發展
- 12年，開源自研的第三代分布式消息中間件RocketMQ，
- 16年，RocketMQ進入Apache 孵化
- 如今，RocketMQ已經是Apache的頂級項目。
更多請戳： RocketMQ的前世今生
RocketMQ 版本
- 開源版本
- 商業收費版本
我們這里討論的都是 開源版本的功能
RocketMQ 基本概念
https://github.com/apache/rocketmq/blob/master/docs/cn/concept.md
RocketMQ中的幾個基本概念，還是需要知道的，不然不好理解RMQ的架構圖
消息模型
RocketMQ主要由 Producer、Broker、Consumer 三部分組成。
Producer 負責生產消息
Consumer 負責消費消息
Broker 負責存儲消息
消息生產者(producer)
負責生產消息，一般由業務系統負責生產消息。
一個消息生產者會把業務應用系統里產生的消息發送到broker服務器。
RocketMQ提供多種發送方式，同步發送、異步發送、順序發送、單向發送.
同步和異步方式均需要Broker返回確認信息，單向發送不需要。
消息消費者（Consumer）
負責消費消息，一般是后臺系統負責異步消費。
一個消息消費者會從Broker服務器拉取消息、并將其提供給應用程序
從用戶應用的角度而言提供了兩種消費形式：拉取式消費(pull consumer)、推動式消費(push consumer)。
主題（Topic）
表示一類消息的集合，每個主題包含若干條消息，每條消息只能屬于一個主題，是RocketMQ進行消息訂閱的基本單位。
代理服務器（Broker Server）
消息中轉角色，負責存儲消息、轉發消息。
代理服務器在RocketMQ系統中負責接收從生產者發送來的消息并存儲、同時為消費者的拉取請求作準備。
代理服務器也存儲消息相關的元數據，包括消費者組、消費進度偏移和主題和隊列消息等
名稱服務（Name Server）
Name Server充當路由消息的提供者。生產者或消費者能夠通過Name Server查找各主題相應的Broker IP列表。
多個Namesrv實例組成集群，但相互獨立，沒有信息交換。
拉取式消費（Pull Consumer）
Consumer消費的一種類型，應用通常主動調用Consumer的拉消息方法從Broker服務器拉消息、主動權由應用控制。一旦獲取了批量消息，應用就會啟動消費過程。
推動式消費（Push Consumer）
Consumer消費的一種類型，該模式下Broker收到數據后會主動推送給消費端，該消費模式一般實時性較高。
生產者組（Producer Group）
同一類Producer的集合，這類Producer發送同一類消息且發送邏輯一致。
如果發送的事務消息且原始生產者在發送之后崩潰，則Broker服務器會聯系同一生產者組的其他生產者實例以提交或回溯消費。
消費者組（Consumer Group）
同一類Consumer的集合，這類Consumer通常消費同一類消息且消費邏輯一致
消費者組使得在消息消費方面，實現負載均衡和容錯的目標變得非常容易。要注意的是，消費者組的消費者實例必須訂閱完全相同的Topic。
RocketMQ 支持兩種消息模式：集群消費（Clustering）和廣播消費（Broadcasting）。
集群消費（Clustering）
集群消費模式下,相同Consumer Group的每個Consumer實例平均分攤消息。
廣播消費（Broadcasting）
廣播消費模式下，相同Consumer Group的每個Consumer實例都接收全量的消息。
普通順序消息（Normal Ordered Message）
普通順序消費模式下，消費者通過同一個消費隊列收到的消息是有順序的，不同消息隊列收到的消息則可能是無順序的。
嚴格順序消息（Strictly Ordered Message）
嚴格順序消息模式下，消費者收到的所有消息均是有順序的。
消息（Message）
消息系統所傳輸信息的物理載體，生產和消費數據的最小單位，每條消息必須屬于一個主題。
RocketMQ中每個消息擁有唯一的Message ID，且可以攜帶具有業務標識的Key。
系統提供了通過Message ID和Key查詢消息的功能。
標簽（Tag）
為消息設置的標志，用于同一主題下區分不同類型的消息. .
來自同一業務單元的消息，可以根據不同業務目的在同一主題下設置不同標簽。
標簽能夠有效地保持代碼的清晰度和連貫性，并優化RocketMQ提供的查詢系統。
消費者可以根據Tag實現對不同子主題的不同消費邏輯，實現更好的擴展性。
RocketMQ 架構圖
Apache RocketMQ借鑒了kafka的架構，對其進行了優，純Java開發，具有低延遲、高吞吐量、高可用性、適合大規模分布式系統應用的特點。
RocketMQ目前在阿里集團被廣泛應用于交易、充值、流計算、消息推送、日志流式處理、binglog分發等場景
它們中的每一個都可以水平擴展，而沒有單個故障點 。
四部分組成
- nameserver ： 提供輕量級的服務發現和路由。 每個名稱服務器記錄完整的路由信息，提供相應的讀寫服務，并支持快速的存儲擴展。
- broker ： 通過提供輕量級的TOPIC和QUEUE機制來存儲消息。
- 生產者
- 使用者
nameserver集群、 生產者集群 、 消費者集群都是無狀態的 。
每一個nameserver都存儲所有broker集群的信息 。
rocketmq 亮點功能： 支持 分布式事務， 支持SQL92 …
白話RocketMQ的架構圖
nameserver , 類似zookeeper注冊中心，用來收集broker的信息。 broker都會注冊到nameserver .
每個namesrv 都會包含broker集群 主從節點的全部信息。 比如上圖 3個namesrv， 4個 broker： 每個namesrv都會包含 broker cluster中的 4個broker的全量信息 。
broker 集群 會向每個namersrv 全量信息。 之所以這樣做，因為namesrv 設計的是無狀態的，每個namesrv之間是沒有關聯的。 其中一個namesrv節點掛了，其他的節點是無感知的。 namesrv不支持有狀態，選舉等功能，所以包含broker cluster的全量信。
我們的producer和consumer 都會配置 全部的namesrv節點的信息，都會配到對應的配置文件中，這也就意味著，當發起心跳拉取信息時，即便有個一個namesrv掛了，還有其他的namesrv節點可用。 只要有個1個namesrv是可用的，就能夠獲取到broker的信息
.
在最開始， producer和consumer都是沒有broker的信息的，都是需要從namesrv上拉取broker集群的信息。 producer 和 consumer 從namesrv拉取信息，也不是實時拉取的，大概30s拉取一次，頻率也還好。
相應的， consumer也是無狀態的， 比如圖上的3個consumer節點， 其中一個掛了，其他兩個consumer也是感知不到的，跟這倆consumer也沒關系， 同理，producer亦是如此。 每個節點都是單獨從namesrv上拉取信息，互相獨立。
服務端的話其實即使 namesrv + broker ， 然后加上 producer 、consumer 就構成了 RocketMQ的基本組成。
broker一旦啟動以后，會有個定時任務主動的向namesrv發送心跳信息（發送broker中的基本信息、topic數據、偏移量等等）
假設你的producer 或者 consumer 的量非常大，namesrv 扛不住了，這個時候增加namesrv的節點即可。 namesrv的節點越多，你命中那個失敗的namesrv的概率就會降低。
除了broker，剩下3個的集群都是無狀態的。 broker才是真正的核心。
消息隊列的作用
說點大家都知道的 消息隊列的作用
- 解耦
- 削峰填谷
- 異步處理
- 分布式事務-中間協調
舉個例子 比如解耦
各個服務之間從原來的強耦合，加入了消息隊列后，支撐成功后，扔到消息隊列里面，剩下的服務誰需要處理這個消息，誰來訂閱即可，減少了下訂單的時長。
Kafka VS RocketMQ VS RabbitMQ
從網上找的一個圖，個人認為非常不錯，請移步
戳這里： Kafka VS RocketMQ VS RabbitMQ
另外官網上 有關于 ActiveMQ VS Kafka VS RocketMQ, 請移步 ： 戳這里
總結
以上是生活随笔為你收集整理的RocketMQ-初体验RocketMQ(01)_RocketMQ初体验的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java-CentoOS 7安装JDK8
- 下一篇： RocketMQ-初体验RocketMQ