*作者：* *周新宇&陳濤&李凱*

阿里雲 RocketMQ 輕量版（MNS）訊息佇列是一個輕量、可靠、可擴充套件且完全託管的分散式訊息佇列服務。MNS 能夠幫助應用開發者在他們應用的分散式元件上更輕量的傳遞資料、通知訊息，構建松耦合系統。無需管理開銷，而且模型簡單，拆箱即用，自動橫向擴容，無需管理分割槽等複雜的邏輯運維，是一款 Serverless 訊息佇列產品。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f1858b678472459e98fc79d4e15876ad~tplv-k3u1fbpfcp-zoom-1.image "1.png")

MNS 重點聚焦在基準訊息佇列的核心能力建設，MNS 經過多年迭代與打磨，儘管內部極為複雜，但一直努力保持其在客戶端的簡單易用，圍繞輕量和整合兩個命題，著力建設更易用的訊息佇列產品。

## 核心優勢

MNS 圍繞輕量訊息佇列，提供一系列的輕量級能力。為企業和開發者降低訊息產品的複雜度，減少運維開銷，提供更易上手的訊息佇列服務。

### 輕量模型

MNS 提供 1:1 和 1:N 兩種輕量模型，可根據場景自行選擇需要的模型方式，學習成本低，上手快。無需理解複雜的概念模型，無需刻意學習，幾分鐘即可快速上手。

MNS 模型輕量主要體現在資源的操作方面，建立和刪除等都配置有極簡的 API，同時與資料鏈路的 API 屬於同一個 SDK，方便使用者像收發訊息那樣進行資源的建立。相反，很多雲產品資源的 API 都採用了新的管控 SDK，使用門檻較高。

此外，MNS 的模型和資源是一一對應的，比如使用佇列模型僅需要建立一個 Queue，非常易於上手和使用，而其他一些同型別產品，對於同一個模型會有例項、主題、佇列、分割槽等多個資源。

### 輕量協議

採用 HTTP RESTful 標準協議，接入方便，跨網路能力強，天然擁有支援多語言訪問的能力。官方 SDK 覆蓋各大主流語言，包括 C++，C#，.Net，Python，PHP 和 Java，社群貢獻也有用 Go，Node 等 。

同時訪問協議簡單通用，即使不想依賴雲產品提供 SDK ，也可以很容易透過簡單的編碼來訪問 API，接入成本低，開發效率高。

### 輕量計費

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/20a7a5448c7844389ad6e6b73813eb39~tplv-k3u1fbpfcp-zoom-1.image "2.png")

MNS 是 Serverless 輕量計費，相較於按照例項付費，MNS 提供更加輕量的 Serverless 計費方式。按照請求量和資源佔用情況付費，用多少付多少，無需為額外預留資源買單；同時提供每個月擁有 2000 萬次 API 免費呼叫額度。這種完全後付費的定價方式可以為企業節約大量閒置資源。

### 輕量運維

MNS 可以根據應用情況進行彈性擴充套件，因此，無需擔心容量規劃和預配置。每個佇列的訊息數量不限，而且標準佇列能提供幾乎無限的吞吐量（QPS 範圍內）；提供 Serverless 化彈性 服務，高效快捷，無需對資源做預留，隨取隨用，實時擴縮；更適合產品整合與瞬時佇列場景。

同時 MNS 提供完善的訊息監控訊息告警等能力，支援高可靠性和高穩定性，消除管理和運維時的複雜性和研發開銷。

## 基本模型

MNS 是一個融合了點對點（P2P）和釋出訂閱（Pub/Sub）兩種消費模型的消費系統，其中 MNS 的「佇列」是 P2P 消費模型的實現，「主題」是 Pub/Sub 消費模型的實現。

MNS 也是業界鮮有的同時提供兩種混合消費模型的雲產品，使用者可以透過「佇列」或者「主題」來實現大部分對訊息系統的需求。

### 佇列（P2P 模型）

佇列模型提供高可靠、高併發的一對一消費模型，即佇列中的每一條訊息都只能夠被某一個消費者消費。佇列就像一家旋轉壽司店。壽司店中有多個壽司師傅（生產者）在製作精美的壽司，每一份壽司都是獨特的，顧客（消費者）可以從傳送帶上拿取中意的壽司進行食用（消費）。

佇列是 MNS 的頂級資源，也是訊息的儲存實體，有完整的阿里雲資源的生命週期，以及完善的許可權控制機制。圍繞佇列有三個核心概念：

-   生產者（Producer）：生產者負責將訊息傳送到指定的佇列上，一個佇列接受分散式的生產者併發投遞訊息。

-   佇列（Queue）：佇列模型對應的物理資源，也是訊息的儲存實體，MNS 透過一個分散式的儲存叢集來提供佇列的分散式儲存能力。

-   消費者（Consumer）：消費者負責從指定的佇列透過輪詢的機制獲取訊息，一個佇列接受分散式的消費者併發地消費訊息，同時保證同一條訊息在可見時間內只會被一個消費者消費。

### 主題（Pub/Sub 模型）

主題模型提供一對多的釋出訂閱模型，支援訊息通知。主題就像一份報紙，多個讀者到郵局訂閱了這份報紙。當報紙推出最新一期時，讀者（包括郵局的合作伙伴）可以選擇以下方式來獲取：

-   讓郵局投遞員將報紙都投遞（推送）到家裡（特定的地址）。

-   去就近的報刊亭（訂閱點）自行獲取報紙（報紙會先被郵局投遞員集中送到各個報刊亭）。

主題是 MNS 的另一個頂級資源，其也具備訊息的儲存能力，對應的 Topic 資源具備完整的阿里雲資源的生命週期，以及完善的許可權控制機制。圍繞主題也有三個核心概念：

-   生產者（Producer）：生產者除了可以把訊息傳送至佇列，也可以把訊息傳送到主題上，主題也接受分散式的生產者併發投遞訊息。

-   主題（Topic）：主題模型對應的物理資源同樣具備訊息的儲存能力。

-   訂閱（Subscription）：可以為每個主題建立多個訂閱，每個訂閱將收到 Topic 上的完整訊息，訂閱的下游可以是多種型別的訂閱者，使用者往往透過訂閱的能力將主題中的訊息扇出至多個佇列。

## 功能特性

MNS 作為一款成熟的訊息產品，面向主題和佇列提供了多種功能特性，能夠深入到應用的架構當中，幫助使用者降低業務流程開發的複雜度，讓業務專注於業務邏輯的開發。比如多種訊息型別的支援，方便使用者快速實現定時、優先順序相關的業務邏輯。

### 多種訊息型別的支援

MNS 佇列支援普通訊息、延遲訊息、優先訊息這 3 種訊息型別。

普通訊息是最基礎的訊息型別，當一條普通訊息傳送到了 MNS 之後，這一條訊息就會在佇列中等待使用者的拉取進行訊息的消費。

對於延遲訊息，使用者可以在傳送的時候指定期望這條訊息的延遲時間，當到了設定的延遲時間後，那麼就可以消費到這條訊息。同時，在傳送了延遲訊息之後，除了可以獲取到訊息的一些基本屬性之外，還可以獲取到一個訊息控制程式碼，當期望提前取消掉這條延遲訊息的時候，我們可以使用這個訊息控制程式碼進行 Delete。Delete 過後，這條訊息就不會再投遞出來。透過延遲訊息，使用者可以輕鬆的實現一個分散式的延遲排程系統，在擁有高精度延遲的同時，實現超高的可擴充套件性和可用性。

對於優先訊息，我們在傳送訊息的時候可以指定訊息的優先順序，優先順序的取值範圍為 1 到 16。優先順序的取值越小，那麼這條訊息的優先順序就越高。需要注意的是，優先訊息並不保證訊息的順序性，優先順序越高的訊息擁有更容易被消費的可能性，並不意味著優先順序低的訊息一定會在優先順序高的訊息消費完成之後才能夠被消費。

### 高效的長輪訓機制

對於 訊息佇列 MNS 來說 ，使用者需要主動進行訊息的拉取，如果拉取的頻率過低，那麼就會導致訊息的延遲；相對應的，如果拉取的頻率過高，那麼又會帶來過多無效的API呼叫。

為解決這個問題，MNS 佇列提供了長輪訓的機制，可以在一定程度上減少無效 API 的呼叫，同時保證訊息的及時性。當使用者拉取訊息的時候，可以設定這次請求拉取訊息的 waitseconds，客戶端則會以設定的時間掛一個長輪訓請求到服務端。如果在長輪訓期間發現有訊息可以被消費，就會立即返回；如果沒有，就會最多等待長輪訓時間結束之後返回。但需要注意的是，雖然我們可以使用長輪訓來減少無效的 API 呼叫，但整體上還是需要一定的訊息拉取的併發度，以保證訊息的及時性。

### 靈活的訊息生命週期管理

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8b8abdf91d6544cdbb2f73059085a6eb~tplv-k3u1fbpfcp-zoom-1.image "3.png")

對於佇列中的一條訊息，其會具有可見、不可見、刪除這 3 種狀態。當訊息傳送到佇列中後，這條訊息就處於可見的狀態，等待消費者來拉取。當訊息被消費者拉取出來之後，訊息會進入一段“不可見時間”，在這段“不可見時間”裡面，這條訊息是不會被再次的拉取出來。但如果在“不可見時間”裡面這條訊息沒有被刪除，那麼這一條訊息就會再次的可見，並可以被消費者再一次的從佇列中拉取出來。

除此之外，當有消費者消費到訊息，在處理的過程中突然出現問題，例如當機，那麼這一條訊息則會在“不可見時間”結束之後再一次的可見，可以被其他的消費者再次消費到。

這裡可能就存在一個矛盾點，使用者可能期望有消費者當機之後，沒有被正確處理的訊息能夠儘快的由其他消費者消費下去，但又由於本身的業務處理時間可能有時候較長，可能會超過佇列上所配置的預設的“不可見時間”，導致訊息的重複消費。那麼，為解決這種場景，MNS 也為使用者提供了可以在訊息維度修改某一條訊息的“不可見時間”功能。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/03506b8eef8848b78c72fb2df7d9daf2~tplv-k3u1fbpfcp-zoom-1.image "4.png")

當使用者收到了一條訊息，發現這條訊息處理的時間較長會超過佇列所配置的“不可見時間”的時候，使用者可以透過訊息的控制程式碼主動呼叫，修改這一條訊息的不可見時間。例如上圖，將這一條訊息的不可見時間進行了延長，留給了業務更多的處理時間。當然，同之前的訊息消費一樣，當這條訊息處理完成之後，也需要呼叫刪除訊息的介面，進行訊息消費成功的確認。

### 訊息多訂閱推送

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cceba3c7f0ef46bc989cc9a167b570c5~tplv-k3u1fbpfcp-zoom-1.image "5.png")

MNS 主題提供了一對多廣播訊息的能力，我們可以為一個主題建立多個訂閱，路由到不同的 Endpoint。使用者只需要將訊息傳送到主題，就可以將這個一條訊息推送到多個訂閱中去。

其次，在一對多廣播訊息的能力的基礎上，在訂閱中，MNS 還支援訂閱帶有特定標籤的訊息。我們在建立訂閱的時候可以指定這個訂閱所關心的訊息的 Tag，這樣當 MNS 進行訊息推送的時候，就會自動進行訊息的過濾，僅將這個訂閱所關心的 Tag 推送出去。

為了保證訊息投遞的可靠性，使用者可以對每個訂閱配置推送策略，可以指定使用退避重試策略或者指數衰減重試的策略。

對於退避重試策略，當訊息推送失敗的時候，會重試 3 次，每一次的重試間隔時間為 10 到 20 秒的隨機值。對於指數衰減重試，整體的重試時間為 1 天，每次的重試時間間隔是指數遞增的（1 秒，2 秒，4 秒，8 秒，...）。

最後，我們還可以配置推送的訊息的格式，我們可以在建立訂閱的時候，指定推送格式為 XML、JSON 或者 SIMPLIFIED。對於 XML 和 JSON，推送給訂閱的訊息內容，除了會包含傳送到主題的訊息之外，還會新增例如 MessageID、TopicName、SubscriptionName 等屬性。而對於 SIMPLIFIED，則是直接將傳送到主題的訊息進行轉發，不會新增額外的屬性。

## 接入協議

MNS 以 HTTP 協議對外提供服務，包含近 30 個 RESTful 的 API，但核心業務場景往往使用 3 個左右的 API 就可以完成研發，非常易於上手。

另外，使用者既可以直接根據 API 進行自行的封裝，也可以直接使用官方所提供的的 SDK 進行整合。使用者僅只需要依賴一個 SDK 就可以完成從服務的開通、資源的建立、再到訊息的收發。

在多語言 SDK 方面，MNS 提供了 8 種主流語言的 SDK，包括 Java、Python、C#、Node、PHP、C++、Go 等，同時也支援採用 Java 領域標準的 JMS SDK 接入 MNS。

## 適用場景解析

相較於 RabbitMQ，ActiveMQ，Kafka 等開源訊息佇列，RocketMQ 輕量版 MNS 摒棄了非常複雜的概念模型及臃腫繁多的協議，透過簡單模型，通用的 HTTP RESTful 標準協議即可高效完成訊息領域的典型場景。提供完全免運維的訊息整合方案，顯著降低開發和維護成本，提升新業務開發效率。

### 訊息廣播（Fanout）場景解析

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b8dd124bfdaf420199fc1d41ae87be6e~tplv-k3u1fbpfcp-zoom-1.image "6.png")

-   **背景資訊**

輕量訊息佇列 MNS 提供佇列（Queue）和主題（Topic）兩種模型，基本能滿足大多數應用場景。佇列提供的是一對一的共享訊息消費模型，採用客戶端主動拉取（Pull）模式。

主題模型提供一對多的廣播訊息消費模型，採用服務端主動推送（Push）模式。

推送模式的好處是即時效能較好，但需暴露客戶端地址來接收服務端的訊息推送。有些情況下有的資訊，例如企業內網，無法暴露推送地址，希望改用拉取（Pull）的方式。雖然訊息服務 MNS 不直接提供這種消費模型，但可以結合主題和佇列來實現一對多的拉取訊息消費模型。

-   **解決方案**

透過建立訂閱，讓主題將訊息先推送到佇列，然後由消費者從佇列拉取訊息。這樣既可以做到一對多的廣播訊息，又可避免暴露消費者的地址。

### 超大訊息傳輸（Claim Check）場景解析

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/85ecaa6ed23b412bbf616437adfaa388~tplv-k3u1fbpfcp-zoom-1.image "7.png")

-   **背景資訊**

訊息服務 MNS 的佇列的訊息大小最大限制是 64 KB，這個限制基本能夠滿足在正常情況下訊息作為控制流資訊交換通道的需求。但是，在某些特殊場景下，訊息資料比較大時，就只能採用訊息切片的方式。

下面是不做訊息切片，透過 OSS 來實現傳遞大於 64 KB 的訊息的解決方案。

-   **解決方案**

生產者在向訊息服務 MNS 傳送訊息前，如果發現訊息體大於 64 KB，則先將訊息體資料上傳到 OSS。

生產者把資料對應的 Object 資訊傳送到訊息服務 MNS。

消費者從訊息服務 MNS 佇列裡讀取訊息，判斷訊息內容是否為 OSS 的 Object 資訊。

判斷訊息內容是 OSS 的 Object 資訊，則從 OSS 下載對應的 Object 內容，並作為訊息體返回給上層程式。

### 簡單事務訊息場景解析

背景資訊：一些業務場景需要保證本地操作和訊息傳送的事務一致性，即訊息傳送成功，本地操作成功。如果訊息傳送成功，本地操作失敗，那麼傳送成功的訊息需要回滾。操作流程如圖所示：

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/91911a15905a45cb877c97b719de5a71~tplv-k3u1fbpfcp-zoom-1.image "8.png")

-   **解決方案**

訊息傳送成功，事務操作成功時操作步驟如下所示：

-   生產者傳送一條事務準備訊息到事務訊息佇列；
-   生產者傳送操作日誌訊息到操作日誌佇列，日誌中包含步驟1訊息的訊息控制程式碼；
-   生產者執行本地事務操作成功；
-   生產者請求修改訊息延遲時間，使訊息對消費者可見；
-   生產者向操作日誌佇列確認操作日誌，刪除日誌訊息；
-   消費者從事務訊息佇列中接收事務訊息；
-   消費者處理事務訊息；
-   消費者請求刪除事務訊息。

### 訊息過濾（Message Filter） 場景解析

-   **背景資訊**

一些場景中需要根據訊息內容把訊息推送到不同的推送目標，為了達到這一功能，您可以建立多個主題，併為每個主題設定相應的推送目標，但是這樣會增加額外的成本，並且增加了運維的複雜度。為了避免這種情況，訊息佇列 MNS 提供了訊息過濾標籤功能。您可以只建立一個主題，並在建立訂閱時設定不同的訊息過濾標籤，結合訊息的訊息過濾標籤，MNS 就可以把訊息推送到不同的推送目標中。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0735f5463d2e48d191e75c89d544840e~tplv-k3u1fbpfcp-zoom-1.image "9.png")

-   **解決方案**

圖示例場景中，在主題 Topic 1 建立 3 個訊息過濾標籤不同的訂閱，Subscription 1、Subscription 2 和 Subscription 3。這 3 個訂閱的推送目標分別是 Queue 1、Queue 2 和 Queue 3。

-   訊息的訊息過濾標籤和訂閱的訊息過濾標籤一致。訊息過濾過程如下：

訊息服務 MNS 將 Message 1 推送到佇列 Queue 1；

訊息服務 MNS 將 Message 2 推送到佇列 Queue 2。

-   訂閱沒有訊息過濾標籤。訊息過濾過程如下：

訊息服務 MNS 將 Message 1推送到佇列 Queue 3；

訊息服務 MNS 將 Message 2 推送到佇列 Queue 3；

訊息服務 MNS 將 Message 3 推送到佇列 Queue 3。

## 客戶案例及最佳實踐

### 線上交易 - 應用解耦 - 削峰填谷（典型場景 ）

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/97d16c1ebc1a447f9238aca70b94218f~tplv-k3u1fbpfcp-zoom-1.image "10.png")

-   **場景描述**

淘寶/天貓主站最為核心的系統是交易系統，每一筆交易訂單資料都會有幾百個下游業務系統的關聯，包括物流、購物車、積分、直充、阿里媽媽、流計算分析等，整個系統龐大而且複雜，架構設計稍有不合理，將直接影響主站業務的連續性。

-   **非同步解耦**

如此複雜且龐大的系統，若上、下游業務系統緊耦合，那麼任意一個子系統不可用都將直接導致核心交易系統不可用；

透過訊息佇列實現上、下游業務系統松耦合，那麼，即便下游子系統（如物流系統）出現不可用，也不會影響到核心交易系統的正常運轉；

-   **削峰填谷**

透過訊息佇列不僅可以起到系統間解耦的作用，更能在大促、秒殺等大型活動中起到削峰填谷的作用。

每年天貓雙11凌晨，保證核心交易系統的業務處理能力始終為重中之重，每秒數十萬筆的交易訂單處理能力，且逐年線性增長；然而相對的，各大物流系統、銀行的支付系統的業務處理能力卻有限，若不能進行流量緩衝將直接引發這些系統的崩潰。因此，利用訊息佇列強大的訊息堆積能力則可以很好的起到削峰填谷的作用，將系統壓力全部轉移到訊息佇列，從而釋放物流、支付等系統的壓力，保證業務的正常運轉。

### 直播錄製 - 合流 - 轉碼（Serverless 場景 ）

場景描述：影片的直播錄製，合流，轉碼是線上教育和線上直播領域的剛需場景，透過 MNS 可以對 FC Serverless 資源進行線上排程，幫助客戶實現非同步直播流錄製，合流轉碼等複雜場景。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4d62ce76900b42a5bbb7443c34b67042~tplv-k3u1fbpfcp-zoom-1.image "11.png")

### 線上遊戲場景

-   **場景描述**

遊戲場景存在大量強互動場景的資料流轉，對訊息中介軟體的穩定性和端到端延遲要求極高，自建訊息中介軟體壓力大、不穩定。遊戲場景存在大量的指令傳輸以及定時任務，自建邏輯無法解決熱點問題。

透過 MNS 可以實現從遊戲閘道器指令到後臺訊息協議的轉換，同時 MNS 也支援後臺邏輯服、工會、戰鬥服之間的非同步解耦拆分。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/91df189c90fe475eb9a5fb47b583b0d3~tplv-k3u1fbpfcp-zoom-1.image "12.png")

## 總結

MNS 圍繞輕量訊息佇列，提供一系列的輕量級能力。為企業和開發者降低訊息產品的複雜度，減少運維開銷，提供更易上手的訊息佇列服務。

作為阿里雲 RocketMQ 的輕量版，填補了 RocketMQ 在輕量化和易用性的不足。儘管 MNS 版本伴隨 RocketMQ 經過多年迭代與打磨，內部極為複雜，但一直努力保持其在客戶端的簡單易用。為企業和開發者降低訊息產品的複雜度，減少運維開銷提供更易上手的訊息佇列服務，是 MNS 的產品使命和願景。

***

## MNS 產品訓練營活動火熱報名中

為了幫助大家由淺入深的對阿里雲訊息佇列 MNS 有更加全面的瞭解，同時期望訊息佇列 MNS 能夠幫助大家解決日常工作和生產的問題，特推出訊息佇列 MNS 產品訓練營課程，課程中不僅有對產品簡單形象的介紹，還有“首秀”的動手實踐學習課程。

參與本次訊息佇列 MNS 訓練營，您可以學習並收穫到：

-   訊息佇列 MNS 的基礎概念及特性
-   訊息佇列 MNS 的最佳實踐及案例
-   基於 MNS，0 基礎輕鬆構建 Web Client

除了學習層面的收穫，活動期間，完成所有參營任務且考試透過的前 20 名同學可獲得（若成績相同按考試時間順序排名），即可免費獲得小米充電寶。活動時間：8 月 10 日 - 8 月 31 日（工作日期間）。

點選[此處](https://developer.aliyun.com/trainingcamp/1091392f83464404a407920226a9df17)，立即報名吧～

厚積薄發--一文帶您瞭解阿里雲 RocketMQ 輕量版訊息佇列（MNS）

相關文章