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

?Labs 導讀

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

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

1 消息中間件的傳輸模式

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

1.1 點對點(Point-to-Point，PTP)

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

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

圖1.1 點對點模型

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

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

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

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

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

Queue與Topic區(qū)別：

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

2 消息中間件的消費模式

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

2.1 推消息模型(Push)

消息生產者將消息發(fā)送給消息服務器后，消息服務器主動地將消息“推送”給消費者。

2.1.1 Push模型優(yōu)點

Push模型最大的好處就是實時性。因為服務端可以做到只要有消息就立即推送，所以消息的消費沒有“額外”的延遲。

2.1.2 Push模型缺點

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

? Push模型存在以下問題：

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

2.2 拉消息模型(Pull)

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

2.2.1 Pull模型優(yōu)點

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

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

2.2.2 Pull模型缺點

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

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

2.3 Push/Pull區(qū)別

? 在實際應用場景中：

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

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

2.5 Long-Polling

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

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

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

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

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

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

3 總結

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