一、什么是消息隊列

消息隊列，英文名：Message Queue，經常縮寫為MQ。從字面上來理解，消息隊列是一種用來存儲消息的隊列 。來看一下下面的代碼

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

總結:消息隊列指的就是將數據放置到一個隊列中, 從隊列一端進入, 然后從另一端流出的過程

二、消息隊列的應用場景

消息隊列在實際應用中包括如下四個場景：

1、應用耦合：

多應用間通過消息隊列對同一消息進行處理，避免調用接口失敗導致整個過程失??；

2、異步處理：

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

3、限流削峰：

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

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

系統(tǒng)分為消息隊列、消息生產者、消息消費者，生產者負責產生消息，消費者(可能有多個)負責對消息進行處理

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

異步處理

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

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

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

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

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

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

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

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

                              并行： 50+50 = 100ms

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

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

應用耦合

具體場景：

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

該方法有如下缺點:

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

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

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

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

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

限流削峰

具體場景：

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

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

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

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

消息驅動系統(tǒng)

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

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

避免了直接調用下一個系統(tǒng)導致當前系統(tǒng)失敗；

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

三、消息隊列的兩種方式

點對點模式

點對點模式下包括三個角色

• 消息隊列
• 發(fā)送者 (生產者)
• 接收者（消費者）

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

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

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

接收者在成功接收消息之后需向隊列應答成功，以便消息隊列刪除當前接收的消息；

發(fā)布/訂閱模式

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

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

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

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

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

為了消費消息，訂閱者需要提前訂閱該角色主題，并保持在線運行；

四、常見的消息隊列的產品

1) RabbitMQ

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

2) activeMQ:

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

3) RocketMQ

RocketMQ 出自 阿里公司的開源產品，用 Java 語言實現，在設計時參考了 Kafka ，并做出了自己的一些改進，消息可靠性上比 Kafka 更好。 RocketMQ 在阿里集團被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理 等

4) kafka

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

五、Kafka的基本介紹

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

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

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

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

kakfa的特點:

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

apache kafka 是一個分布式發(fā)布 - 訂閱消息系統(tǒng)和一個強大的隊列，可以處理大量的數據，并使能夠將消息從一個 端點傳遞到另一個端點，kafka 適合離線和在線消息消費。 kafka 消息保留在磁盤上，并在集群內復制以防止數據丟失。kafka構建在 zookeeper 同步服務之上。它與 apache 和 spark 非常好的集成，應用于實時流式數據分析。

kafka的主要應用場景:

1) 指標分析 : kafka 通常用于操作監(jiān)控數據 , 這設計聚合來自分布式應用程序和統(tǒng)計信息 , 以產生操作的數據集中反饋

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

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

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

最新評論