RocketMQ技術全面決議（概念、設計理念與目標、資訊發送、同步發送--含代碼！）

1.RocketMQ 介紹

訊息佇列 RocketMQ 是阿里巴巴集團基于高可用分布式集群技術，自主研發的云正式商用的專業訊息中間件，既可為分布式應用系統提供異步解耦 和削峰填谷的能力，同時也具備互聯網應用所需的海量訊息堆積、高吞吐、可靠重試等特性，是阿里巴巴雙 11 使用的核心產品，
RocketMQ 的設計基于主題的發布與訂閱模式，其核心功能包括訊息發送、訊息存盤(Broker)、訊息消費，整體設計追求簡單與性能第一，

1. NameServer 設計及其簡單，RocketMQ 擯棄了業界常用的 Zookeeper 充當訊息管理的“注冊中心”，而是使用自主研發的 NameServer 來實作各 種元資料的管理（Topic 路由資訊等）
2. 高效的 I/O 存盤，RocketMQ 追求訊息發送的高吞吐量，RocketMQ 的訊息存盤設計成檔案組的概念，組內單個檔案固定大小，引入了記憶體映射機 制，所有主題的訊息存盤基于順序讀寫，極大提高訊息寫性能，同時為了兼顧訊息消費與訊息查找，引入訊息消費佇列檔案與索引檔案
3. 容忍存在設計缺陷，適當將某些作業下放給 RocketMQ 的使用者，比如訊息只消費一次，這樣極大的簡化了訊息中間件的內核，使得 RocketMQ 的實作發送變得非常簡單與高效，
   RocketMQ 原先阿里巴巴內部使用，與 2017 年提交到 Apache 基金會成為 Apache 基金會的頂級開源專案，GitHub 代碼庫鏈接:https://github.com/apache/rocketmq.git
   RocketMQ 的官網 http://rocketmq.apache.org/

MQ:訊息中間件是什么？
訊息中間件屬于分布式系統中一個子系統，關注于資料的發送和接收，利用高效可靠的異步訊息傳遞機制對分布式系統中的其余各個子系統進行集成

2.核心概念

2.1NameServer

NameServer 是整個 RocketMQ 的“大腦”，它是 RocketMQ 的服務注冊中心,所以 RocketMQ需要先啟動 NameServer 再啟動 Rocket 中的 Broker，

Broker 在啟動時向所有 NameServer 注冊（主要是服務器地址等），生產者在發送訊息之前先從 NameServer 獲取 Broker 服務器地址串列（消費者一 樣），然后根據負載均衡演算法從串列中選擇一臺服務器進行訊息發送，
NameServer與每臺 Broker 服務保持長連接，并間隔 30S 檢查 Broker 是否存活，如果檢測到 Broker 宕機，則從路由注冊表中將其移除，這樣就可以實 現 RocketMQ 的高可用，具體細節后續的課程會進行講解，

2.2主題

主題，Topic，訊息主題，一級訊息型別，生產者向其發送訊息，消費者負責從 Topic 接收并消費訊息，

2.3生產者

生產者：也稱為訊息發布者，負責生產并發送訊息至 Topic，

2.4消費者

消費者：也稱為訊息訂閱者，負責從 Topic 接收并消費訊息，

2.5訊息

訊息：生產者或消費者進行訊息發送或消費的主題，對于 RocketMQ 來說，訊息就是位元組陣列，

3.核心概念

以下我們將總結下 Rocket 的整體運轉，

1. NameServer 先啟動
2. Broker 啟動時向 NameServer 注冊
3. 生產者在發送某個主題的訊息之前先從 NamerServer 獲取 Broker 服務器地址串列（有可能是集群），然后根據負載均衡演算法從串列中選擇一臺 Broker 進行訊息發送，
4. NameServer 與每臺 Broker 服務器保持長連接，并間隔 30S 檢測 Broker 是否存活，如果檢測到 Broker 宕機（使用心跳機制，如果檢測超過 120S），則從路由注冊表中將其移除，
5. 消費者在訂閱某個主題的訊息之前從 NamerServer 獲取 Broker 服務器地址串列（有可能是集群），但是消費者選擇從 Broker 中 訂閱訊息，訂閱 規則由 Broker 配置決定，

點我獲取RocketMQ完整筆記-》》》》》》》》》》》》

4.RocketMQ 的設計理念和目標

4.1設計理念

整體設計思想 **80%**借鑒 Kafka.
基于主題的發布和訂閱，其核心功能，訊息發送、訊息存盤和訊息消費，整體設計追求簡單與性能， NameServer 性能對比 Zookeeper 有極大的提升
高效的 IO 存盤機制，基于檔案順序讀寫，記憶體映射機制
容忍設計缺陷，比如訊息只消費一次，Rocket 自身不保證，從而簡化 Rocket 的內核使得 Rocket 簡單與高效，這個問題交給消費者去實作（冪等），

4.2設計目標

架構模式：發布訂閱模式，主要組件：訊息發送者、訊息服務器（訊息存盤）、訊息消費、路由發現，
順序訊息：RocketMQ 可以嚴格保證訊息有序
訊息過濾：訊息消費是，消費者可以對同一主題下的訊息按照規則只消費自己感興趣的訊息，可以支持在服務端與消費端的訊息過濾機制，
訊息存盤：一般 MQ 核心就是訊息的存盤，對存盤一般來說兩個維度:訊息堆積能力和訊息存盤性能，RocketMQ 追求訊息存盤的高性能，引入記憶體映 射機制，所有的主題訊息順序存盤在同一個檔案中，同時為了防止無限堆積，引入訊息檔案過期機制和檔案存盤空間報警機制，
訊息高可用：

1. Rocket 關機、斷電等情況下，Rokcet 可以確保不丟失訊息（同步刷盤機制不丟失，異步刷盤會丟失少量），
2. 另外如果 Rocket 服務器因為 CPU、記憶體、主板、磁盤等關鍵設備損壞導致無法開機，這個屬于單點故障，該節點上的訊息全部丟失，如果開啟了 異步復制機制，Rocket 可以確保只丟失很少量訊息，
3. 如果引入雙寫機制，這樣基本上可以滿足訊息可靠性要求極高的場景（畢竟兩臺主服務器同時故障的可能性還是非常小）
   訊息消費低延遲：RocketMQ在訊息不發生訊息堆積時，以長輪詢模式實作準實時的訊息推送模式，
   確保訊息必須被消費一次：訊息確認機制(ACK)來確保訊息至少被消費一次，一般 ACK 機制只能做到訊息只被消費一次，有重復消費的可能，
   訊息回溯：已經消費完的訊息，可以根據業務要求重新消費訊息，
   訊息堆積：訊息中間件的主要功能是異步解耦，還有個重要功能是擋住前端的資料洪峰，保證后端系統的穩定性，這就要求訊息中間件具有一定的 訊息堆積能力，RocketMQ 采用磁盤檔案存盤，所以堆積能力比較強，同時提供檔案過期洗掉機制，
   定時訊息：定時訊息，定時訊息是指訊息發送到 Rocket Broker 上之后，不被消費者理解消費，要到等待一定的時間才能進行消費，apache 的版本目 前只支持等待指定的時間才能被消費，不支持任意精度的定時訊息消費，（一個說法是任意精度的定時訊息會帶來性能損耗，但是阿里云版本的 RocketMQ 卻提供這樣的功能，充值收費優先策略？）
   訊息重試機制：訊息重試是指在訊息消費時，如果發送例外，那么訊息中間件需要支持訊息重新投遞，RocketMQ 支持訊息重試機制，

5.RocketMq 中訊息的發送

普通訊息是指訊息佇列 RocketMQ 中無特性的訊息，區別于有特性的定時/延時訊息、順序訊息和事務訊息，這些后續會細講， RocketMQ 發送普通訊息有三種實作方式：單向(OneWay)發送、可靠同步發送、可靠異步發送，
訊息生產的客戶端依賴如下：

broker.conf

#是否允許 **Broker** 自動創建 Topic，建議線下開啟，線上關閉 
autoCreateTopicEnable=true 
#是否允許 Broker 自動創建訂閱組，建議線下開啟，線上關閉 
autoCreateSubscriptionGroup=true

5.1單向(OneWay)發送

5.1.1.代碼演示

單向（Oneway）發送特點為發送方只負責發送訊息，不等待服務器回應且沒有回呼函式觸發，即只發送請求不等待應答，此方式發送訊息的程序耗 時非常短，一般在微秒級別，cn.enjoyedu.normal.OnewayProducer

點我獲取RocketMQ完整筆記-》》》》》》》》》》》》》》》》》》

5.1.2.Producer Group（生產者分組）

生產者組，簡單來說就是多個發送同一類訊息的生產者稱之為一個生產者組，在這里可以不用關心，只要知道有這么一個概念即可，RocketMQ 中的 生產者組只能有一個在用的生產者，分組的作用如下（簡單的場景不需要了解這個概念）：

1. 標識一類 Producer
2. 可以通過運維工具查詢這個發送訊息應用下有多個 Producer 實體
3. 發送分布式事務訊息時，如果 Producer 中途意外宕機，Broker 會主動回呼 Producer Group 內的任意一臺機器來確認事務狀態，

5.1.3.Producer 實體

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

5.1.4.Message Key

Key 一般用于訊息在業務層面的唯一標識，對發送的訊息設定好 Key，以后可以根據這個 Key 來查找訊息，比如訊息例外，訊息丟失，進行查找會很 方便，RocketMQ 會創建專門的索引檔案，用來存盤 Key 與訊息的映射，由于是 Hash 索引，應盡量使 Key 唯一，避免潛在的哈希沖突，
Tag 和 Key 的主要差別是使用場景不同，Tag 用在 Consumer 代碼中，用于服務端訊息過濾，Key 主要用于通過命令進行查找訊息
RocketMQ 并不能保證 message id 唯一，在這種情況下，生產者在 push 訊息的時候可以給每條訊息設定唯一的 key, 消費者可以通過 message key 保證對訊息冪等處理，

5.1.5.Tag

訊息標簽，二級訊息型別，用來進一步區分某個 Topic 下的訊息分類，
Topic 與 Tag 都是業務上用來歸類的標識，區分在于 Topic 是一級分類，而 Tag 可以理解為是二級分類，
以天貓交易平臺為例，訂單訊息和支付訊息屬于不同業務型別的訊息，分別創建 Topic_Order 和 Topic_Pay，其中訂單訊息根據商品品類以不同的 Tag 再進行細分，如電器類、男裝類、女裝類、化妝品類，最后他們都被各個不同的系統所接收，
通過合理的使用 Topic 和 Tag，可以讓業務結構清晰，更可以提高效率，
您可能會有這樣的疑問：到底什么時候該用 Topic，什么時候該用 Tag？
1）訊息型別是否一致：如普通訊息、事務訊息、定時（延時）訊息、順序訊息，不同的訊息型別使用不同的 Topic，無法通過 Tag 進行區分，
2）業務是否相關聯：沒有直接關聯的訊息，如淘寶交易訊息，京東物流訊息使用不同的 Topic 進行區分；而同樣是天貓交易訊息，電器類訂單、女 裝類訂單、化妝品類訂單的訊息可以用 Tag 進行區分，
3）訊息優先級是否一致：如同樣是物流訊息，盒馬必須小時內送達，天貓超市 24 小時內送達，淘寶物流則相對會慢一些，不同優先級的訊息用不 同的 Topic 進行區分，
4）訊息量級是否相當：有些業務訊息雖然量小但是實時性要求高，如果跟某些萬億量級的訊息使用同一個 Topic，則有可能會因為過長的等待時間 而“餓死”，此時需要將不同量級的訊息進行拆分，使用不同的 Topic，

5.2.可靠同步發送

####代碼演示

同步發送是指訊息發送方發出資料后，同步等待，直到收到接收方發回回應之后才發下一個請求，

點我獲取更多-》》》》》》》》》》》》》》》》》》

5.2.1.Message ID

訊息的全域唯一標識（內部機制的 ID 生成是使用機器 IP 和訊息偏移量的組成，所以有可能重復，如果是冪等性還是最好考慮 Key），由訊息佇列 MQ 系統自動生成，唯一標識某條訊息，

5.2.2.SendStatus

發送的標識，成功，失敗等

5.2.3Queue

RocketMQ 收到訊息后，所有主題的訊息都存盤在 commitlog檔案中，當訊息到達 commitlog 后，將會采用異步轉發到訊息佇列，也就是 consumerqueue, Queue 是資料分片的產物，資料分片可以提高消費者的效率，(這個也是 RocketMQ 對比 Kafka 的不同，存盤設計時有佇列的概念)

broker.conf

# 在發送訊息時，自動創建服務器不存在的 topic，默認創建的佇列數 
defaultTopicQueueNums=4

5.3.可靠異步發送

5.3.1.代碼演示

訊息發送方在發送了一條訊息后，不等接收方發回回應，接著進行第二條訊息發送，發送方通過回呼介面的方式接收服務器回應，并對回應結果進 行處理

5.4.RocketMQ 中訊息發送的權衡

三種發送方式的對比

整理不易!點個關注,收藏一下吧！

點我獲取RocketMQ完整筆記-》》》》》》》》》》》》》》》》》》