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

?Labs 導讀

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

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

1 消息中間件的傳輸模式

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

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

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

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

圖1.1 點對點模型

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

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

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

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

圖1.2 發布/訂閱模型

Queue與Topic區別：

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

2 消息中間件的消費模式

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

2.1 推消息模型(Push)

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

2.1.1 Push模型優點

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

2.1.2 Push模型缺點

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

? Push模型存在以下問題：

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

2.2 拉消息模型(Pull)

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

2.2.1 Pull模型優點

相較于Push模型，Pull模型存在以下優勢：

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

2.2.2 Pull模型缺點

優勢的反面即時劣勢，Pull模型存在以下缺點：

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

2.3 Push/Pull區別

? 在實際應用場景中：

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

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

2.5 Long-Polling

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

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

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

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

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

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

3 總結

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