建站
咨詢
售后
建站咨詢
新聞中心
作者 | 葛賢亮，單位：中國移動智慧家庭運營中心
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(liá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)識。本期由“傳輸模式”與“消費模式”切入，期望能以點見面使讀者對消息中間件有更深入的了解。
1 消息中間件的傳輸模式
從傳輸視角看，MQ的消息模式可分為“點對點”和“發(fā)布/訂閱”兩種模式。
1.1 點對點(Point-to-Point，PTP)
顧名思義，PTP模型用于消息生產(chǎn)者和消息消費者之間點對點的通信。消息生產(chǎn)者基于某種規(guī)則將消息發(fā)送到特定的消費者，通常是某個固定的消息隊列(Queue)，在消息傳遞給消費者之前它被存儲在這個隊列中。隊列消息可以放在內(nèi)存中也可以持久化，以保證在消息服務(wù)出現(xiàn)故障時仍然能夠傳遞消息。
PTP模型中，一個隊列可以有多個生產(chǎn)者和多個消費者。消息服務(wù)器按照收到消息的先后順序，將消息放到隊列中。隊列中的每一條消息，只能由一個消費者進行消費，消費之后就會從隊列中移除。
圖1.1 點對點模型
需要注意的是，盡管使用Queue的概念，但并代表先進入隊列的消息，一定會被先消費。為了提升系統(tǒng)并發(fā)性，很多MQ實現(xiàn)方案中引入了“消費者組”的概念，隊列中的消息會被分發(fā)到不同的消費者進行并行處理。這意味著消息在發(fā)送的時候是有序的，但是在消費的時候就變成無序了。一些MQ提供了“專有消費者”或者“排他消費者”的概念，在這種情況下，隊列中的消息僅允許一個消費者進行消費。但是，這也犧牲了消息的并發(fā)消費能力，消息量很大的情況下，將會產(chǎn)生嚴(yán)重的消息積壓。為了解決這一問題，一些MQ方案（如 Kafka、RocketMQ）又引入了分區(qū)的概念，相同主題的消息使用不同分區(qū)進行隔離，同一分區(qū)內(nèi)的消息可以有序消費，不同分區(qū)內(nèi)的消息可以并行消費。
1.2 發(fā)布/訂閱(Publish-and-Subscribe，Pub/Sub)
Pub/Sub模式類似廣播消息，生產(chǎn)者將消息發(fā)布到一個主題(Topic)中，訂閱了該Topic的所有下游消費者，都可以接收到這條消息。
在這種模型下，發(fā)布者和訂閱者彼此無感知。相較于PTP模型中一個消息只能被一個消費者消費，Pub/Sub模型中一個消息會被發(fā)送至所有訂閱了該Topic的消費者進行消費。
圖1.2 發(fā)布/訂閱模型
Queue與Topic區(qū)別：
- Queue實現(xiàn)了負(fù)載均衡，將生產(chǎn)者生產(chǎn)的消息發(fā)送到消息隊列中，由多個消費者消費。但一個消息只能被一個消費者接受，當(dāng)沒有消費者可用時，這個消息會被保存直到有一個可用的消費者。
- Topic實現(xiàn)了發(fā)布和訂閱，當(dāng)發(fā)布一個消息時，所有訂閱這個Topic的服務(wù)都能得到這個消息；所以從1到N個訂閱者都能得到這個消息的拷貝。
2 消息中間件的消費模式
從消費視角看，MQ的消費模式可分為“Push”和“Pull”兩種模式。
2.1 推消息模型(Push)
消息生產(chǎn)者將消息發(fā)送給消息服務(wù)器后，消息服務(wù)器主動地將消息“推送”給消費者。
2.1.1 Push模型優(yōu)點
Push模型最大的好處就是實時性。因為服務(wù)端可以做到只要有消息就立即推送，所以消息的消費沒有“額外”的延遲。
2.1.2 Push模型缺點
Push模型看上去很美好，但在實際使用中卻存在很多硬傷，以至于有些MQ的Push模型底層也是依托Pull方式實現(xiàn)的。
Push模型存在以下問題：
- 在Broker端需要維護Consumer的狀態(tài)，不利于Broker去支持大量Consumer的場景；
- Consumer的消費速度不一致，由Broker進行推送難以根據(jù)不同的Consumer狀況選擇相應(yīng)的推送策略（時機）；
- Broker難以處理Consumer無法消費消息的情況（Broker無法確定Consumer的故障是短暫的還是永久的）；
- 在Consumer消費能力不足的情況下，大量的推送消息會加重Consumer的負(fù)載或者沖垮Consumer。
2.2 拉消息模型(Pull)
消息生產(chǎn)者將消息發(fā)送給消息服務(wù)器后，由消息消費者主動從消息服務(wù)器中拉取該消息。
2.2.1 Pull模型優(yōu)點
相較于Push模型，Pull模型存在以下優(yōu)勢：
- Broker不再需要維護Consumer的狀態(tài)（每一次pull都包含了偏移量等必要信息）；
- 由Consumer維護狀態(tài)，Consumer可以很容易的根據(jù)自身的負(fù)載等狀態(tài)來決定從Broker獲取消息的頻率；
- 可以實現(xiàn)消息聚合。Push模型中，Broker無法預(yù)測寫一條消息產(chǎn)生的時間，所以在收到消息之后只能立即推送給Consumer，所以無法對消息聚合后再推送給Consumer。而Pull模型中由Consumer主動獲取消息，每一次Pull時都能批量獲取Broker中的消息。
2.2.2 Pull模型缺點
優(yōu)勢的反面即時劣勢，Pull模型存在以下缺點：
- 實時性差。因為由Consumer主動Pull消息，所以實時性和Pull的周期相關(guān)，這樣就產(chǎn)生了“額外”延遲。如果通過提升Pull的執(zhí)行頻率來降低延遲，又會在沒有消息的時候產(chǎn)生大量的Pull請求（消息中間件是完全解耦的，Broker和Consumer無法預(yù)測下一條消息在什么時候產(chǎn)生）；
- Pull模型中由Consumer維護狀態(tài)，所以多個Consumer之間需要相互協(xié)調(diào)，這樣就需要引入ZooKeeper(Kafka)或者自己實現(xiàn) NameServer(RocketMQ)之類的服務(wù)來完成Consumer之間的協(xié)調(diào)工作。
2.3 Push/Pull區(qū)別
在實際應(yīng)用場景中：
- 大吞吐量的消息隊列都是采用Pull模式，而非Push模式；
- 采用Push模式，消費端的性能會影響整個消息隊列服務(wù)器的性能；
- 采用Push模式，容易造成broker的消息積壓，因為broker控制消息的推送速率，消息數(shù)量大的話，很難使每個消費者很難適應(yīng)消息推送速率；
2.4 常用消息中間件支持模型
2.5 Long-Polling
如上所述，雖然很多消息中間件都支持Push模式，但是在實現(xiàn)時其實也是采用pull方式實現(xiàn)的push語義。
比較成熟的做法是采用Long-Polling的方式，基于Push/Pull方案的優(yōu)缺點，在性能與時效性之間尋找到一個平衡點。
Long-Polling是Pull模式的變種。Pull模型中不管服務(wù)端數(shù)據(jù)有無更新，客戶端每隔定長時間拉取一次數(shù)據(jù)，可能有更新數(shù)據(jù)返回，也可能什么都沒有。Long Polling是指客戶端發(fā)起Long Polling，此時如果服務(wù)端沒有消息，會hold住請求，直到服務(wù)端有可消費的消息，或者到達超時時間才會返回請求。返回后，客戶端又會立即再次發(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ù)量）；
- 在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）逐步成為主流實現(xiàn)方案。對于使用方來說，綜合考慮兩者的差異與特性，才能做好技術(shù)選型與分析決策。
網(wǎng)站名稱：消息中間件系列介紹-傳輸與消費模式
文章起源：http://www.5511xx.com/article/ccissgd.html
