MetaQ的概念是什么

這篇文章主要講解了“MetaQ的概念是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“MetaQ的概念是什么”吧！

消息中間件——分布式消息的廣播員

綜述
消息中間件是一種由消息傳送機(jī)制或消息隊列模式組成的最典型的中間件技術(shù)。通過消息中間件，應(yīng)用程序或組件之間可以進(jìn)行可靠的異步通訊來降低系統(tǒng)之間的耦合度，從而提高整個系統(tǒng)的可擴(kuò)展性和可用性。

3.1、Notify

Notify是淘寶自主研發(fā)的一套消息服務(wù)引擎，是支撐雙11最為核心的系統(tǒng)之一，在淘寶和支付寶的核心交易場景中都有大量使用。消息系統(tǒng)的核心作用就是三點：解耦，異步和并行。下面讓我以一個實際的例子來說明一下解耦異步和并行分別所代表的具體意義吧：

假設(shè)我們有這么一個應(yīng)用場景，為了完成一個用戶注冊淘寶的操作，可能需要將用戶信息寫入到用戶庫中，然后通知給紅包中心給用戶發(fā)新手紅包，然后還需要通知支付寶給用戶準(zhǔn)備對應(yīng)的支付寶賬號，進(jìn)行合法性驗證，告知sns系統(tǒng)給用戶導(dǎo)入新的用戶等10步操作。
那么針對這個場景，一個最簡單的設(shè)計方法就是串行的執(zhí)行整個流程，如圖3-1所示：

這種方式的最大問題是，隨著后端流程越來越多，每步流程都需要額外的耗費很多時間，從而會導(dǎo)致用戶更長的等待延遲。自然的，我們可以采用并行的方式來完成業(yè)務(wù)，能夠極大的減少延遲，如圖3-2所示。

但并行以后又會有一個新的問題出現(xiàn)了，在用戶注冊這一步，系統(tǒng)并行的發(fā)起了4個請求，那么這四個請求中，如果通知SNS這一步需要的時間很長，比如需要10秒鐘的話，那么就算是發(fā)新手包，準(zhǔn)備支付寶賬號，進(jìn)行合法性驗證這幾個步驟的速度再快，用戶也仍然需要等待10秒以后才能完成用戶注冊過程。因為只有當(dāng)所有的后續(xù)操作全部完成的時候，用戶的注冊過程才算真正的“完成”了。用戶的信息狀態(tài)才是完整的。而如果這時候發(fā)生了更嚴(yán)重的事故，比如發(fā)新手紅包的所有服務(wù)器因為業(yè)務(wù)邏輯bug導(dǎo)致down機(jī)，那么因為用戶的注冊過程還沒有完全完成，業(yè)務(wù)流程也就是失敗的了。這樣明顯是不符合實際的需要的，隨著下游步驟的逐漸增多，那么用戶等待的時間就會越來越長，并且更加嚴(yán)重的是，隨著下游系統(tǒng)越來越多，整個系統(tǒng)出錯的概率也就越來越大。

通過業(yè)務(wù)分析我們能夠得知，用戶的實際的核心流程其實只有一個，就是用戶注冊。而后續(xù)的準(zhǔn)備支付寶，通知sns等操作雖然必須要完成，但卻是不需要讓用戶等待的。
這種模式有個專業(yè)的名詞，就叫最終一致。為了達(dá)到最終一致，我們引入了MQ系統(tǒng)。業(yè)務(wù)流程如下：

主流程如圖3-3所示：

圖3-3-用戶注冊流程-引入MQ系統(tǒng)-主流程

異步流程如圖3-4所示：

圖3-4-用戶注冊流程-引入MQ系統(tǒng)-異步流程

核心原理

Notify在設(shè)計思路上與傳統(tǒng)的MQ有一定的不同，他的核心設(shè)計理念是

1. 為了消息堆積而設(shè)計系統(tǒng)

2. 無單點，可自由擴(kuò)展的設(shè)計

下面就請隨我一起，進(jìn)入到我們的消息系統(tǒng)內(nèi)部來看看他設(shè)計的核心原理

為了消息堆積而設(shè)計系統(tǒng)在市面上的大部分MQ產(chǎn)品，大部分的核心場景就是點對點的消息傳輸通道，然后非常激進(jìn)的使用內(nèi)存來提升整體的系統(tǒng)性能，這樣做雖然標(biāo)稱的tps都能達(dá)到很高，但這種設(shè)計的思路是很難符合大規(guī)模分布式場景的實際需要的。

在實際的分布式場景中，這樣的系統(tǒng)會存在著較大的應(yīng)用場景瓶頸，在后端有大量消費者的前提下，消費者出現(xiàn)問題是個非常常見的情況，而消息系統(tǒng)則必須能夠在后端消費不穩(wěn)定的情況下，仍然能夠保證用戶寫入的正常并且TPS不降，是個非常考驗消息系統(tǒng)能力的實際場景。

也因為如此，在Notify的整體設(shè)計中，我們最優(yōu)先考慮的就是消息堆積問題，在目前的設(shè)計中我們使用了持久化磁盤的方式，在每次用戶發(fā)消息到Notify的時候都將消息先落盤，然后再異步的進(jìn)行消息投遞，而沒有采用激進(jìn)的使用內(nèi)存的方案來加快投遞速度。

這種方式，雖然系統(tǒng)性能在峰值時比目前市面的MQ效率要差一些，但是作為整個業(yè)務(wù)邏輯的核心單元，穩(wěn)定，安全可靠是系統(tǒng)的核心訴求。

無單點，可自由擴(kuò)展的設(shè)計

圖3-5展示了組成Notify整個生態(tài)體系的有五個核心的部分。

• 發(fā)送消息的集群這主要是業(yè)務(wù)方的機(jī)器，這些APP的機(jī)器上是沒有任何狀態(tài)信息的，可以隨著用戶請求量的增加而隨時增加或減少業(yè)務(wù)發(fā)送方的機(jī)器數(shù)量，從而擴(kuò)大或縮小集群能力。

• 配置服務(wù)器集群(Config server)這個集群的主要目的是動態(tài)的感知應(yīng)用集群，消息集群機(jī)器上線與下線的過程，并及時廣播給其他集群。如當(dāng)業(yè)務(wù)接受消息的機(jī)器下線時，config server會感知到機(jī)器下線，從而將該機(jī)器從目標(biāo)用戶組內(nèi)踢出，并通知給notify server，notify server 在獲取通知后，就可以將已經(jīng)下線的機(jī)器從自己的投遞目標(biāo)列表中刪除，這樣就可以實現(xiàn)機(jī)器的自動上下線擴(kuò)容了。

• 消息服務(wù)器(Notify Server)消息服務(wù)器，也就是真正承載消息發(fā)送與消息接收的服務(wù)器，也是一個集群，應(yīng)用發(fā)送消息時可以隨機(jī)選擇一臺機(jī)器進(jìn)行消息發(fā)送，任意一臺server 掛掉，系統(tǒng)都可以正常運行。當(dāng)需要增加處理能力時，只需要簡單地增加notify Server就可以了

• 存儲(Storage)Notify的存儲集群有多種不同的實現(xiàn)方式，以滿足不同應(yīng)用的實際存儲需求。針對消息安全性要求高的應(yīng)用，我們會選擇使用多份落盤的方式存儲消息數(shù)據(jù)，而對于要求吞吐量而不要求消息安全的場景，我們則可以使用內(nèi)存存儲模型的存儲。自然的，所有存儲也被設(shè)計成了隨機(jī)無狀態(tài)寫入存儲模型以保障可以自由擴(kuò)展。

• 消息接收集群業(yè)務(wù)方用于處理消息的服務(wù)器組，上下線機(jī)器時候也能夠動態(tài)的由config server 感知機(jī)器上下線的時機(jī)，從而可以實現(xiàn)機(jī)器自動擴(kuò)展。

3.2、Notify雙11準(zhǔn)備與優(yōu)化

在雙11的整個準(zhǔn)備過程中，Notify都承載了非常巨大的壓力，因為我們的核心假定就是后端系統(tǒng)一定會掛，而我們需要能夠承載整個交易高峰內(nèi)的所有消息都會堆積在數(shù)據(jù)庫內(nèi)的實際場景。
在多次壓測中，我們的系統(tǒng)表現(xiàn)還是非常穩(wěn)定的，以60w/s的寫入量堆積4.5億消息的時候，整個系統(tǒng)表現(xiàn)非常淡定可靠。在真正的大促到來時，我們的后端系統(tǒng)響應(yīng)效率好于預(yù)期，所以我們很輕松的就滿足了用戶所有消息投遞請求，比較好的滿足了用戶的實際需要。

3.3、MetaQ

METAQ是一款完全的隊列模型消息中間件，服務(wù)器使用Java語言編寫，可在多種軟硬件平臺上部署?？蛻舳酥С諮ava、C++編程語言，已于2012年3月對外開源，開源地址是：http://metaq.taobao.org/。MetaQ大約經(jīng)歷了下面3個階段

在2011年1月份發(fā)布了MetaQ 1.0版本，從Apache Kafka衍生而來，在內(nèi)部主要用于日志傳輸。
在2012年9月份發(fā)布了MetaQ 2.0版本，解決了分區(qū)數(shù)受限問題，在數(shù)據(jù)庫binlog同步方面得到了廣泛的應(yīng)用。
在2013年7月份發(fā)布了MetaQ 3.0版本，MetaQ開始廣泛應(yīng)用于訂單處理，cache同步、流計算、IM實時消息、binlog同步等領(lǐng)域。MetaQ3.0版本已經(jīng)開源，參見這里
綜上，MetaQ借鑒了Kafka的思想，并結(jié)合互聯(lián)網(wǎng)應(yīng)用場景對性能的要求，對數(shù)據(jù)的存儲結(jié)構(gòu)進(jìn)行了全新設(shè)計。在功能層面，增加了更適合大型互聯(lián)網(wǎng)特色的功能點。

MetaQ簡介

圖3-6-MetaQ整體結(jié)構(gòu)

如圖3-6所示，MetaQ對外提供的是一個隊列服務(wù)，內(nèi)部實現(xiàn)也是完全的隊列模型，這里的隊列是持久化的磁盤隊列，具有非常高的可靠性，并且充分利用了操作系統(tǒng)cache來提高性能。

• 是一個隊列模型的消息中間件，具有高性能、高可靠、高實時、分布式特點。

• Producer、Consumer、隊列都可以分布式。

• Producer向一些隊列輪流發(fā)送消息，隊列集合稱為Topic，Consumer如果做廣播消費，則一個consumer實例消費* * 這個Topic對應(yīng)的所有隊列，如果做集群消費，則多個Consumer實例平均消費這個topic對應(yīng)的隊列集合。

• 能夠保證嚴(yán)格的消息順序

• 提供豐富的消息拉取模式

• 高效的訂閱者水平擴(kuò)展能力

• 實時的消息訂閱機(jī)制

• 億級消息堆積能力

MetaQ存儲結(jié)構(gòu)

MetaQ的存儲結(jié)構(gòu)是根據(jù)阿里大規(guī)?；ヂ?lián)網(wǎng)應(yīng)用需求，完全重新設(shè)計的一套存儲結(jié)構(gòu)，使用這套存儲結(jié)構(gòu)可以支持上萬的隊列模型，并且可以支持消息查詢、分布式事務(wù)、定時隊列等功能，如圖3-7所示。

圖3-7-MetaQ存儲體系

MetaQ單機(jī)上萬隊列

MetaQ內(nèi)部大部分功能都靠隊列來驅(qū)動，那么必須支持足夠多的隊列，才能更好的滿足業(yè)務(wù)需求，如圖所示，MetaQ可以在單機(jī)支持上萬隊列，這里的隊列全部為持久化磁盤方式，從而對IO性能提出了挑戰(zhàn)。MetaQ是這樣解決的

Message全部寫入到一個獨立的隊列，完全的順序?qū)?br/> Message在文件的位置信息寫入到另外的文件，串行方式寫。
通過以上方式，既做到數(shù)據(jù)可靠，又可以支持更多的隊列，如圖3-8所示。

圖3-8-MetaQ單機(jī)上萬隊列

MetaQ與Notify區(qū)別

• Notify側(cè)重于交易消息，分布式事務(wù)消息方面。

• MetaQ側(cè)重于順序消息場景，例如binlog同步。以及主動拉消息場景，例如流計算等。

3.4、MetaQ雙11準(zhǔn)備與優(yōu)化

Notify 交易消息轉(zhuǎn) MetaQ 方案改進(jìn)

MetaQ 交易集群主要是 Notify 交易消息的一個鏡像，舊有的方案是通過 Notify-Client 訂閱 Notify 交易消息，然后再轉(zhuǎn)投到 MetaQ 集群，這個方案的缺點：1. 通過消息訂閱的方式給 Notify 集群帶來比較大的壓力 2. 一旦 MetaQ 集群處理不及時會給 Notify 造成消息的堆積，從而帶來連鎖不良效應(yīng)。新的方案則是從Notify DB直接拉取binlog到MetaQ，它帶來的優(yōu)勢： 1. 解放 NotifyServer 集群的壓力；2. 通過 binlog 批量處理可以提升系統(tǒng)的吞吐量。

交易集群低延遲優(yōu)化

天貓直播間，旨在通過實時獲取活動當(dāng)天的交易數(shù)據(jù)，通過實時流計算的方式，及時、準(zhǔn)確的展示各業(yè)務(wù)數(shù)據(jù)。它的特點就是數(shù)據(jù)全而準(zhǔn)確、實時性要求較高。而在全鏈路壓測過程中發(fā)現(xiàn)從 Notify Mysql binlog 獲取數(shù)據(jù)時，出現(xiàn)較大的延遲，最嚴(yán)重的延遲高達(dá)4h+，這顯然是不合系統(tǒng)需求的?；谶@些問題，我們在 Notify Mysql 端做了很多的優(yōu)化：
Mysql 數(shù)據(jù)庫實例擴(kuò)容，從而提高集群的整體吞吐量；
對 binlog 的存放位置進(jìn)行優(yōu)化，將數(shù)據(jù)存儲以及 binlog 存儲進(jìn)行分離，從而發(fā)揮 DB 的最大寫性能；
由于 MySQL 的 binlog 操作存在鎖操作，優(yōu)化了 MySQL 生成 binlog 的配置，保證了拉 binlog 無延時。

針對不同集群運行參數(shù)調(diào)優(yōu)

根據(jù)業(yè)務(wù)的特點，對不同集群的運行參數(shù)調(diào)優(yōu)，如批量拉取大小，刷盤方式，數(shù)據(jù)有效期等等；同時對io調(diào)度、虛擬內(nèi)存等參數(shù)進(jìn)行調(diào)優(yōu)，以提供更為高效的堆積。

監(jiān)控與實時告警

任何一個值得信賴的系統(tǒng)，最低限度是需要做到及時發(fā)現(xiàn)并處理異常，在第一時間排除故障發(fā)生的可能，從而提高產(chǎn)品的可用性。在雙十一活動之前，我們實現(xiàn)了由 MetaQ 系統(tǒng)內(nèi)部，根據(jù)集群狀態(tài)，各消息的業(yè)務(wù)數(shù)據(jù)指標(biāo)進(jìn)行監(jiān)控統(tǒng)計并主動告警，同時還能通過 Diamond 做到動態(tài)調(diào)整，從而提高監(jiān)控的及時性以及靈活性。

回顧雙十一活動當(dāng)日，淘寶消息寫入總量112億，消息投遞總量220億，支付寶消息寫入總量24億，消息投遞總量24億。其中實時直播間集群消息寫入峰值為13.1w，消息投遞峰值為27.8w。

從總體上看，我們的前期準(zhǔn)備還是比較充分的，MetaQ 各集群在高峰期表現(xiàn)穩(wěn)定，全天表現(xiàn)很平穩(wěn)，個別訂閱組對消息進(jìn)行重溯，部分消息有少量的堆積，但都沒有對系統(tǒng)造成影響，效果還是非常好的。75%的交易在聚石塔上完成，實時直播間交易統(tǒng)計延遲在1s左右，加減庫存做到零超賣。

小結(jié)

目前分布式消息中間件產(chǎn)品已經(jīng)服務(wù)于整個集團(tuán)，支持了阿里集團(tuán)各個公司的500多個業(yè)務(wù)應(yīng)用系統(tǒng)。每日處理海量消息超350億次，保證所有交易數(shù)據(jù)高可靠，高性能，分布式事務(wù)處理，是中間件團(tuán)隊最老牌的中間件產(chǎn)品之一。

補(bǔ)充閱讀：Notify實現(xiàn)分布式事務(wù)的方式

資料來源：http://club.alibabatech.org/resource_detail.htm?topicId=61

業(yè)務(wù)操作和消息存儲都在本地事務(wù)域進(jìn)行，不存在跨資源的事務(wù)。
提交/回滾消息有可能失敗，系統(tǒng)會處于短暫的不一致狀態(tài)
Broker會主動發(fā)送Check消息，確認(rèn)消息是否提交或回滾
最終一致
將分布式事務(wù)分解在兩個本地事務(wù)中
客戶端需要付出的代價
實現(xiàn)CheckMessageListener接口

延伸閱讀：MetaQ在雙十二彩票中的運用

原帖鏈接：http://jm-blog.aliapp.com/?p=3405&utm_source=tuicool

雙十二大促是淘寶集市的年終促銷活動，活動當(dāng)天掃描首頁二維碼贈送一注彩票的活動更是讓大家“玩”了一把。面對瞬間的數(shù)倍于往常的峰值，如何讓用戶有一個良好的體驗，如何保證系統(tǒng)的穩(wěn)定運行，讓我們來揭秘這一切。

歸納一下系統(tǒng)需要做到如下幾點：

• RT足夠短

• 壓力分布均勻

• 復(fù)雜邏輯分離，異步話

系統(tǒng)結(jié)構(gòu)圖

大體分為兩個部分：活動系統(tǒng)，彩票系統(tǒng)，他們之間通過消息驅(qū)動。
活動系統(tǒng)里面只更新一個彩票分配的狀態(tài)，數(shù)據(jù)更新成功就返回給用戶，邏輯足夠簡單能保證RT非常短。彩票系統(tǒng)負(fù)責(zé)真正的彩票出票和更新用戶狀態(tài)等一些耗時操作。
用戶在首頁掃描二維碼發(fā)起對活動系統(tǒng)的請求，活動系統(tǒng)更新彩票分配狀態(tài)，產(chǎn)生一條消息，立即返回并。彩票系統(tǒng)收到這個消息完成后續(xù)出票等一些的業(yè)務(wù)操作。整個過程是通過MetaQ提供的消息服務(wù)驅(qū)動完成?；顒拥臅r候會有大量的請求涌進(jìn)活動系統(tǒng)，會產(chǎn)生大量的消息，預(yù)估qps達(dá)到24w；并且消息不可丟失，確保用戶都能領(lǐng)到一注彩票；活動系統(tǒng)，彩票系統(tǒng)業(yè)務(wù)復(fù)雜度相差較大，處理能力也相差較大，可能會出現(xiàn)大量的堆積；為了讓用戶有個較好的體驗，消息的消費也需要足夠的及時。綜上對MetaQ有這么一些挑戰(zhàn)：

• 高吞吐量

• 數(shù)據(jù)可靠

• 高效堆積

• 消息投遞足夠低延遲

下面介紹一下MetaQ如何做到這些的。

MetaQ簡介

METAQ是一款完全的隊列模型消息中間件，服務(wù)器使用Java語言編寫，可在多種軟硬件平臺上部署。客戶端支持Java、C++編程語言，已于2012年3月對外開源，開源地址。MetaQ的設(shè)計目標(biāo)是高吞吐量，高效堆積。完全的隊列模型還提供了順序消息，消息回溯等一些特性。

基本概念

• Topic 消息主題

• Partition 分區(qū)，代表一個消費隊列 （一個Topic可以劃分為多個分區(qū)，分區(qū)數(shù)越多并行度越大，支持的Qps越高）

• Group 消費分組，代表一個消費集群

MetaQ對外提供的是一個隊列服務(wù)，內(nèi)部實現(xiàn)也是完全的隊列模型，這里的隊列是持久化的磁盤隊列，具有非常高的可靠性，并且充分利用了操作系統(tǒng)cache來提高性能。這些特性都源于存儲層的設(shè)計。

MetaQ存儲結(jié)構(gòu)

MetaQ的存儲結(jié)構(gòu)是根據(jù)阿里大規(guī)?；ヂ?lián)網(wǎng)應(yīng)用需求，完全重新設(shè)計的一套存儲結(jié)構(gòu)，使用這套存儲結(jié)構(gòu)可以支持上萬的隊列模型，并且可以支持消息查詢、分布式事務(wù)、定時隊列等功能，如圖3所示。

存儲層可以大致分為數(shù)據(jù)文件（CommitLog）和索引文件兩部分。數(shù)據(jù)文件保存了所有的消息的內(nèi)容，索引文件保存了消息所在數(shù)據(jù)文件的偏移量。消息數(shù)據(jù)不區(qū)分Topic，順序的append到CommitLog，索引文件按照Topic-Partition維度組織，不同分區(qū)的消息append到不同索引隊列里面。

消息寫入
客戶端發(fā)送一條消息,數(shù)據(jù)首先會寫到文件緩存中，同時派發(fā)一個寫索引請求；異步的構(gòu)建消息索引。

消息讀取
客戶端讀取消息，根據(jù)索引的位置找到需要讀取的消息的物理位置和消息長度，從CommitLog中讀取數(shù)據(jù)，通過文件緩存來加速消息的讀取。通常熱數(shù)據(jù)都在緩存中，無需IO操作；非熱數(shù)據(jù)，會觸發(fā)缺頁中斷，數(shù)據(jù)從磁盤加載到文件緩存中，直接寫到socket緩沖區(qū)，避免數(shù)據(jù)進(jìn)入Java堆。

數(shù)據(jù)刷盤
刷盤后數(shù)據(jù)最終持久化到磁盤。刷盤方式分為兩種方式：同步刷盤，數(shù)據(jù)寫入緩存后立即刷盤，確保數(shù)據(jù)落盤后返回客戶端，MetaQ在同步刷盤過程中也做了一定優(yōu)化避免過多的性能損失；異步刷盤，數(shù)據(jù)批量定時的刷到磁盤。

數(shù)據(jù)清理
消息數(shù)據(jù)按照文件有效期定時做清理。

數(shù)據(jù)復(fù)制
數(shù)據(jù)可靠性要求很高的應(yīng)用，可通過數(shù)據(jù)復(fù)制保證數(shù)據(jù)的可靠。MetaQ提供兩種數(shù)據(jù)同步的方式：同步雙寫，數(shù)寫入到主機(jī)后會同時寫到備機(jī)，主備都寫成功才返回客戶端成功，主備間數(shù)據(jù)無延遲，MetaQ有一套自己的主備間高效數(shù)據(jù)復(fù)制方案；異步復(fù)制，數(shù)據(jù)寫到主機(jī)后返回客戶端成功，主備間異步同步，主備間存在一定的延遲。

MetaQ單機(jī)上萬隊列

MetaQ的大部分功能都是靠隊列來驅(qū)動，以文件的方式存儲，通過內(nèi)存映射對數(shù)據(jù)進(jìn)行操作。所有的消息都是順序的寫到數(shù)據(jù)文件（CommitLog），完全順序的寫入，避免隨機(jī)IO；消息索引按照Topic和Partition的維度區(qū)分串行的寫到索引文件。通過這種這種組織方式可以實現(xiàn)單機(jī)上萬隊列，如圖4所示。

數(shù)據(jù)流圖

消息數(shù)據(jù)首先寫入到Java堆，然后在寫入到文件緩存，在根據(jù)具體的刷盤策略Flush到磁盤；消費消息的時候如果是熱數(shù)據(jù)則直接從系統(tǒng)緩存寫到socket發(fā)到遠(yuǎn)端；如果非熱數(shù)據(jù)則由系統(tǒng)產(chǎn)生缺頁中斷將數(shù)據(jù)從磁盤加載到系統(tǒng)緩存在寫到socket，數(shù)據(jù)不進(jìn)應(yīng)用程序內(nèi)存空間。內(nèi)存的管理，頁面的換入換出都是由OS來管理的。同時消息的拉取也是批量的，一次處理多條數(shù)據(jù)，盡量減少往返的時間。
MetaQ性能依賴于系統(tǒng)內(nèi)存分配，磁盤IO的有效利用，所以我們也對操作系統(tǒng)內(nèi)存分配，臟頁會寫策略，以及IO調(diào)度算法做了一些調(diào)優(yōu)，讓資源的分配耗時趨于平穩(wěn)，堆積的時候保持較高的吞吐量。

負(fù)載均衡

發(fā)送端負(fù)載
默認(rèn)發(fā)送端通過輪詢的方式向broker寫消息，如圖6所示；也可以自行指定消息發(fā)到哪里。

消費端負(fù)載
默認(rèn)是消費集群機(jī)器均分所有的消費隊列。余下的部分由靠前的消費者消費，如圖7所示。消費端負(fù)載均很也可以定制，如同機(jī)房優(yōu)先等。

感謝各位的閱讀，以上就是“MetaQ的概念是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對MetaQ的概念是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！