1、引言

消息是互聯(lián)網(wǎng)信息的一種表現(xiàn)形式，是人利用計(jì)算機(jī)進(jìn)行信息傳遞的有效載體，比如即時(shí)通訊網(wǎng)壇友最熟悉的即時(shí)通訊消息就是其具體的表現(xiàn)形式之一。

消息從發(fā)送者到接收者的典型傳遞方式有兩種：
?

• 1）一種我們可以稱為即時(shí)消息：即消息從一端發(fā)出后（消息發(fā)送者）立即就可以達(dá)到另一端（消息接收者），這種方式的具體實(shí)現(xiàn)就是平時(shí)最常見的IM聊天消息；
• 2）另一種稱為延遲消息：即消息從某端發(fā)出后，首先進(jìn)入一個(gè)容器進(jìn)行臨時(shí)存儲(chǔ)，當(dāng)達(dá)到某種條件后，再由這個(gè)容器發(fā)送給另一端。

在上述“消息傳遞方式2）”中所指的這個(gè)容器的一種具體實(shí)現(xiàn)就是MQ消息隊(duì)列服務(wù)。

MQ消息隊(duì)列中間件是中大型分布式系統(tǒng)中重要的組件，它主要用來解決：應(yīng)用解耦、異步消息、流量削鋒等問題，用以實(shí)現(xiàn)高性能、高可用、可伸縮和最終一致性架構(gòu)。目前使用較多的消息隊(duì)列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。MQ消息隊(duì)列中間件已被廣泛用于電商、即時(shí)通訊、社交等各種中大型分布式應(yīng)用系統(tǒng)。

在一個(gè)典型的IM即時(shí)通訊應(yīng)用中，MQ消息隊(duì)列可以用于：
?

• 1）用戶的聊天消息離線存儲(chǔ)環(huán)節(jié)：因?yàn)镮M消息的發(fā)送屬于高吞吐場(chǎng)景，直接操縱DB很容易就把DB搞掛了，所以離線消息在落地入庫前，可以先扔到MQ消息隊(duì)列中，再由單獨(dú)部署的消費(fèi)者來有節(jié)奏地存儲(chǔ)到DB中；
• 2）用戶的行為數(shù)據(jù)收集環(huán)節(jié)：因?yàn)橛脩舻牧奶煜⒑椭噶畹?#xff0c;可以用于大數(shù)據(jù)分析，而且基于國(guó)家監(jiān)管要求也是必須要存儲(chǔ)一段時(shí)間的，所以此類數(shù)據(jù)的收集同樣可以用于MQ消息隊(duì)列，再由單獨(dú)部署的消費(fèi)者存儲(chǔ)到DB中；
• 3）用戶的操作日志收集環(huán)節(jié)：log這種數(shù)據(jù)價(jià)值不高，但關(guān)鍵時(shí)刻又非常有用，而且數(shù)據(jù)量又很大，要想存儲(chǔ)起來難度很高，這時(shí)就輪到Linkedin公司開源的Kafka出場(chǎng)了；
• ....

因此，對(duì)于即時(shí)通訊開發(fā)者來說，正確地理解MQ消息隊(duì)列，對(duì)于IM或消息推送系統(tǒng)的架構(gòu)設(shè)計(jì)、方案選型等都大有裨益。

2、系列文章

• 《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫讀寫分離原理及實(shí)踐建議》
• 《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

3、MQ消息隊(duì)列的典型應(yīng)用場(chǎng)景

MQ消息隊(duì)列目前在中大型分布式系統(tǒng)實(shí)際應(yīng)用中常用的使用場(chǎng)景主要有：異步處理、應(yīng)用解耦、流量削鋒和消息通訊四個(gè)場(chǎng)景。
?

3.1應(yīng)用場(chǎng)景1：異步處理

場(chǎng)景說明：一個(gè)典型的IM即時(shí)通訊系統(tǒng)中，用戶注冊(cè)成功后可能需要發(fā)送注冊(cè)郵件和注冊(cè)通知短信。

傳統(tǒng)的做法有兩種：
?

• 1）串行的方式：即將注冊(cè)信息寫入數(shù)據(jù)庫成功后、發(fā)送注冊(cè)郵件、再發(fā)送注冊(cè)短信。以上三個(gè)任務(wù)全部完成后，返回給客戶端；
• 2）并行方式：即將注冊(cè)信息寫入數(shù)據(jù)庫成功后，發(fā)送注冊(cè)郵件的同時(shí)，發(fā)送注冊(cè)短信。以上三個(gè)任務(wù)完成后，返回給客戶端。與串行的差別是，并行的方式可以提高處理的時(shí)間。

假設(shè)三個(gè)業(yè)務(wù)節(jié)點(diǎn)每個(gè)使用50毫秒，不考慮網(wǎng)絡(luò)等其他開銷，則串行方式的時(shí)間是150毫秒，并行的時(shí)間可能是100毫秒。

因?yàn)镃PU在單位時(shí)間內(nèi)處理的請(qǐng)求數(shù)是一定的，假設(shè)CPU1秒內(nèi)吞吐量是100次。則串行方式1秒內(nèi)CPU可處理的請(qǐng)求量是7次（1000/150）。并行方式處理的請(qǐng)求量是10次（1000/100）。

小結(jié)：如以上案例描述，傳統(tǒng)的方式系統(tǒng)的性能（并發(fā)量，吞吐量，響應(yīng)時(shí)間）會(huì)有瓶頸。

如何解決這個(gè)問題呢？答案是：引入消息隊(duì)列，將不是必須的業(yè)務(wù)邏輯，異步處理。

改造后的架構(gòu)如下：

按照以上約定，用戶的響應(yīng)時(shí)間相當(dāng)于是注冊(cè)信息寫入數(shù)據(jù)庫的時(shí)間，也就是50毫秒。注冊(cè)郵件，發(fā)送短信寫入消息隊(duì)列后，直接返回，因此寫入消息隊(duì)列的速度很快，基本可以忽略，因此用戶的響應(yīng)時(shí)間可能是50毫秒。因此架構(gòu)改變后，系統(tǒng)的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了兩倍。
?

3.2應(yīng)用場(chǎng)景2：應(yīng)用解耦

場(chǎng)景說明：一個(gè)典型的電商購物系統(tǒng)中，用戶下訂單后，訂單系統(tǒng)需要通知庫存系統(tǒng)。

傳統(tǒng)的做法是：訂單系統(tǒng)調(diào)用庫存系統(tǒng)的接口。如下圖所示：

傳統(tǒng)模式的缺點(diǎn)：假如庫存系統(tǒng)無法訪問，則訂單減庫存將失敗，從而導(dǎo)致訂單失敗，訂單系統(tǒng)與庫存系統(tǒng)耦合。

如何解決以上問題呢？答案是：引入應(yīng)用消息隊(duì)列后的方案。如下圖：

如上圖所示，大致的原理是：
?

• 訂單系統(tǒng)：用戶下單后，訂單系統(tǒng)完成持久化處理，將消息寫入消息隊(duì)列，返回用戶訂單下單成功；
• 庫存系統(tǒng)：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫存系統(tǒng)根據(jù)下單信息，進(jìn)行庫存操作。

好處就是：假如在下單時(shí)庫存系統(tǒng)不能正常使用，也不影響正常下單，因?yàn)橄聠魏?#xff0c;訂單系統(tǒng)寫入消息隊(duì)列就不再關(guān)心其他的后續(xù)操作了。實(shí)現(xiàn)訂單系統(tǒng)與庫存系統(tǒng)的應(yīng)用解耦。
?

3.3應(yīng)用場(chǎng)景3：流量削鋒

流量削鋒也是消息隊(duì)列中的常用場(chǎng)景，一般在電商秒殺等大型活動(dòng)（比如雙11）、團(tuán)購搶單活動(dòng)中使用廣泛。

應(yīng)用場(chǎng)景：秒殺活動(dòng)，一般會(huì)因?yàn)榱髁窟^大，導(dǎo)致流量暴增，應(yīng)用掛掉。為解決這個(gè)問題，一般需要在應(yīng)用前端加入消息隊(duì)列。

在這種場(chǎng)景下加入消息隊(duì)列服務(wù)的好處：
?

• 1）可以控制活動(dòng)的人數(shù)；
• 2）可以緩解短時(shí)間內(nèi)高流量壓垮應(yīng)用。

用戶的請(qǐng)求，服務(wù)器接收后，首先寫入消息隊(duì)列。假如消息隊(duì)列長(zhǎng)度超過最大數(shù)量，則直接拋棄用戶請(qǐng)求或跳轉(zhuǎn)到錯(cuò)誤頁面。秒殺業(yè)務(wù)根據(jù)消息隊(duì)列中的請(qǐng)求信息，再做后續(xù)處理。
?

3.4應(yīng)用場(chǎng)景4：日志處理

日志處理是指將消息隊(duì)列用在日志處理中，比如Linkedin這種大型職業(yè)社交應(yīng)用架構(gòu)中Kafka的應(yīng)用（Kafka就是Linkedin開發(fā)并開源的），解決大量日志傳輸?shù)膯栴}。

使用Kafka后的架構(gòu)簡(jiǎn)化如下：

上圖所示的架構(gòu)原理就是：
?

• 日志采集客戶端：負(fù)責(zé)日志數(shù)據(jù)采集，定時(shí)寫入Kafka隊(duì)列；
• Kafka消息隊(duì)列：負(fù)責(zé)日志數(shù)據(jù)的接收，存儲(chǔ)和轉(zhuǎn)發(fā)；
• 日志處理應(yīng)用：訂閱并消費(fèi)kafka隊(duì)列中的日志數(shù)據(jù)。

?

3.5應(yīng)用場(chǎng)景5：即時(shí)消息通訊

即時(shí)消息通訊是指，消息隊(duì)列一般都內(nèi)置了高效的通信機(jī)制，因此也可以用在純的即時(shí)消息通訊場(chǎng)景。比如實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)消息隊(duì)列或者IM聊天室等（但Jack Jiang認(rèn)為，在中大型IM系統(tǒng)中，MQ并不適合這么用，具體的討論請(qǐng)見：《請(qǐng)教可以使用MQ消息隊(duì)列中間件做即時(shí)通訊系統(tǒng)嗎？》）。

• 點(diǎn)對(duì)點(diǎn)通訊：客戶端A和客戶端B使用同一隊(duì)列，進(jìn)行消息通訊；
• 聊天室通訊：客戶端A，客戶端B，客戶端N訂閱同一主題，進(jìn)行消息發(fā)布和接收。實(shí)現(xiàn)類似聊天室效果。

以上實(shí)際是消息隊(duì)列的兩種消息模式，點(diǎn)對(duì)點(diǎn)或發(fā)布訂閱模式。模型為示意圖，供參考。

4、MQ消息隊(duì)列的常見消息模式

常見的MQ消息隊(duì)列消息模式有：
?

• 1）P2P模式；
• 2）Pub/sub模式（也就是常說的“發(fā)布/訂閱”模式）；
• 3）推(Push)模式和拉(Pull)模式。

下面將逐個(gè)介紹這幾種常消息模式。
?

4.1P2P模式

P2P模式包含三個(gè)角色：
?

• 1）消息隊(duì)列（Queue）；
• 2）發(fā)送者(Sender)；
• 3）接收者(Receiver)。

每個(gè)消息都被發(fā)送到一個(gè)特定的隊(duì)列，接收者從隊(duì)列中獲取消息。隊(duì)列保留著消息，直到他們被消費(fèi)或超時(shí)。

P2P消息模式的特點(diǎn)：

每個(gè)消息只有一個(gè)消費(fèi)者（Consumer）(即一旦被消費(fèi)，消息就不再在消息隊(duì)列中)發(fā)送者和接收者之間在時(shí)間上沒有依賴性，也就是說當(dāng)發(fā)送者發(fā)送了消息之后，不管接收者有沒有正在運(yùn)行，它不會(huì)影響到消息被發(fā)送到隊(duì)列接收者在成功接收消息之后需向隊(duì)列應(yīng)答成功 如果希望發(fā)送的每個(gè)消息都會(huì)被成功處理的話，那么需要P2P模式。

?

4.2Pub/sub模式

如上圖所示，此消息模式包含三個(gè)角色：
?

• 1）主題（Topic）；
• 2）發(fā)布者（Publisher）；
• 3）訂閱者（Subscriber）。

多個(gè)發(fā)布者將消息發(fā)送到Topic，系統(tǒng)將這些消息傳遞給多個(gè)訂閱者。

Pub/Sub的特點(diǎn)：

每個(gè)消息可以有多個(gè)消費(fèi)者發(fā)布者和訂閱者之間有時(shí)間上的依賴性。針對(duì)某個(gè)主題（Topic）的訂閱者，它必須創(chuàng)建一個(gè)訂閱者之后，才能消費(fèi)發(fā)布者的消息。為了消費(fèi)消息，訂閱者必須保持運(yùn)行的狀態(tài)。為了緩和這樣嚴(yán)格的時(shí)間相關(guān)性，有些MQ消息隊(duì)列（比如RabbitMQ）允許訂閱者創(chuàng)建一個(gè)可持久化的訂閱。這樣，即使訂閱者沒有被激活（運(yùn)行），它也能接收到發(fā)布者的消息。如果希望發(fā)送的消息可以不被做任何處理、或者只被一個(gè)消息者處理、或者可以被多個(gè)消費(fèi)者處理的話，那么可以采用Pub/Sub模型。

?

4.3推模式和拉模式

推(push)模式是一種基于C/S機(jī)制、由服務(wù)器主動(dòng)將信息送到客戶器的技術(shù)。

在Push模式應(yīng)用中，服務(wù)器把信息送給客戶器之前，并沒有明顯的客戶請(qǐng)求。push事務(wù)由服務(wù)器發(fā)起。push模式可以讓信息主動(dòng)、快速地尋找用戶/客戶器，信息的主動(dòng)性和實(shí)時(shí)性比較好。但精確性較差，可能推送的信息并不一定滿足客戶的需求。

Push模式不能保證能把信息送到客戶器，因?yàn)橥颇Ｊ讲捎昧藦V播機(jī)制，如果客戶器正好聯(lián)網(wǎng)并且和服務(wù)器在同一個(gè)頻道上，推送模式才是有效的。

Push模式無法跟蹤狀態(tài)，采用了開環(huán)控制模式，沒有用戶反饋信息。在實(shí)際應(yīng)用中，由客戶器向服務(wù)器發(fā)送一個(gè)申請(qǐng)，并把自己的地址（如IP、port）告知服務(wù)器，然后服務(wù)器就源源不斷地把信息推送到指定地址。在多媒體信息廣播中也采用了推模式。

拉(Pull)模式與推(Push)模式相反，是由客戶器主動(dòng)發(fā)起的事務(wù)。服務(wù)器把自己所擁有的信息放在指定地址（如IP、port），客戶器向指定地址發(fā)送請(qǐng)求，把自己需要的資源“拉”回來。不僅可以準(zhǔn)確獲取自己需要的資源，還可以及時(shí)把客戶端的狀態(tài)反饋給服務(wù)器。

5、主流的MQ消息隊(duì)列技術(shù)選型對(duì)比

一份主流MQ技術(shù)對(duì)比清單：

?

?

5.1Kafka

Kafka是Linkedin開源的MQ系統(tǒng)（現(xiàn)已是Apache下的一個(gè)子項(xiàng)目），它是一個(gè)高性能跨語言分布式發(fā)布/訂閱消息隊(duì)列系統(tǒng)，主要特點(diǎn)是基于Pull的模式來處理消息消費(fèi)，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，0.8開始支持復(fù)制，不支持事務(wù)，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。

Kafka還具有以下特性：
?

• 1）快速持久化，可以在O(1)的系統(tǒng)開銷下進(jìn)行消息持久化；
• 2）高吞吐，在一臺(tái)普通的服務(wù)器上既可以達(dá)到10W/s的吞吐速率；
• 3）完全的分布式系統(tǒng)，Broker、Producer、Consumer都原生自動(dòng)支持分布式，自動(dòng)實(shí)現(xiàn)負(fù)載均衡；
• 4）支持Hadoop數(shù)據(jù)并行加載，對(duì)于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實(shí)時(shí)處理的限制，這是一個(gè)可行的解決方案。Kafka通過Hadoop的并行加載機(jī)制統(tǒng)一了在線和離線的消息處理。

Apache Kafka相對(duì)于ActiveMQ是一個(gè)非常輕量級(jí)的消息系統(tǒng)，除了性能非常好之外，還是一個(gè)工作良好的分布式系統(tǒng)。
?

5.2RabbitMQ

RabbitMQ是使用Erlang語言開發(fā)的開源消息隊(duì)列系統(tǒng)，基于AMQP協(xié)議來實(shí)現(xiàn)。AMQP的主要特征是面向消息、隊(duì)列、路由（包括點(diǎn)對(duì)點(diǎn)和發(fā)布/訂閱）、可靠性、安全。AMQP協(xié)議更多用在企業(yè)系統(tǒng)內(nèi)，對(duì)數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場(chǎng)景，對(duì)性能和吞吐量的要求還在其次。

RabbitMQ本身支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級(jí)，更適合于企業(yè)級(jí)的開發(fā)。同時(shí)實(shí)現(xiàn)了Broker構(gòu)架，這意味著消息在發(fā)送給客戶端時(shí)先在中心隊(duì)列排隊(duì)。對(duì)路由，負(fù)載均衡或者數(shù)據(jù)持久化都有很好的支持。
?

5.3RocketMQ

RocketMQ是阿里開源的消息中間件，它是純Java開發(fā)，具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點(diǎn)。RocketMQ思路起源于Kafka，但并不是Kafka的一個(gè)Copy，它對(duì)消息的可靠傳輸及事務(wù)性做了優(yōu)化，目前在阿里集團(tuán)被廣泛應(yīng)用于交易、充值、流計(jì)算、消息推送、日志流式處理、binglog分發(fā)等場(chǎng)景。
?

5.4ZeroMQ

ZeroMQ只是一個(gè)網(wǎng)絡(luò)編程的Pattern庫，將常見的網(wǎng)絡(luò)請(qǐng)求形式（分組管理，鏈接管理，發(fā)布訂閱等）模式化、組件化，簡(jiǎn)而言之socket之上、MQ之下。對(duì)于MQ來說，網(wǎng)絡(luò)傳輸只是它的一部分，更多需要處理的是消息存儲(chǔ)、路由、Broker服務(wù)發(fā)現(xiàn)和查找、事務(wù)、消費(fèi)模式（ack、重投等）、集群服務(wù)等。

ZeroMQ是號(hào)稱最快的消息隊(duì)列系統(tǒng)，尤其針對(duì)大吞吐量的需求場(chǎng)景。ZeroMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長(zhǎng)的高級(jí)/復(fù)雜的隊(duì)列，但是開發(fā)人員需要自己組合多種技術(shù)框架，技術(shù)上的復(fù)雜度是對(duì)這MQ能夠應(yīng)用成功的挑戰(zhàn)。ZeroMQ具有一個(gè)獨(dú)特的非中間件的模式，你不需要安裝和運(yùn)行一個(gè)消息服務(wù)器或中間件，因?yàn)槟愕膽?yīng)用程序?qū)缪葸@個(gè)服務(wù)器角色。你只需要簡(jiǎn)單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應(yīng)用程序之間發(fā)送消息了。但是ZeroMQ僅提供非持久性的隊(duì)列，也就是說如果宕機(jī)，數(shù)據(jù)將會(huì)丟失。其中，Twitter的Storm 0.9.0以前的版本中默認(rèn)使用ZeroMQ作為數(shù)據(jù)流的傳輸（Storm從0.9版本開始同時(shí)支持ZeroMQ和Netty作為傳輸模塊）。
?

5.5小結(jié)

RabbitMQ/Kafka/ZeroMQ 都能提供消息隊(duì)列服務(wù)，但有很大的區(qū)別。

在面向服務(wù)架構(gòu)中通過消息代理（比如 RabbitMQ / Kafka等），使用生產(chǎn)者-消費(fèi)者模式在服務(wù)間進(jìn)行異步通信是一種比較好的思想。

因?yàn)榉?wù)間依賴由強(qiáng)耦合變成了松耦合。消息代理都會(huì)提供持久化機(jī)制，在消費(fèi)者負(fù)載高或者掉線的情況下會(huì)把消息保存起來，不會(huì)丟失。就是說生產(chǎn)者和消費(fèi)者不需要同時(shí)在線，這是傳統(tǒng)的請(qǐng)求-應(yīng)答模式比較難做到的，需要一個(gè)中間件來專門做這件事。其次消息代理可以根據(jù)消息本身做簡(jiǎn)單的路由策略，消費(fèi)者可以根據(jù)這個(gè)來做負(fù)載均衡，業(yè)務(wù)分離等。

缺點(diǎn)也有，就是需要額外搭建消息代理集群（但優(yōu)點(diǎn)是大于缺點(diǎn)的 ） 。

ZeroMQ 和 RabbitMQ/Kafka 不同，它只是一個(gè)異步消息庫，在套接字的基礎(chǔ)上提供了類似于消息代理的機(jī)制。使用 ZeroMQ 的話，需要對(duì)自己的業(yè)務(wù)代碼進(jìn)行改造，不利于服務(wù)解耦。

RabbitMQ 支持 AMQP（二進(jìn)制），STOMP（文本），MQTT（二進(jìn)制），HTTP（里面包裝其他協(xié)議）等協(xié)議。Kafka 使用自己的協(xié)議。

Kafka 自身服務(wù)和消費(fèi)者都需要依賴 Zookeeper。

RabbitMQ 在有大量消息堆積的情況下性能會(huì)下降，Kafka不會(huì)。畢竟AMQP設(shè)計(jì)的初衷不是用來持久化海量消息的，而Kafka一開始是用來處理海量日志的。

總的來說，RabbitMQ 和 Kafka 都是十分優(yōu)秀的分布式的消息代理服務(wù)，只要合理部署，基本上可以滿足生產(chǎn)條件下的任何需求。
?

網(wǎng)易云信，你身邊的即時(shí)通訊和音視頻技術(shù)專家，了解我們，請(qǐng)戳網(wǎng)易云信官網(wǎng)

想要行業(yè)洞察和技術(shù)干貨，請(qǐng)關(guān)注網(wǎng)易云信博客

本文轉(zhuǎn)載自52im,作者：JackJiang

總結(jié)

以上是生活随笔為你收集整理的IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。