一、什么是消息隊(duì)列

消息隊(duì)列，英文名：Message Queue，經(jīng)?？s寫為MQ。從字面上來理解，消息隊(duì)列是一種用來存儲消息的隊(duì)列 。來看一下下面的代碼

上述代碼，創(chuàng)建了一個隊(duì)列，先往隊(duì)列中添加了一個消息，然后又從隊(duì)列中取出了一個消息。這說明了隊(duì)列是可以用來存取消息的

總結(jié):消息隊(duì)列指的就是將數(shù)據(jù)放置到一個隊(duì)列中, 從隊(duì)列一端進(jìn)入, 然后從另一端流出的過程

二、消息隊(duì)列的應(yīng)用場景

消息隊(duì)列在實(shí)際應(yīng)用中包括如下四個場景：

1、應(yīng)用耦合：

多應(yīng)用間通過消息隊(duì)列對同一消息進(jìn)行處理，避免調(diào)用接口失敗導(dǎo)致整個過程失??；

2、異步處理：

多應(yīng)用對消息隊(duì)列中同一消息進(jìn)行處理，應(yīng)用間并發(fā)處理消息，相比串行處理，減少處理時間；

3、限流削峰：

廣泛應(yīng)用于秒殺或搶購活動中，避免流量過大導(dǎo)致應(yīng)用系統(tǒng)掛掉的情況；

4、消息驅(qū)動的系統(tǒng)：

系統(tǒng)分為消息隊(duì)列、消息生產(chǎn)者、消息消費(fèi)者，生產(chǎn)者負(fù)責(zé)產(chǎn)生消息，消費(fèi)者(可能有多個)負(fù)責(zé)對消息進(jìn)行處理

下面詳細(xì)介紹上述四個場景以及消息隊(duì)列如何在上述四個場景中使用

異步處理

具體場景：用戶為了使用某個應(yīng)用，進(jìn)行注冊，系統(tǒng)需要發(fā)送注冊郵件并驗(yàn)證短信。

對這兩個操作的處理方式有兩種：串行及并行。

1) 串行方式: 新注冊信息生成后 , 先發(fā)送注冊郵件, 再發(fā)送驗(yàn)證短信

注意 : 在這種方式下，需要最終發(fā)送驗(yàn)證短信后再返回給客戶端

2) 并行處理：新注冊信息寫入后，由發(fā)短信和發(fā)郵件并行處理

注意: 在這種方式下，發(fā)短信和發(fā)郵件 需處理完成后再返回給客戶端。

假設(shè)以上三個子系統(tǒng)處理的時間均為 50ms ，且不考慮網(wǎng)絡(luò)延遲

則總的處理時間： 串行： 50+50+50=150ms ​

                              并行： 50+50 = 100ms

如果引入消息隊(duì)列 , 在來看整體的執(zhí)行效率 :

在寫入消息隊(duì)列后立即返回成功給客戶端，則總的響應(yīng)時間依賴于寫入消息隊(duì)列的時間，而寫入消息隊(duì)列的時間本身是可以很快的，基本可以忽略不計(jì)，因此總的處理時間相比串行提高了2倍，相比并行提高了一倍；

應(yīng)用耦合

具體場景：

用戶使用 QQ 相冊上傳一張圖片，人臉識別系統(tǒng)會對該圖片進(jìn)行人臉識別，一般的做法是，服務(wù)器接收到圖片后，圖片上傳系統(tǒng)立即調(diào)用人臉識別系統(tǒng)，調(diào)用完成后再返回成功，如下圖所示: 如果引入消息隊(duì)列 , 在來看整體的執(zhí)行效率

該方法有如下缺點(diǎn):

1) 人臉識別系統(tǒng)被調(diào)失敗，導(dǎo)致圖片上傳失敗；

2) 延遲高，需要人臉識別系統(tǒng)處理完成后，再返回給客戶端，即使用戶并不需要立即知道結(jié)果；

3) 圖片上傳系統(tǒng)與人臉識別系統(tǒng)之間互相調(diào)用，需要做耦合； 若使用消息隊(duì)列:

此時圖片上傳系統(tǒng)并不需要關(guān)心人臉識別系統(tǒng)是否對這些圖片信息的處理、以及何時對這些圖片信息進(jìn)行處理。

事實(shí)上，由于用戶并不需要立即知道人臉識別結(jié)果，人臉識別系統(tǒng)可以選擇不同的調(diào)度策略，按照閑時、忙時、正常時 間，對隊(duì)列中的圖片信息進(jìn)行處理。

限流削峰

具體場景：

購物網(wǎng)站開展秒殺活動，一般由于瞬時訪問量過大，服務(wù)器接收過大，會導(dǎo)致流量暴增，相關(guān)系統(tǒng)無法處理請求甚至崩潰。而加入消息隊(duì)列后，系統(tǒng)可以從消息隊(duì)列中取數(shù)據(jù)，相當(dāng)于消息隊(duì)列做了一次緩沖。

該方法有如下優(yōu)點(diǎn)：

請求先入消息隊(duì)列，而不是由業(yè)務(wù)處理系統(tǒng)直接處理，做了一次緩沖 , 極大地減少了業(yè)務(wù)處理系統(tǒng)的壓力；

隊(duì)列長度可以做限制，事實(shí)上，秒殺時，后入隊(duì)列的用戶無法秒殺到商品，這些請求可以直接被拋棄，返回活動已結(jié)束或商品已售完信息；

消息驅(qū)動系統(tǒng)

具體場景：用戶新上傳了一批照片， 人臉識別系統(tǒng)需要對這個用戶的所有照片進(jìn)行聚類，聚類完成后由對賬系統(tǒng)重新生成用 戶的人臉?biāo)饕? 加快查詢 ) 。這三個子系統(tǒng)間由消息隊(duì)列連接起來，前一個階段的處理結(jié)果放入隊(duì)列中，后一個階段從隊(duì)列中獲取消息繼續(xù)處理。

該方法有如下優(yōu)點(diǎn)：

避免了直接調(diào)用下一個系統(tǒng)導(dǎo)致當(dāng)前系統(tǒng)失?。?/p>

每個子系統(tǒng)對于消息的處理方式可以更為靈活，可以選擇收到消息時就處理，可以選擇定時處理，也可以劃分時間 段按不同處理速度處理；

三、消息隊(duì)列的兩種方式

點(diǎn)對點(diǎn)模式

點(diǎn)對點(diǎn)模式下包括三個角色

• 消息隊(duì)列
• 發(fā)送者 (生產(chǎn)者)
• 接收者（消費(fèi)者）

消息發(fā)送者生產(chǎn)消息發(fā)送到 queue 中，然后消息接收者從 queue 中取出并且消費(fèi)消息。消息被消費(fèi)以后， queue 中不再有存儲，所以消息接收者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息。 點(diǎn)對點(diǎn)模式特點(diǎn)：

每個消息只有一個接收者（Consumer）(即一旦被消費(fèi)，消息就不再在消息隊(duì)列中)；

發(fā)送者和接收者間沒有依賴性，發(fā)送者發(fā)送消息之后，不管有沒有接收者在運(yùn)行，都不會影響到發(fā)送者下次發(fā)送消息；

接收者在成功接收消息之后需向隊(duì)列應(yīng)答成功，以便消息隊(duì)列刪除當(dāng)前接收的消息；

發(fā)布/訂閱模式

發(fā)布 / 訂閱模式下包括三個角色：

• 角色主題（Topic）
• 發(fā)布者(Publisher)
• 訂閱者(Subscriber)

發(fā)布者將消息發(fā)送到 Topic, 系統(tǒng)將這些消息傳遞給多個訂閱者。 發(fā)布 / 訂閱模式特點(diǎn)：

每個消息可以有多個訂閱者；

發(fā)布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創(chuàng)建一個訂閱者之后，才能消費(fèi)發(fā)布者的消息。

為了消費(fèi)消息，訂閱者需要提前訂閱該角色主題，并保持在線運(yùn)行；

四、常見的消息隊(duì)列的產(chǎn)品

1) RabbitMQ

RabbitMQ 2007 年發(fā)布，是一個在 AMQP ( 高級消息隊(duì)列協(xié)議 ) 基礎(chǔ)上完成的，可復(fù)用的企業(yè)消息系統(tǒng)，是當(dāng)前最主 流的消息中間件之一。

2) activeMQ:

ActiveMQ 是由 Apache 出品， ActiveMQ 是一個完全支持 JMS1.1 和 J2EE 1.4 規(guī)范的 JMS Provider 實(shí)現(xiàn)。它非?？焖?，支持多種語言的客戶端和協(xié)議，而且可以非常容易的嵌入到企業(yè)的應(yīng)用環(huán)境中，并有許多高級功能, 目前市場的活躍 度比較低, 在 java 領(lǐng)域正在被 RabbitMQ 替代

3) RocketMQ

RocketMQ 出自 阿里公司的開源產(chǎn)品，用 Java 語言實(shí)現(xiàn)，在設(shè)計(jì)時參考了 Kafka ，并做出了自己的一些改進(jìn)，消息可靠性上比 Kafka 更好。 RocketMQ 在阿里集團(tuán)被廣泛應(yīng)用在訂單，交易，充值，流計(jì)算，消息推送，日志流式處理 等

4) kafka

Apache Kafka 是一個分布式消息發(fā)布訂閱系統(tǒng)。它最初由 LinkedIn 公司基于獨(dú)特的設(shè)計(jì)實(shí)現(xiàn)為一個分布式的提交日志系統(tǒng)( a distributed commit log) ，之后成為 Apache 項(xiàng)目的一部分。 Kafka 系統(tǒng)快速、可擴(kuò)展并且可持久化。它的分區(qū)特性，可復(fù)制和可容錯都是其不錯的特性。 各種消息隊(duì)列產(chǎn)品的對比圖：

五、Kafka的基本介紹

kafka 是最初由 linkedin 公司開發(fā)的，使用 scala 語言編寫， kafka 是一個分布式，分區(qū)的，多副本的，多訂閱者的日 志系統(tǒng)（分布式MQ 系統(tǒng)），可以用于搜索日志，監(jiān)控日志，訪問日志等 Kafka is a distributed,partitioned,replicated commit logservice 。

它提供了類似于 JMS 的特性，但是在設(shè)計(jì)實(shí)現(xiàn)上完全不同，此外它并不是JMS 規(guī)范的完整實(shí)現(xiàn)。

kafka 對消息保存時根據(jù) Topic 進(jìn)行歸類，發(fā)送消息者成為 Producer, 消息 接受者成為Consumer, 此外 kafka 集群有多個 kafka 實(shí)例組成，每個實(shí)例 (server) 成為 broker 。

無論是 kafka 集群，還是producer和 consumer 都依賴于 zookeeper 來保證系統(tǒng)可用性集群保存一些 meta 信息

kakfa的特點(diǎn):

• 可靠性: 分布式, 分區(qū) , 復(fù)制 和容錯等
• 可擴(kuò)展性: kakfa消息傳遞系統(tǒng)輕松縮放, 無需停機(jī)
• 耐用性: kafka使用分布式提交日志, 這個意味著消息會盡可能快速的保存在磁盤上, 因此它是持久的
• 性能: kafka對于發(fā)布和訂閱消息都具有高吞吐量, 即使存儲了許多TB的消息, 他也爆出穩(wěn)定的性能-kafka非常快: 保證零停機(jī)和零數(shù)據(jù)丟失

apache kafka 是一個分布式發(fā)布 - 訂閱消息系統(tǒng)和一個強(qiáng)大的隊(duì)列，可以處理大量的數(shù)據(jù)，并使能夠?qū)⑾囊粋€ 端點(diǎn)傳遞到另一個端點(diǎn)，kafka 適合離線和在線消息消費(fèi)。 kafka 消息保留在磁盤上，并在集群內(nèi)復(fù)制以防止數(shù)據(jù)丟失。kafka構(gòu)建在 zookeeper 同步服務(wù)之上。它與 apache 和 spark 非常好的集成，應(yīng)用于實(shí)時流式數(shù)據(jù)分析。

kafka的主要應(yīng)用場景:

1) 指標(biāo)分析 : kafka 通常用于操作監(jiān)控?cái)?shù)據(jù) , 這設(shè)計(jì)聚合來自分布式應(yīng)用程序和統(tǒng)計(jì)信息 , 以產(chǎn)生操作的數(shù)據(jù)集中反饋

2) 日志聚合解決方法 : kafka 可用于跨組織從多個服務(wù)器收集日志 , 并使他們一標(biāo)準(zhǔn)的合適提供給多個服務(wù)器

3) 流式處理 : 流式的處理框架 (spark, storm , flink) 從主題中讀取數(shù)據(jù) , 對其進(jìn)行處理 , 并將處理后的結(jié)果數(shù)據(jù)寫入新的主題, 供用戶和應(yīng)用程序使用 , kafka 的強(qiáng)耐久性在流處理的上下文中也非常的有用

到此這篇關(guān)于大數(shù)據(jù)Kafka:消息隊(duì)列和Kafka基本介紹的文章就介紹到這了,更多相關(guān)大數(shù)據(jù)消息隊(duì)列和Kafka內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論