作者 | 葛賢亮，單位：中國(guó)移動(dòng)智慧家庭運(yùn)營(yíng)中心

?Labs 導(dǎo)讀

近年來(lái)，互聯(lián)網(wǎng)技術(shù)發(fā)展迅猛，各行各業(yè)的信息量急劇膨脹。隨著云計(jì)算和算力網(wǎng)絡(luò)時(shí)代的到來(lái)，消息中間件在國(guó)內(nèi)許多行業(yè)的關(guān)鍵應(yīng)用中越來(lái)越受到重視。在高并發(fā)分布式場(chǎng)景下，合理地利用消息中間件往往能起到突破性能瓶頸與化繁為簡(jiǎn)的效果。

前期從“作用”與“協(xié)議”出發(fā)，使讀者對(duì)消息中間件技術(shù)有了初步認(rèn)識(shí)。本期由“傳輸模式”與“消費(fèi)模式”切入，期望能以點(diǎn)見(jiàn)面使讀者對(duì)消息中間件有更深入的了解。

1 消息中間件的傳輸模式

從傳輸視角看，MQ的消息模式可分為“點(diǎn)對(duì)點(diǎn)”和“發(fā)布/訂閱”兩種模式。

1.1 點(diǎn)對(duì)點(diǎn)(Point-to-Point，PTP)

顧名思義，PTP模型用于消息生產(chǎn)者和消息消費(fèi)者之間點(diǎn)對(duì)點(diǎn)的通信。消息生產(chǎn)者基于某種規(guī)則將消息發(fā)送到特定的消費(fèi)者，通常是某個(gè)固定的消息隊(duì)列(Queue)，在消息傳遞給消費(fèi)者之前它被存儲(chǔ)在這個(gè)隊(duì)列中。隊(duì)列消息可以放在內(nèi)存中也可以持久化，以保證在消息服務(wù)出現(xiàn)故障時(shí)仍然能夠傳遞消息。

PTP模型中，一個(gè)隊(duì)列可以有多個(gè)生產(chǎn)者和多個(gè)消費(fèi)者。消息服務(wù)器按照收到消息的先后順序，將消息放到隊(duì)列中。隊(duì)列中的每一條消息，只能由一個(gè)消費(fèi)者進(jìn)行消費(fèi)，消費(fèi)之后就會(huì)從隊(duì)列中移除。

圖1.1 點(diǎn)對(duì)點(diǎn)模型

需要注意的是，盡管使用Queue的概念，但并代表先進(jìn)入隊(duì)列的消息，一定會(huì)被先消費(fèi)。為了提升系統(tǒng)并發(fā)性，很多MQ實(shí)現(xiàn)方案中引入了“消費(fèi)者組”的概念，隊(duì)列中的消息會(huì)被分發(fā)到不同的消費(fèi)者進(jìn)行并行處理。這意味著消息在發(fā)送的時(shí)候是有序的，但是在消費(fèi)的時(shí)候就變成無(wú)序了。一些MQ提供了“專(zhuān)有消費(fèi)者”或者“排他消費(fèi)者”的概念，在這種情況下，隊(duì)列中的消息僅允許一個(gè)消費(fèi)者進(jìn)行消費(fèi)。但是，這也犧牲了消息的并發(fā)消費(fèi)能力，消息量很大的情況下，將會(huì)產(chǎn)生嚴(yán)重的消息積壓。為了解決這一問(wèn)題，一些MQ方案（如 Kafka、RocketMQ）又引入了分區(qū)的概念，相同主題的消息使用不同分區(qū)進(jìn)行隔離，同一分區(qū)內(nèi)的消息可以有序消費(fèi)，不同分區(qū)內(nèi)的消息可以并行消費(fèi)。

1.2 發(fā)布/訂閱(Publish-and-Subscribe，Pub/Sub)

Pub/Sub模式類(lèi)似廣播消息，生產(chǎn)者將消息發(fā)布到一個(gè)主題(Topic)中，訂閱了該Topic的所有下游消費(fèi)者，都可以接收到這條消息。

在這種模型下，發(fā)布者和訂閱者彼此無(wú)感知。相較于PTP模型中一個(gè)消息只能被一個(gè)消費(fèi)者消費(fèi)，Pub/Sub模型中一個(gè)消息會(huì)被發(fā)送至所有訂閱了該Topic的消費(fèi)者進(jìn)行消費(fèi)。

圖1.2 發(fā)布/訂閱模型

Queue與Topic區(qū)別：

• Queue實(shí)現(xiàn)了負(fù)載均衡，將生產(chǎn)者生產(chǎn)的消息發(fā)送到消息隊(duì)列中，由多個(gè)消費(fèi)者消費(fèi)。但一個(gè)消息只能被一個(gè)消費(fèi)者接受，當(dāng)沒(méi)有消費(fèi)者可用時(shí)，這個(gè)消息會(huì)被保存直到有一個(gè)可用的消費(fèi)者。
• Topic實(shí)現(xiàn)了發(fā)布和訂閱，當(dāng)發(fā)布一個(gè)消息時(shí)，所有訂閱這個(gè)Topic的服務(wù)都能得到這個(gè)消息；所以從1到N個(gè)訂閱者都能得到這個(gè)消息的拷貝。

2 消息中間件的消費(fèi)模式

從消費(fèi)視角看，MQ的消費(fèi)模式可分為“Push”和“Pull”兩種模式。

2.1 推消息模型(Push)

消息生產(chǎn)者將消息發(fā)送給消息服務(wù)器后，消息服務(wù)器主動(dòng)地將消息“推送”給消費(fèi)者。

2.1.1 Push模型優(yōu)點(diǎn)

Push模型最大的好處就是實(shí)時(shí)性。因?yàn)榉?wù)端可以做到只要有消息就立即推送，所以消息的消費(fèi)沒(méi)有“額外”的延遲。

2.1.2 Push模型缺點(diǎn)

Push模型看上去很美好，但在實(shí)際使用中卻存在很多硬傷，以至于有些MQ的Push模型底層也是依托Pull方式實(shí)現(xiàn)的。

? Push模型存在以下問(wèn)題：

• 在Broker端需要維護(hù)Consumer的狀態(tài)，不利于Broker去支持大量Consumer的場(chǎng)景；
• Consumer的消費(fèi)速度不一致，由Broker進(jìn)行推送難以根據(jù)不同的Consumer狀況選擇相應(yīng)的推送策略（時(shí)機(jī)）；
• Broker難以處理Consumer無(wú)法消費(fèi)消息的情況（Broker無(wú)法確定Consumer的故障是短暫的還是永久的）；
• 在Consumer消費(fèi)能力不足的情況下，大量的推送消息會(huì)加重Consumer的負(fù)載或者沖垮Consumer。

2.2 拉消息模型(Pull)

消息生產(chǎn)者將消息發(fā)送給消息服務(wù)器后，由消息消費(fèi)者主動(dòng)從消息服務(wù)器中拉取該消息。

2.2.1 Pull模型優(yōu)點(diǎn)

相較于Push模型，Pull模型存在以下優(yōu)勢(shì)：

• Broker不再需要維護(hù)Consumer的狀態(tài)（每一次pull都包含了偏移量等必要信息）；
• 由Consumer維護(hù)狀態(tài)，Consumer可以很容易的根據(jù)自身的負(fù)載等狀態(tài)來(lái)決定從Broker獲取消息的頻率；
• 可以實(shí)現(xiàn)消息聚合。Push模型中，Broker無(wú)法預(yù)測(cè)寫(xiě)一條消息產(chǎn)生的時(shí)間，所以在收到消息之后只能立即推送給Consumer，所以無(wú)法對(duì)消息聚合后再推送給Consumer。而Pull模型中由Consumer主動(dòng)獲取消息，每一次Pull時(shí)都能批量獲取Broker中的消息。

2.2.2 Pull模型缺點(diǎn)

優(yōu)勢(shì)的反面即時(shí)劣勢(shì)，Pull模型存在以下缺點(diǎn)：

• 實(shí)時(shí)性差。因?yàn)橛蒀onsumer主動(dòng)Pull消息，所以實(shí)時(shí)性和Pull的周期相關(guān)，這樣就產(chǎn)生了“額外”延遲。如果通過(guò)提升Pull的執(zhí)行頻率來(lái)降低延遲，又會(huì)在沒(méi)有消息的時(shí)候產(chǎn)生大量的Pull請(qǐng)求（消息中間件是完全解耦的，Broker和Consumer無(wú)法預(yù)測(cè)下一條消息在什么時(shí)候產(chǎn)生）；
• Pull模型中由Consumer維護(hù)狀態(tài)，所以多個(gè)Consumer之間需要相互協(xié)調(diào)，這樣就需要引入ZooKeeper(Kafka)或者自己實(shí)現(xiàn) NameServer(RocketMQ)之類(lèi)的服務(wù)來(lái)完成Consumer之間的協(xié)調(diào)工作。

2.3 Push/Pull區(qū)別

? 在實(shí)際應(yīng)用場(chǎng)景中：

• 大吞吐量的消息隊(duì)列都是采用Pull模式，而非Push模式；
• 采用Push模式，消費(fèi)端的性能會(huì)影響整個(gè)消息隊(duì)列服務(wù)器的性能；
• 采用Push模式，容易造成broker的消息積壓，因?yàn)閎roker控制消息的推送速率，消息數(shù)量大的話，很難使每個(gè)消費(fèi)者很難適應(yīng)消息推送速率；

2.4 常用消息中間件支持模型

2.5 Long-Polling

如上所述，雖然很多消息中間件都支持Push模式，但是在實(shí)現(xiàn)時(shí)其實(shí)也是采用pull方式實(shí)現(xiàn)的push語(yǔ)義。

比較成熟的做法是采用Long-Polling的方式，基于Push/Pull方案的優(yōu)缺點(diǎn)，在性能與時(shí)效性之間尋找到一個(gè)平衡點(diǎn)。

Long-Polling是Pull模式的變種。Pull模型中不管服務(wù)端數(shù)據(jù)有無(wú)更新，客戶(hù)端每隔定長(zhǎng)時(shí)間拉取一次數(shù)據(jù)，可能有更新數(shù)據(jù)返回，也可能什么都沒(méi)有。Long Polling是指客戶(hù)端發(fā)起Long Polling，此時(shí)如果服務(wù)端沒(méi)有消息，會(huì)hold住請(qǐng)求，直到服務(wù)端有可消費(fèi)的消息，或者到達(dá)超時(shí)時(shí)間才會(huì)返回請(qǐng)求。返回后，客戶(hù)端又會(huì)立即再次發(fā)起下一次Long Polling。這種方式解決了Pull模式數(shù)據(jù)通知不及時(shí)的問(wèn)題，且減少了大量的無(wú)效輪詢(xún)次數(shù)。

hold住請(qǐng)求指的服務(wù)端暫時(shí)不回復(fù)結(jié)果，保持住相關(guān)請(qǐng)求，不關(guān)閉請(qǐng)求連接，等相關(guān)數(shù)據(jù)準(zhǔn)備好，再寫(xiě)回客戶(hù)端。

由此可見(jiàn)，Long-Polling模式下：

• 在Broker一直有可讀消息的情況下，Long-Polling就等價(jià)于執(zhí)行間隔為0的Pull模式（每次收到Pull結(jié)果就發(fā)起下一次Pull請(qǐng)求，當(dāng)然也可根據(jù)實(shí)際情況設(shè)置最小間隔保護(hù)時(shí)間或單批次最小消息數(shù)量）；
• 在Broker沒(méi)有可讀消息的情況下，請(qǐng)求阻塞在了Broker，在產(chǎn)生下一條消息或者請(qǐng)求“超時(shí)之前”響應(yīng)請(qǐng)求給Consumer。

3 總結(jié)

雖然Push模式在語(yǔ)義上更符合事件驅(qū)動(dòng)架構(gòu)風(fēng)格，但在當(dāng)前互聯(lián)網(wǎng)大數(shù)據(jù)量高并發(fā)的背景下，Pull模式（含Long-Polling）逐步成為主流實(shí)現(xiàn)方案。對(duì)于使用方來(lái)說(shuō)，綜合考慮兩者的差異與特性，才能做好技術(shù)選型與分析決策。