什麼是佇列？

- 什麼是訊息佇列？ -

訊息佇列就是一個佇列結構的中介軟體，也就是說訊息放入這個中介軟體之後就可以直接返回，並不需要系統立即處理，而另外會有一個程式讀取這些資料，並按順序進行逐次處理。

- 訊息佇列的優勢 -

訊息佇列的核心功能就是訊息傳遞。但由於其非同步性和訊息儲存的特定，使訊息佇列具備如下優勢：

1. 解耦

訊息佇列在處理過程中間插入了一個隱含的、基於資料的介面層，兩邊的處理過程都要實現這一介面。這允許你獨立的擴充套件或修改兩邊的處理過程，只要確保它們遵守同樣的介面約束。

2. 冗餘

有時在處理資料的時候處理過程會失敗。除非資料被持久化，否則將永遠丟失。訊息佇列把資料進行持久化直到它們已經被完全處理，透過這一方式規避了資料丟失風險。在被許多訊息佇列所採用的"插入-獲取-刪除"正規化中，在把一個訊息從佇列中刪除之前，需要你的處理過程明確的指出該訊息已經被處理完畢，確保你的資料被安全的儲存直到你使用完畢。

3. 擴充套件性

4. 靈活性 & 峰值處理能力

在訪問量劇增的情況下，你的應用仍然需要繼續發揮作用，但是這樣的突發流量並不常見；如果為以能處理這類峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用訊息佇列能夠使關鍵元件頂住增長的訪問壓力，而不是因為超出負荷的請求而完全崩潰。

5. 可恢復性

當體系的一部分元件失效，不會影響到整個系統。訊息佇列降低了程序間的耦合度，所以即使一個處理訊息的程序掛掉，加入佇列中的訊息仍然可以在系統恢復後被處理。而這種允許重試或者延後處理請求的能力通常是造就一個略感不便的使用者和一個沮喪透頂的使用者之間的區別。

6. 送達保證

訊息佇列提供的冗餘機制保證了訊息能被實際的處理，只要一個程序讀取了該佇列即可。

7.排序保證

在許多情況下，資料處理的順序都很重要。訊息佇列本來就是排序的，並且能保證資料會按照特定的順序來處理。

8.緩衝

在任何重要的系統中，都會有需要不同的處理時間的元素。例如,載入一張圖片比應用過濾器花費更少的時間。訊息佇列透過一個緩衝層來幫助任務最高效率的執行--寫入佇列的處理會盡可能的快速，而不受從佇列讀的預備處理的約束。該緩衝有助於控制和最佳化資料流經過系統的速度。

9. 理解資料流

在一個分散式系統裡，要得到一個關於使用者操作會用多長時間及其原因的總體印象，是個巨大的挑戰。訊息系列透過訊息被處理的頻率，來方便的輔助確定那些表現不佳的處理過程或領域，這些地方的資料流都不夠最佳化。

10. 非同步通訊

很多時候，你不想也不需要立即處理訊息。訊息佇列提供了非同步處理機制，允許你把一個訊息放入佇列，但並不立即處理它。你想向佇列中放入多少訊息就放多少，然後在你樂意的時候再去處理它們。

- 訊息模板：如何釋出和獲取訊息 -

JMS（Java Message Service,Java訊息服務）API是一個訊息服務的標準/規範，允許應用程式元件基於JavaEE平臺建立、傳送、接收和讀取訊息。在JMS標準中，有兩種訊息模型：P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。

Point-to-Point(PTP)模型

在P2P模型中，每個訊息只有一個消費者（即一旦被消費，訊息就不再在訊息佇列中），佇列保留著訊息，直到它們被消費或超時。傳送者和接收者之間在時間上沒有依賴性，也就是說當傳送者傳送了訊息之後，不管接收者有沒有正在執行，它不會影響到訊息被髮送到佇列。接收者在成功接收訊息之後需向佇列應答成功如果你希望傳送的每個訊息都應該被成功處理的話，那麼你需要P2P模型

Publisher/Subscriber (Pub/Sub) 模型

在Pub/Sub模型中包含如下概念：主題（Topic）、釋出者（Publisher）、訂閱者（Subscriber）。客戶端將訊息傳送到主題。多個釋出者將訊息傳送到Topic，系統將這些訊息傳遞給多個訂閱者。

每個訊息可以有多個消費者。釋出者和訂閱者之間有時間上的依賴性。針對某個主題(Topic)的訂閱者，它必須建立一個訂閱之後，才能消費釋出者的訊息，而且，為了消費訊息，訂閱者必須保持執行的狀態。當然，為了緩和這種嚴格的時間相關性，JMS允許訂閱者建立一個可持久化的訂閱。這樣，即使訂閱者沒有被啟用（執行），它也能接收到釋出者的訊息。如果你希望傳送的訊息可以不被做任何處理、或者被一個消費者處理、或者可以被多個消費者處理的話，那麼可以採用Pub/Sub模型。

- 何時使用訊息佇列 -

訊息佇列是軟體系統作資訊傳遞和系統整合的主要手段，同時相對於使用訊息佇列傳送訊息而言，還有另外一種更加普遍使用的整合技術，就是API。兩者都具有廣泛的應用，所以在實際架構設計中，經常要考慮的問題是什麼時候使用API，什麼時候使用訊息佇列。下表列出兩者主要的區別：

如何判斷什麼時候該使用API，什麼時候該使用訊息呢？舉個例子：

假設一個零售商開放他的產品清單。透過開放這個產品清單，合作廠商可以快速定位到自己的產品。產品清單中的資料是隻讀的，所以使用者可以重複的請求訪問。這種場景下，REST API使用簡單並且同步，更適合這個場景。

另一個場景，假設一個醫院要在治療病人之後更新病人的病歷。病歷資訊對於醫院和病人來講都是非常關鍵的資訊，為了保證資訊在傳輸過程中不會丟失，此時採用訊息更加合適。

最後一個場景。假設一個零售商搭建一個應用允許合作廠商訪問他的產品清單並下訂單。這種情況下，可以同時使用API和訊息。在查詢產品清單時，可以使用API。而在下訂單時，為了避免訊息丟失和處理峰值流量，可以使用訊息佇列。

- 服務匯流排 -

訊息匯流排可以理解成全域性的訊息通道。所以相對訊息佇列而言，他的不同之處在於全域性性和共享性。所以，訊息匯流排會包含三部分：通用資料模型、通用指令集和訊息佇列。跟隨SOA（Service Oriented Architecture，面向服務架構）的概念，資訊系統的匯流排通常叫服務匯流排，企業層的匯流排稱之為企業服務匯流排(ESB)。

企業服務匯流排可以看作是一種模式，在這種模式下定義了一個集中式的訊息中介軟體實現各種後端系統的整合（包括資料模型轉換、連線、路由和編排），從而實現些整合服務可以在構建新應用時複用。

在SOA中，IT架構被分成元件層、Web服務層、業務流程層等。元件層包括各種應用系統，它們通常是技術相關的具體實現，各種具體的分散式元件技術(CORBA、COM/DCOM、J2EE)都可以用於實現元件層的應用元件。通常複雜的IT環境中的元件層都同時使用了多種分散式元件技術，而不同實現技術之間的互聯性障礙給應用整合帶來了極大的困難，進而形成了一個個資訊孤島。

SOA引入了Web服務層來解決此種情況下的應用整合問題。Web服務是獨立於各種分散式元件技術的，它使用標準的基於XML的服務描述語言(Web Service Description Language，WSDL)來定義和封裝離散的業務功能，各種支援Web服務的分散式元件技術能夠將其上的業務元件釋出成Web服務併產生相應的WSDL文件，並且只需要依據WSDL描述的資訊就能夠呼叫Web服務，即WSDL所描述的業務功能。在SOA中，需要進入系統整合環節的業務元件都被對映為Web服務，形成了Web服務層。業務流程層則處於Web服務層之上，透過對Web服務的流程編排來實現商業流程。業務流程層透過Web服務層能夠呼叫到基於各種分散式元件技術實現的業務元件，實現了複雜IT系統環境的應用整合。

作為SOA基礎架構的關鍵部分，ESB的功能主要體現在通訊、服務互動、應用整合、服務質量、安全性以及管理和監控等方面。在通訊方面，ESB能夠支援訊息路由/定址，支援多種通訊技術、通訊協議(如JMS、HTTP)，支援釋出/訂閱的通訊模式，能夠處理請求/響應、同步以及非同步的訊息傳遞方式，並且要求以可靠的方式傳遞訊息。

常見的ESB產品包括：IBM的WebSphere ESB，Microsoft 基於BizTalk的ESB產品，JBOSS SOA Platform等。

需要強調的是，訊息匯流排或企業服務匯流排的目的是為了系統整合和服務共享。因此，當使用訊息匯流排的時候，所有的服務或者應用必須共享相同的資料型別，指令集以及相同的通訊協議，並且在訊息匯流排中，會最大量訊息轉換和編排的工作。而相對而言，訊息佇列的目的是資訊傳輸，因此並不限制是否型別一致。

- 流處理平臺——Kafka -

市面上的訊息佇列產品有很多，比如ActiveMQ、RabbitMQ 、Kafka 、RocketMQ ，還有 ZeroMQ ，連 redis 這樣的 NoSQL 資料庫也支援 MQ 功能。但其中影響力最大的應該還是Kafka。而從Kafka給自己的定義可以看出，Kafka不只是訊息佇列，而是分散式的流處理平臺。

什麼是流處理平臺呢？流處理是一種重要的大資料處理手段，其主要特點是其處理的資料是源源不斷且實時到來的。分散式流處理是一種面向動態資料的細粒度處理模式，基於分散式記憶體，對不斷產生的動態資料進行處理。其對資料處理的快速，高效，低延遲等特性，在大資料處理中發揮越來越重要的作用。流處理技術有很多技術選型，更多資訊可以參考“Apache 的流處理技術概述”。僅從Kafka的角度看流處理平臺和訊息佇列的區別，Kafka作為流處理平臺具有以下三種特性:

可以讓你釋出和訂閱流式的記錄。這一方面與訊息佇列或者訊息匯流排類似。可以儲存流式的記錄，並且有較好的容錯性。可以在流式記錄產生時就進行處理。

但與基於佇列和交換的RabbitMQ不同，Kafka的儲存層是使用分割槽的事務日誌實現的。Kafka還提供用於實時處理流的Streams API和可輕鬆與各種資料來源整合的Connector API。Kafka沒有“執行佇列”的概念。相反，Kafka將記錄的集合儲存在稱為主題（Topic）的類別中。

對於每個主題，Kafka維護訊息的分割槽日誌。每個分割槽都是一個有序的，不可變的記錄序列，在該記錄中連續附加訊息。因此Kafka的實現十分適合“Publisher/Subscriber (Pub/Sub) 模型”，但不適合“Point-to-Point(PTP)模型”。因此Kafka的定位並非訊息佇列或訊息匯流排，而是流處理平臺。