消息隊列（四）阿里RocketMQ

消息隊列 RocketMQ 是阿里巴巴集團自主研發的專業消息中間件，基於高可用分佈式集羣技術，提供消息訂閱和發佈、消息軌跡查詢以及定時（延時）消息、資源統計、監控報警等一系列消息雲服務，是企業級互聯網架構的核心產品。 消息隊列 RocketMQ 歷史超過9年，爲分佈式應用系統提供異步解耦、削峯填谷的能力，同時具有海量消息堆積、高吞吐、可靠重試等互聯網應用所需的特性，是阿里巴巴雙11使用的核心產品。

消息隊列 RocketMQ 是阿里雲正式商用的產品，目前在阿里雲多個地域（Region）提供了高可用消息雲服務，單個域內採用多機房部署，可用性極高，即便整個機房都不可用，仍然能夠爲應用提供消息發佈服務，產品穩定性及可用性徹底按照阿里巴巴內部標準來實施，無單點。

消息隊列 RocketMQ 目前提供 TCP 和 HTTP 協議層面的接入方式，支持 Java、C++、 .NET、Go、Python、Nodejs、PHP 這七種編程語言，方便不一樣編程語言開發的應用快速接入消息隊列 RocketMQ 消息雲服務。 用戶能夠將應用部署在阿里雲 ECS、企業自建雲，或者嵌入到移動端、物聯網設備中與消息隊列 RocketMQ 創建鏈接進行消息收發，同時本地開發者也能夠經過公網接入消息隊列 RocketMQ 服務進行消息收發。

產品功能

消息隊列 RocketMQ 提供了基於 TCP 和 HTTP 協議的多種編程語言的接入方式以及多維度的管理工具，同時針對不一樣的應用場景提供了一系列的特點功能。

功能概覽圖

多協議支持

• 支持 HTTP 協議：採用 RESTful 標準，方便易用，快速接入，跨網絡能力強，並支持七種語言客戶端。

• 支持 TCP 協議：區別於 HTTP 簡單的接入方式，提供更爲專業、可靠、穩定的 TCP 協議的 SDK 接入。

• 支持 STOMP 協議：相似於 HTTP 的純文本的協議機制，經常使用於腳本語言（如 Ruby、Python、Perl）和消息隊列 RocketMQ Broker 進行輕量級交互。

管理工具

• Web 控制檯：支持 Topic 管理、生產者管理、消費者管理、消息查詢、消息軌跡展現和查詢、資源報表以及監控報警管理。

• OpenAPI：提供 API 便於將消息隊列 RocketMQ 管理工具集成到本身的控制檯。

• mqadmin 命令集：專有云輸出提供一套豐富的管理命令集，以命令方式對消息隊列 RocketMQ 服務進行管理。

特點功能

• 事務消息：實現相似 X/Open XA 的分佈事務功能，以達到事務最終一致性狀態。

• 定時（延時）消息：容許消息生產者指定消息進行定時（延時）投遞，最長支持 40 天。

• 大消息：支持最大 4 MB 消息。

• 消息軌跡：經過消息軌跡，能清晰定位消息從發佈者發出，經由消息隊列 RocketMQ 服務端，投遞給消息訂閱者的完整鏈路，方便定位排查問題。

• 廣播消費：容許同一個 Group ID 所標識的全部 Consumer 都各自消費某條消息一次。

• 順序消息：容許消息消費者按照消息發送的順序對消息進行消費。

• 重置消費進度：根據時間重置消費進度，容許用戶進行消息回溯或者丟棄堆積消息。

• 死信隊列：將沒法正常消費的消息儲存到特殊的死信隊列供後續處理。

• 全球消息路由：用於全球不一樣地域之間的消息同步複製，保證地域之間的數據一致性。

專有云部署

• 專家定製：提供技術方案設計；專家現場技術支持與培訓。

• 靈活部署：支持專有云獨立部署，同時支持混合雲架構。

• 運維管控：專有云支持 mqadmin 命令集、Open API

• 運維管理工具，方便管控平臺集成以及統一運維。

消息收發模型

消息隊列 RocketMQ 支持「發佈/訂閱」模型，消息發佈者（生產者）能夠將一條消息發送服務端的某個主題（Topic），多個消息接收方（消費者）訂閱這個主題以接收該消息，以下圖所示：

Topic

消息主題，一級消息類型，經過 Topic 對消息進行分類。

Message

消息，消息隊列中信息傳遞的載體。

Message ID

消息的全局惟一標識，由消息隊列 RocketMQ 系統自動生成，惟一標識某條消息。

Message Key

消息的業務標識，由消息生產者（Producer）設置，惟一標識某個業務邏輯。

Tag

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

Producer

消息生產者，也稱爲消息發佈者，負責生產併發送消息。

Producer 實例

Producer 的一個對象實例，不一樣的 Producer 實例能夠運行在不一樣進程內或者不一樣機器上。Producer 實例線程安全，可在同一進程內多線程之間共享。

Consumer

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

Consumer 實例

Consumer 的一個對象實例，不一樣的 Consumer 實例能夠運行在不一樣進程內或者不一樣機器上。一個 Consumer 實例內配置線程池消費消息。

Group

一類 Producer 或 Consumer，這類 Producer 或 Consumer 一般生產或消費同一類消息，且消息發佈或訂閱的邏輯一致。

Group ID

Group 的標識。

Exactly-Once 投遞語義

Exactly-Once 投遞語義是指發送到消息系統的消息只能被消費端處理且僅處理一次，即便生產端重試消息發送致使某消息重複投遞，該消息也在消費端也只被消費一次。

集羣消費

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

廣播消費

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

定時消息

Producer 將消息發送到消息隊列 RocketMQ 服務端，但並不指望這條消息立馬投遞，而是推遲到在當前時間點以後的某一個時間投遞到 Consumer 進行消費，該消息即定時消息。

延時消息

Producer 將消息發送到消息隊列 RocketMQ 服務端，但並不指望這條消息立馬投遞，而是延遲必定時間後才投遞到 Consumer 進行消費，該消息即延時消息。

事務消息

消息隊列 RocketMQ 提供相似 X/Open XA 的分佈事務功能，經過消息隊列 RocketMQ 的事務消息能達到分佈式事務的最終一致。

順序消息

消息隊列 RocketMQ 提供的一種按照順序進行發佈和消費的消息類型, 分爲全局順序消息和分區順序消息。

全局順序消息

對於指定的一個 Topic，全部消息按照嚴格的先入先出（FIFO）的順序進行發佈和消費。

分區順序消息

對於指定的一個 Topic，全部消息根據 sharding key 進行區塊分區。同一個分區內的消息按照嚴格的 FIFO 順序進行發佈和消費。Sharding key 是順序消息中用來區分不一樣分區的關鍵字段，和普通消息的 key 是徹底不一樣的概念。

消息堆積

Producer 已經將消息發送到消息隊列 RocketMQ 的服務端，但因爲 Consumer 消費能力有限，未能在短期內將全部消息正確消費掉，此時在消息隊列 RocketMQ 的服務端保存着未被消費的消息，該狀態即消息堆積。

消息過濾

消費者能夠根據消息標籤（Tag）對消息進行過濾，確保消費者最終只接收被過濾後的消息類型。消息過濾在消息隊列 RocketMQ 的服務端完成。

消息軌跡

在一條消息從生產者發出到訂閱者消費處理過程當中，由各個相關節點的時間、地點等數據匯聚而成的完整鏈路信息。經過消息軌跡，您能清晰定位消息從生產者發出，經由消息隊列 RocketMQ 服務端，投遞給消息消費者的完整鏈路，方便定位排查問題。

重置消費位點

以時間軸爲座標，在消息持久化存儲的時間範圍內（默認 3 天），從新設置消息消費者對其訂閱 Topic 的消費進度，設置完成後訂閱者將接收設定時間點以後由消息生產者發送到消息隊列 RocketMQ 服務端的消息。

死信隊列

死信隊列用於處理沒法被正常消費的消息。當一條消息初次消費失敗，消息隊列 RocketMQ 會自動進行消息重試；達到最大重試次數後，若消費依然失敗，則代表消費者在正常狀況下沒法正確地消費該消息，此時，消息隊列 RocketMQ 不會馬上將消息丟棄，而是將其發送到該消費者對應的特殊隊列中。

消息隊列 RocketMQ 將這種正常狀況下沒法被消費的消息稱爲死信消息（Dead-Letter Message），將存儲死信消息的特殊隊列稱爲死信隊列（Dead-Letter Queue）。

消息路由

消息路由經常使用於不一樣地域之間的消息同步，保證地域之間的數據一致性。消息隊列 RocketMQ 的全球消息路由功能依託阿里雲優質基礎設施實現的高速通道專線，能夠高效地實現國內外不一樣地域之間的消息同步複製。

消息隊列 RocketMQ 在任何一個環境都是可擴展的，發佈者必須是一個集羣，消息服務器必須是一個集羣，訂閱者也一樣。集羣級別的高可用，是消息隊列 RocketMQ 跟其餘的消息服務器的主要區別，消息發佈者（Producer）發送一條消息到消息服務器，消息服務器會隨機的選擇一個消費者（Consumer），只要這個消費者消費成功咱們就認爲是成功了。

注意：文中所說起的消息隊列 RocketMQ 的服務端或者服務器包含 Name Server、Broker 等。服務端不等同於 Broker。

系統部署架構

系統部署架構以下圖所示。

圖中所涉及到的概念以下所述：

• Name Server: 是一個幾乎無狀態節點，可集羣部署，在消息隊列 RocketMQ 中提供命名服務，更新和發現 Broker 服務。

• Broker：分爲 Master Broker 和 Slave Broker，一個 Master Broker 能夠對應多個 Slave Broker，可是一個 Slave Broker 只能對應一個 Master Broker。Broker 啓動後須要完成一次將本身註冊至 Name Server 的操做；隨後每隔 30s 按期向 Name Server 上報 Topic 路由信息。

• Producer：與 Name Server 集羣中的其中一個節點（隨機）創建長連接（Keep-alive），按期從 Name Server 讀取 Topic 路由信息，並向提供 Topic 服務的 Master Broker 創建長連接，且定時向 Master Broker 發送心跳。

• Consumer： 與 Name Server 集羣中的其中一個節點（隨機）創建長鏈接，按期從 Name Server 拉取 Topic 路由信息，並向提供 Topic 服務的 Master Broker、Slave Broker 創建長鏈接，且定時向 Master Broker、Slave Broker 發送心跳。Consumer 既能夠從 Master Broker 訂閱消息，也能夠從 Slave Broker 訂閱消息，訂閱規則由 Broker 配置決定。

訂閱模式

消息隊列 RocketMQ 的訂閱模式採用的是發佈/訂閱模式（Pub/Sub 模式），以下圖所示。

Producer 集羣: 用來表示一個發送消息應用，一個 Producer 集羣下包含多個 Producer 實例，能夠是多臺機器，也能夠是一臺機器的多個進程，或者一個進程的多個 Producer 對象。一個 Producer 集羣能夠發送多個 Topic 消息。能夠想象一下，發送分佈式事物消息時，若是 Producer 中途意外宕機，Broker 會主動回調 Producer 集羣的任意一臺機器來確認事務狀態。

Consumer 集羣：用來表示一個消費消息應用，一個 Consumer 集羣下包含多個 Consumer 實例，能夠是多臺機器，也能夠是多個進程，或者是一個進程的多個 Consumer 對象。一個 Consumer 集羣下的多個 Consumer 以均攤方式消費消息。若是設置的是廣播方式，那麼這個 Consumer 集羣下的每一個實例都消費全量數據。

一個 Consumer 對應一個 Group ID，一個 Group ID 能夠訂閱多個 Topic，如圖中的 Group 1 所示。Group 和 Topic 的訂閱關係能夠經過直接在程序中設置便可。

note:今天你是否成功取決於你昨天的態度，今天的態度決定了你明天是否成功。