作者：周新宇、陳濤、李凱

 阿里云 RocketMQ 輕量版（MNS）消息隊(duì)列是一個(gè)輕量、可靠、可擴(kuò)展且完全托管的分布式消息隊(duì)列服務(wù)。MNS 能夠幫助應(yīng)用開發(fā)者在他們應(yīng)用的分布式組件上更輕量的傳遞數(shù)據(jù)、通知消息，構(gòu)建松耦合系統(tǒng)。無需管理開銷，而且模型簡單，拆箱即用，自動(dòng)橫向擴(kuò)容，無需管理分區(qū)等復(fù)雜的邏輯運(yùn)維，是一款 Serverless 消息隊(duì)列產(chǎn)品。

MNS 重點(diǎn)聚焦在基準(zhǔn)消息隊(duì)列的核心能力建設(shè)，MNS 經(jīng)過多年迭代與打磨，盡管內(nèi)部極為復(fù)雜，但一直努力保持其在客戶端的簡單易用，圍繞輕量和集成兩個(gè)命題，著力建設(shè)更易用的消息隊(duì)列產(chǎn)品。

核心優(yōu)勢(shì)

MNS 圍繞輕量消息隊(duì)列，提供一系列的輕量級(jí)能力。為企業(yè)和開發(fā)者降低消息產(chǎn)品的復(fù)雜度，減少運(yùn)維開銷，提供更易上手的消息隊(duì)列服務(wù)。

輕量模型

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

MNS 模型輕量主要體現(xiàn)在資源的操作方面，創(chuàng)建和刪除等都配置有極簡的 API，同時(shí)與數(shù)據(jù)鏈路的 API 屬于同一個(gè) SDK，方便用戶像收發(fā)消息那樣進(jìn)行資源的創(chuàng)建。相反，很多云產(chǎn)品資源的 API 都采用了新的管控 SDK，使用門檻較高。

此外，MNS 的模型和資源是一一對(duì)應(yīng)的，比如使用隊(duì)列模型僅需要?jiǎng)?chuàng)建一個(gè) Queue，非常易于上手和使用，而其他一些同類型產(chǎn)品，對(duì)于同一個(gè)模型會(huì)有實(shí)例、主題、隊(duì)列、分區(qū)等多個(gè)資源。

輕量協(xié)議

采用 HTTP RESTful 標(biāo)準(zhǔn)協(xié)議，接入方便，跨網(wǎng)絡(luò)能力強(qiáng)，天然擁有支持多語言訪問的能力。官方 SDK 覆蓋各大主流語言，包括C++，C#，.Net，Python，PHP 和 Java，社區(qū)貢獻(xiàn)也有用 Go，Node等 。

同時(shí)訪問協(xié)議簡單通用，即使不想依賴云產(chǎn)品提供SDK ，也可以很容易通過簡單的編碼來訪問 API，接入成本低，開發(fā)效率高。

輕量計(jì)費(fèi)

MNS是Serverless輕量計(jì)費(fèi)，相較于按照實(shí)例付費(fèi)，MNS 提供更加輕量的Serverless 計(jì)費(fèi)方式。按照請(qǐng)求量和資源占用情況付費(fèi)，用多少付多少，無需為額外預(yù)留資源買單；同時(shí)提供每個(gè)月?lián)碛?2000 萬次 API 免費(fèi)調(diào)用額度。這種完全后付費(fèi)的定價(jià)方式可以為企業(yè)節(jié)約大量閑置資源。

輕量運(yùn)維

MNS 可以根據(jù)應(yīng)用情況進(jìn)行彈性擴(kuò)展，因此，無需擔(dān)心容量規(guī)劃和預(yù)配置。每個(gè)隊(duì)列的消息數(shù)量不限，而且標(biāo)準(zhǔn)隊(duì)列能提供幾乎無限的吞吐量（QPS 范圍內(nèi)）；提供 Serverless 化彈性服務(wù)，高效快捷，無需對(duì)資源做預(yù)留，隨取隨用，實(shí)時(shí)擴(kuò)縮；更適合產(chǎn)品集成與瞬時(shí)隊(duì)列場景。

同時(shí)MNS提供完善的消息監(jiān)控消息告警等能力，支持高可靠性和高穩(wěn)定性，消除管理和運(yùn)維時(shí)的復(fù)雜性和研發(fā)開銷。

基本模型

MNS 是一個(gè)融合了點(diǎn)對(duì)點(diǎn)（P2P）和發(fā)布訂閱（Pub/Sub）兩種消費(fèi)模型的消費(fèi)系統(tǒng)，其中 MNS 的「隊(duì)列」是 P2P 消費(fèi)模型的實(shí)現(xiàn)，「主題」是 Pub/Sub 消費(fèi)模型的實(shí)現(xiàn)。

MNS 也是業(yè)界鮮有的同時(shí)提供兩種混合消費(fèi)模型的云產(chǎn)品，用戶可以通過「隊(duì)列」或者「主題」來實(shí)現(xiàn)大部分對(duì)消息系統(tǒng)的需求。

隊(duì)列（P2P 模型）

隊(duì)列模型提供高可靠、高并發(fā)的一對(duì)一消費(fèi)模型，即隊(duì)列中的每一條消息都只能夠被某一個(gè)消費(fèi)者消費(fèi)。隊(duì)列就像一家旋轉(zhuǎn)壽司店。壽司店中有多個(gè)壽司師傅（生產(chǎn)者）在制作精美的壽司，每一份壽司都是獨(dú)特的，顧客（消費(fèi)者）可以從傳送帶上拿取中意的壽司進(jìn)行食用（消費(fèi)）。

隊(duì)列是 MNS 的頂級(jí)資源，也是消息的存儲(chǔ)實(shí)體，有完整的阿里云資源的生命周期，以及完善的權(quán)限控制機(jī)制。圍繞隊(duì)列有三個(gè)核心概念：

• 生產(chǎn)者（Producer）：生產(chǎn)者負(fù)責(zé)將消息發(fā)送到指定的隊(duì)列上，一個(gè)隊(duì)列接受分布式的生產(chǎn)者并發(fā)投遞消息。
• 隊(duì)列（Queue）：隊(duì)列模型對(duì)應(yīng)的物理資源，也是消息的存儲(chǔ)實(shí)體，MNS 通過一個(gè)分布式的存儲(chǔ)集群來提供隊(duì)列的分布式存儲(chǔ)能力。
• 消費(fèi)者（Consumer）：消費(fèi)者負(fù)責(zé)從指定的隊(duì)列通過輪詢的機(jī)制獲取消息，一個(gè)隊(duì)列接受分布式的消費(fèi)者并發(fā)地消費(fèi)消息，同時(shí)保證同一條消息在可見時(shí)間內(nèi)只會(huì)被一個(gè)消費(fèi)者消費(fèi)。

主題（Pub/Sub 模型）

主題模型提供一對(duì)多的發(fā)布訂閱模型，支持消息通知。主題就像一份報(bào)紙，多個(gè)讀者到郵局訂閱了這份報(bào)紙。當(dāng)報(bào)紙推出最新一期時(shí)，讀者（包括郵局的合作伙伴）可以選擇以下方式來獲?。?/span>

• 讓郵局投遞員將報(bào)紙都投遞（推送）到家里（特定的地址）。
• 去就近的報(bào)刊亭（訂閱點(diǎn)）自行獲取報(bào)紙（報(bào)紙會(huì)先被郵局投遞員集中送到各個(gè)報(bào)刊亭）。

主題是 MNS 的另一個(gè)頂級(jí)資源，其也具備消息的存儲(chǔ)能力，對(duì)應(yīng)的 Topic 資源具備完整的阿里云資源的生命周期，以及完善的權(quán)限控制機(jī)制。圍繞主題也有三個(gè)核心概念：

• 生產(chǎn)者（Producer）：生產(chǎn)者除了可以把消息發(fā)送至隊(duì)列，也可以把消息發(fā)送到主題上，主題也接受分布式的生產(chǎn)者并發(fā)投遞消息。
• 主題（Topic）：主題模型對(duì)應(yīng)的物理資源同樣具備消息的存儲(chǔ)能力。
• 訂閱（Subscription）：可以為每個(gè)主題創(chuàng)建多個(gè)訂閱，每個(gè)訂閱將收到 Topic 上的完整消息，訂閱的下游可以是多種類型的訂閱者，用戶往往通過訂閱的能力將主題中的消息扇出至多個(gè)隊(duì)列。

功能特性

MNS 作為一款成熟的消息產(chǎn)品，面向主題和隊(duì)列提供了多種功能特性，能夠深入到應(yīng)用的架構(gòu)當(dāng)中，幫助用戶降低業(yè)務(wù)流程開發(fā)的復(fù)雜度，讓業(yè)務(wù)專注于業(yè)務(wù)邏輯的開發(fā)。比如多種消息類型的支持，方便用戶快速實(shí)現(xiàn)定時(shí)、優(yōu)先級(jí)相關(guān)的業(yè)務(wù)邏輯。

多種消息類型的支持

MNS 隊(duì)列支持普通消息、延遲消息、優(yōu)先消息這3種消息類型。

普通消息是最基礎(chǔ)的消息類型，當(dāng)一條普通消息發(fā)送到了MNS之后，這一條消息就會(huì)在隊(duì)列中等待用戶的拉取進(jìn)行消息的消費(fèi)。

對(duì)于延遲消息，用戶可以在發(fā)送的時(shí)候指定期望這條消息的延遲時(shí)間，當(dāng)?shù)搅嗽O(shè)定的延遲時(shí)間后，那么就可以消費(fèi)到這條消息。同時(shí)，在發(fā)送了延遲消息之后，除了可以獲取到消息的一些基本屬性之外，還可以獲取到一個(gè)消息句柄，當(dāng)期望提前取消掉這條延遲消息的時(shí)候，我們可以使用這個(gè)消息句柄進(jìn)行Delete。Delete過后，這條消息就不會(huì)再投遞出來。通過延遲消息，用戶可以輕松的實(shí)現(xiàn)一個(gè)分布式的延遲調(diào)度系統(tǒng)，在擁有高精度延遲的同時(shí)，實(shí)現(xiàn)超高的可擴(kuò)展性和可用性。 

對(duì)于優(yōu)先消息，我們?cè)诎l(fā)送消息的時(shí)候可以指定消息的優(yōu)先級(jí)，優(yōu)先級(jí)的取值范圍為1到16。優(yōu)先級(jí)的取值越小，那么這條消息的優(yōu)先級(jí)就越高。需要注意的是，優(yōu)先消息并不保證消息的順序性，優(yōu)先級(jí)越高的消息擁有更容易被消費(fèi)的可能性，并不意味著優(yōu)先級(jí)低的消息一定會(huì)在優(yōu)先級(jí)高的消息消費(fèi)完成之后才能夠被消費(fèi)。

高效的長輪訓(xùn)機(jī)制

對(duì)于 消息隊(duì)列MNS來說 ，用戶需要主動(dòng)進(jìn)行消息的拉取，如果拉取的頻率過低，那么就會(huì)導(dǎo)致消息的延遲；相對(duì)應(yīng)的，如果拉取的頻率過高，那么又會(huì)帶來過多無效的API調(diào)用。

為解決這個(gè)問題，MNS 隊(duì)列提供了長輪訓(xùn)的機(jī)制，可以在一定程度上減少無效API的調(diào)用，同時(shí)保證消息的及時(shí)性。當(dāng)用戶拉取消息的時(shí)候，可以設(shè)置這次請(qǐng)求拉取消息的waitseconds，客戶端則會(huì)以設(shè)置的時(shí)間掛一個(gè)長輪訓(xùn)請(qǐng)求到服務(wù)端。如果在長輪訓(xùn)期間發(fā)現(xiàn)有消息可以被消費(fèi)，就會(huì)立即返回；如果沒有，就會(huì)最多等待長輪訓(xùn)時(shí)間結(jié)束之后返回。但需要注意的是，雖然我們可以使用長輪訓(xùn)來減少無效的API調(diào)用，但整體上還是需要一定的消息拉取的并發(fā)度，以保證消息的及時(shí)性。

靈活的消息生命周期管理

對(duì)于隊(duì)列中的一條消息，其會(huì)具有可見、不可見、刪除這3狀態(tài)。當(dāng)消息發(fā)送到隊(duì)列中后，這條消息就處于可見的狀態(tài)，等待消費(fèi)者來拉取。當(dāng)消息被消費(fèi)者拉取出來之后，消息會(huì)進(jìn)入一段“不可見時(shí)間”，在這段“不可見時(shí)間”里面，這條消息是不會(huì)被再次的拉取出來。但如果在“不可見時(shí)間”里面這條消息沒有被刪除，那么這一條消息就會(huì)再次的可見，并可以被消費(fèi)者再一次的從隊(duì)列中拉取出來。

除此之外，當(dāng)有消費(fèi)者消費(fèi)到消息，在處理的過程中突然出現(xiàn)問題，例如宕機(jī)，那么這一條消息則會(huì)在“不可見時(shí)間”結(jié)束之后再一次的可見，可以被其他的消費(fèi)者再次消費(fèi)到。

這里可能就存在一個(gè)矛盾點(diǎn)，用戶可能期望有消費(fèi)者宕機(jī)之后，沒有被正確處理的消息能夠盡快的由其他消費(fèi)者消費(fèi)下去，但又由于本身的業(yè)務(wù)處理時(shí)間可能有時(shí)候較長，可能會(huì)超過隊(duì)列上所配置的默認(rèn)的“不可見時(shí)間”，導(dǎo)致消息的重復(fù)消費(fèi)。那么，為解決這種場景，MNS也為用戶提供了可以在消息維度修改某一條消息的“不可見時(shí)間”功能。

當(dāng)用戶收到了一條消息，發(fā)現(xiàn)這條消息處理的時(shí)間較長會(huì)超過隊(duì)列所配置的“不可見時(shí)間”的時(shí)候，用戶可以通過消息的句柄主動(dòng)調(diào)用，修改這一條消息的不可見時(shí)間。例如上圖，將這一條消息的不可見時(shí)間進(jìn)行了延長，留給了業(yè)務(wù)更多的處理時(shí)間。當(dāng)然，同之前的消息消費(fèi)一樣，當(dāng)這條消息處理完成之后，也需要調(diào)用刪除消息的接口，進(jìn)行消息消費(fèi)成功的確認(rèn)。

消息多訂閱推送

MNS主題提供了一對(duì)多廣播消息的能力，我們可以為一個(gè)主題創(chuàng)建多個(gè)訂閱，路由到不同的Endpoint。用戶只需要將消息發(fā)送到主題，就可以將這個(gè)一條消息推送到多個(gè)訂閱中去。

其次，在一對(duì)多廣播消息的能力的基礎(chǔ)上，在訂閱中，MNS還支持訂閱帶有特定標(biāo)簽的消息。我們?cè)趧?chuàng)建訂閱的時(shí)候可以指定這個(gè)訂閱所關(guān)心的消息的Tag，這樣當(dāng)MNS進(jìn)行消息推送的時(shí)候，就會(huì)自動(dòng)進(jìn)行消息的過濾，僅將這個(gè)訂閱所關(guān)心的Tag推送出去。

為了保證消息投遞的可靠性，用戶可以對(duì)每個(gè)訂閱配置推送策略，可以指定使用退避重試策略或者指數(shù)衰減重試的策略。

對(duì)于退避重試策略，當(dāng)消息推送失敗的時(shí)候，會(huì)重試3次，每一次的重試間隔時(shí)間為10到20秒的隨機(jī)值。對(duì)于指數(shù)衰減重試，整體的重試時(shí)間為1天，每次的重試時(shí)間間隔是指數(shù)遞增的（1秒，2秒，,4秒，8秒，...）。

最后，我們還可以配置推送的消息的格式，我們可以在創(chuàng)建訂閱的時(shí)候，指定推送格式為XML、JSON或者SIMPLIFIED。對(duì)于XML和JSON，推送給訂閱的消息內(nèi)容，除了會(huì)包含發(fā)送到主題的消息之外，還會(huì)添加例如MessageID、TopicName、SubscriptionName等屬性。而對(duì)于SIMPLIFIED，則是直接將發(fā)送到主題的消息進(jìn)行轉(zhuǎn)發(fā)，不會(huì)添加額外的屬性。

接入?yún)f(xié)議

MNS 以HTTP 協(xié)議對(duì)外提供服務(wù)，包含近 30 個(gè) RESTful 的 API，但核心業(yè)務(wù)場景往往使用 3 個(gè)左右的 API 就可以完成研發(fā)，非常易于上手。

另外，用戶既可以直接根據(jù) API 進(jìn)行自行的封裝，也可以直接使用官方所提供的的 SDK 進(jìn)行集成。用戶僅只需要依賴一個(gè) SDK 就可以完成從服務(wù)的開通、資源的創(chuàng)建、再到消息的收發(fā)。

在多語言 SDK 方面，MNS 提供了 8 種主流語言的 SDK，包括 Java、Python、C#、Node、PHP、C++、Go 等，同時(shí)也支持采用
Java 領(lǐng)域標(biāo)準(zhǔn)的 JMS SDK 接入 MNS。

適用場景解析

相較于 RabbitMQ，ActiveMQ，Kafka
等開源消息隊(duì)列，RocketMQ 輕量版 MNS 摒棄了非常復(fù)雜的概念模型及臃腫繁多的協(xié)議，通過簡單模型，通用的 HTTP RESTful 標(biāo)準(zhǔn)協(xié)議即可高效完成消息領(lǐng)域的典型場景。提供完全免運(yùn)維的消息集成方案，顯著降低開發(fā)和維護(hù)成本，提升新業(yè)務(wù)開發(fā)效率。

消息廣播（Fanout）場景解析

背景信息：輕量消息隊(duì)列 MNS 提供隊(duì)列（Queue）和主題（Topic）兩種模型，基本能滿足大多數(shù)應(yīng)用場景。隊(duì)列提供的是一對(duì)一的共享消息消費(fèi)模型，采用客戶端主動(dòng)拉?。≒ull）模式。

主題模型提供一對(duì)多的廣播消息消費(fèi)模型，采用服務(wù)端主動(dòng)推送（Push）模式。

推送模式的好處是即時(shí)性能較好，但需暴露客戶端地址來接收服務(wù)端的消息推送。有些情況下有的信息，例如企業(yè)內(nèi)網(wǎng)，無法暴露推送地址，希望改用拉取（Pull）的方式。雖然消息服務(wù)MNS不直接提供這種消費(fèi)模型，但可以結(jié)合主題和隊(duì)列來實(shí)現(xiàn)一對(duì)多的拉取消息消費(fèi)模型。

解決方案：通過創(chuàng)建訂閱，讓主題將消息先推送到隊(duì)列，然后由消費(fèi)者從隊(duì)列拉取消息。這樣既可以做到一對(duì)多的廣播消息，又可避免暴露消費(fèi)者的地址。

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

背景信息 ：消息服務(wù)MNS的隊(duì)列的消息大小最大限制是64 KB，這個(gè)限制基本能夠滿足在正常情況下消息作為控制流信息交換通道的需求。但是，在某些特殊場景下，消息數(shù)據(jù)比較大時(shí)，就只能采用消息切片的方式。

下面是不做消息切片，通過OSS來實(shí)現(xiàn)傳遞大于64 KB的消息的解決方案。

解決方案

生產(chǎn)者在向消息服務(wù)MNS發(fā)送消息前，如果發(fā)現(xiàn)消息體大于64 KB，則先將消息體數(shù)據(jù)上傳到OSS。

生產(chǎn)者把數(shù)據(jù)對(duì)應(yīng)的Object信息發(fā)送到消息服務(wù)MNS。

消費(fèi)者從消息服務(wù)MNS隊(duì)列里讀取消息，判斷消息內(nèi)容是否為OSS的Object信息。

判斷消息內(nèi)容是OSS的Object信息，則從OSS下載對(duì)應(yīng)的Object內(nèi)容，并作為消息體返回給上層程序。

簡單事務(wù)消息場景解析

背景信息：一些業(yè)務(wù)場景需要保證本地操作和消息發(fā)送的事務(wù)一致性，即消息發(fā)送成功，本地操作成功。如果消息發(fā)送成功，本地操作失敗，那么發(fā)送成功的消息需要回滾。操作流程如圖所示：

解決方案

消息發(fā)送成功，事務(wù)操作成功時(shí)操作步驟如下所示：

• 生產(chǎn)者發(fā)送一條事務(wù)準(zhǔn)備消息到事務(wù)消息隊(duì)列；
• 生產(chǎn)者發(fā)送操作日志消息到操作日志隊(duì)列，日志中包含步驟1消息的消息句柄；
• 生產(chǎn)者執(zhí)行本地事務(wù)操作成功；
• 生產(chǎn)者請(qǐng)求修改消息延遲時(shí)間，使消息對(duì)消費(fèi)者可見；
• 生產(chǎn)者向操作日志隊(duì)列確認(rèn)操作日志，刪除日志消息；
• 消費(fèi)者從事務(wù)消息隊(duì)列中接收事務(wù)消息；
• 消費(fèi)者處理事務(wù)消息；
• 消費(fèi)者請(qǐng)求刪除事務(wù)消息。

消息過濾（Message Filter） 場景解析

背景信息

一些場景中需要根據(jù)消息內(nèi)容把消息推送到不同的推送目標(biāo)，為了達(dá)到這一功能，您可以創(chuàng)建多個(gè)主題，并為每個(gè)主題設(shè)置相應(yīng)的推送目標(biāo)，但是這樣會(huì)增加額外的成本，并且增加了運(yùn)維的復(fù)雜度。為了避免這種情況，消息隊(duì)列MNS提供了消息過濾標(biāo)簽功能。您可以只創(chuàng)建一個(gè)主題，并在創(chuàng)建訂閱時(shí)設(shè)置不同的消息過濾標(biāo)簽，結(jié)合消息的消息過濾標(biāo)簽，MNS就可以把消息推送到不同的推送目標(biāo)中。

解決方案

圖示例場景中，在主題 Topic 1 創(chuàng)建 3 個(gè)消息過濾標(biāo)簽不同的訂閱，Subscription 1、Subscription 2和Subscription 3。這 3 個(gè)訂閱的推送目標(biāo)分別是 Queue 1、Queue 2 和
Queue 3。

• 消息的消息過濾標(biāo)簽和訂閱的消息過濾標(biāo)簽一致。消息過濾過程如下：

?  消息服務(wù) MNS 將 Message 1 推送到隊(duì)列 Queue 1；

?  消息服務(wù) MNS 將 Message 2 推送到隊(duì)列 Queue 2。

• 訂閱沒有消息過濾標(biāo)簽。消息過濾過程如下：

?  消息服務(wù) MNS 將 Message 1推送到隊(duì)列Queue 3；

?  消息服務(wù)MNS將Message 2推送到隊(duì)列Queue 3；

?  消息服務(wù)MNS將Message 3推送到隊(duì)列Queue 3。

客戶案例及最佳實(shí)踐

在線交易 - 應(yīng)用解耦 - 削峰填谷（典型場景）

 場景描述：

淘寶/天貓主站最為核心的系統(tǒng)是交易系統(tǒng)，每一筆交易訂單數(shù)據(jù)都會(huì)有幾百個(gè)下游業(yè)務(wù)系統(tǒng)的關(guān)聯(lián)，包括物流、購物車、積分、直充、阿里媽媽、流計(jì)算分析等，整個(gè)系統(tǒng)龐大而且復(fù)雜，架構(gòu)設(shè)計(jì)稍有不合理，將直接影響主站業(yè)務(wù)的連續(xù)性。

異步解耦：

如此復(fù)雜且龐大的系統(tǒng)，若上、下游業(yè)務(wù)系統(tǒng)緊耦合，那么任意一個(gè)子系統(tǒng)不可用都將直接導(dǎo)致核心交易系統(tǒng)不可用；

通過消息隊(duì)列實(shí)現(xiàn)上、下游業(yè)務(wù)系統(tǒng)松耦合，那么，即便下游子系統(tǒng)（如物流系統(tǒng)）出現(xiàn)不可用，也不會(huì)影響到核心交易系統(tǒng)的正常運(yùn)轉(zhuǎn)；

削峰填谷 :

通過消息隊(duì)列不僅可以起到系統(tǒng)間解耦的作用，更能在大促、秒殺等大型活動(dòng)中起到削峰填谷的作用。

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

直播錄制 - 合流 - 轉(zhuǎn)碼（Serverless 場景 ）

場景描述： 視頻的直播錄制，合流，轉(zhuǎn)碼是在線教育和在線直播領(lǐng)域的剛需場景，通過 MNS 可以對(duì) FC Serverless 資源進(jìn)行在線調(diào)度，幫助客戶實(shí)現(xiàn)異步直播流錄制，合流轉(zhuǎn)碼等復(fù)雜場景。

 在線游戲場景

場景描述： 游戲場景存在大量強(qiáng)交互場景的數(shù)據(jù)流轉(zhuǎn)，對(duì)消息中間件的穩(wěn)定性和端到端延遲要求極高，自建消息中間件壓力大、不穩(wěn)定。游戲場景存在大量的指令傳輸以及定時(shí)任務(wù)，自建邏輯無法解決熱點(diǎn)問題。

通過 MNS 可以實(shí)現(xiàn)從游戲網(wǎng)關(guān)指令到后臺(tái)消息協(xié)議的轉(zhuǎn)換，同時(shí) MNS 也支持后臺(tái)邏輯服、工會(huì)、戰(zhàn)斗服之間的異步解耦拆分。

 總結(jié)

對(duì)于 RocketMQ 來講，隨著核心架構(gòu)經(jīng)歷了五次重要的演進(jìn)階段。RocketMQ 5.0
包含了非常多的新功能，這些功能在完善消息功能的同時(shí)，也帶來大量的概念和組件更新。

作為阿里云 RocketMQ 的輕量版，填補(bǔ)了 RocketMQ 在輕量化和易用性的不足。盡管 MNS 版本伴隨 RocketMQ 經(jīng)過多年迭代與打磨，內(nèi)部極為復(fù)雜，但一直努力保持其在客戶端的簡單易用。為企業(yè)和開發(fā)者降低消息產(chǎn)品的復(fù)雜度，減少運(yùn)維開銷提供更易上手的消息隊(duì)列服務(wù)，是 MNS 的產(chǎn)品使命和愿景。

【MNS產(chǎn)品訓(xùn)練營活動(dòng)火熱報(bào)名中！】

為了幫助大家由淺入深的對(duì)阿里云消息隊(duì)列MNS有更加全面的了解，同時(shí)期望消息隊(duì)列MNS能夠幫助大家解決日常工作和生產(chǎn)的問題，特推出消息隊(duì)列MNS產(chǎn)品訓(xùn)練營課程，課程中不僅有對(duì)產(chǎn)品簡單形象的介紹，還有“首秀”的動(dòng)手實(shí)踐學(xué)習(xí)課程。

參與本次消息隊(duì)列MNS訓(xùn)練營，您可以學(xué)習(xí)并收獲到：

• 消息隊(duì)列MNS的基礎(chǔ)概念及特性
• 消息隊(duì)列MNS的最佳實(shí)踐及案例
• 基于MNS，0基礎(chǔ)輕松構(gòu)建Web Client

除了學(xué)習(xí)層面的收獲，活動(dòng)期間，完成所有參營任務(wù)且考試通過的前20名同學(xué)可獲得（若成績相同按考試時(shí)間順序排名），即可免費(fèi)獲得小米充電寶?；顒?dòng)時(shí)間：8月10日-8月31日（工作日期間）。

點(diǎn)擊鏈接，立即報(bào)名吧～??https://developer.aliyun.com/trainingcamp/1091392f83464404a407920226a9df17?utm_content=g_1000353774??