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

?Labs 導(dǎo)讀

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

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

1 消息中間件的傳輸模式

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

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

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

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

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

需要注意的是，盡管使用Queue的概念，但并代表先進(jìn)入隊列的消息，一定會被先消費(fèi)。為了提升系統(tǒng)并發(fā)性，很多MQ實(shí)現(xiàn)方案中引入了“消費(fèi)者組”的概念，隊列中的消息會被分發(fā)到不同的消費(fèi)者進(jìn)行并行處理。這意味著消息在發(fā)送的時候是有序的，但是在消費(fèi)的時候就變成無序了。一些MQ提供了“專有消費(fèi)者”或者“排他消費(fèi)者”的概念，在這種情況下，隊列中的消息僅允許一個消費(fèi)者進(jìn)行消費(fèi)。但是，這也犧牲了消息的并發(fā)消費(fèi)能力，消息量很大的情況下，將會產(chǎn)生嚴(yá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模式類似廣播消息，生產(chǎn)者將消息發(fā)布到一個主題(Topic)中，訂閱了該Topic的所有下游消費(fèi)者，都可以接收到這條消息。

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

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

Queue與Topic區(qū)別：

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

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

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

2.1 推消息模型(Push)

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

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

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

2.1.2 Push模型缺點(diǎn)

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

? Push模型存在以下問題：

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

2.2 拉消息模型(Pull)

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

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

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

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

2.2.2 Pull模型缺點(diǎn)

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

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

2.3 Push/Pull區(qū)別

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

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

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

2.5 Long-Polling

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

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

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

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

由此可見，Long-Polling模式下：

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

3 總結(jié)

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