消息隊列系列一（相關概念）

概念

1. 消息隊列協議

比較三種最多見和最流行的基於TCP/IP的消息傳遞協議，並提供每種優點的快速總結：AMQP、MQTT和STOMP，RabbitMQ 3.0版本中支持全部這三個協議-咱們將使用這些協議做爲示例並稍後再回來。

AMQP

AMQP-高級消息隊列協議，旨在做爲現有專有消息傳遞中間件的開放替代品。使用AMQP的兩個最重要的緣由是可靠性和互操做性。顧名思義，它提供了與消息傳遞相關的各類功能，包括可靠的排隊，基於主題的發佈和訂閱消息傳遞，靈活的路由，事務和安全性。AMQP直接以扇出形式，按主題和基於標題交換路由消息。

如此豐富的功能集能夠實現許多細粒度控制。您能夠限制對隊列的訪問，管理其深度等。消息屬性，註釋和標題等功能使其很是適合各類企業應用程序。該協議旨在提升許多大型公司的可靠性，這些公司依靠消息傳遞來集成應用程序並在其組織中移動數據。在RabbitMQ的狀況下，有許多不一樣的語言實現和可用的大樣本，使其成爲構建大規模，可靠，彈性或羣集消息傳遞基礎結構的良好選擇。

AMQP是一種二進制有線協議，旨在實現不一樣供應商之間的互操做性。在其餘協議失敗的狀況下，AMQP的採用率很高。摩根大通等公司天天使用它來處理10億條消息。NASA將其用於星雲雲計算。Google將其用於複雜的事件處理。如下是一些其餘AMQP示例和連接：

• 它被用於世界上最大的生物識別數據庫之一印度的Aadhar項目 -擁有12億個身份。
• 它被用於Ocean Observatories Initiative--一種天天收集8TB數據的架構。
• amqp.org提供了更多示例和連接。

MQTT

MQTT（消息隊列遙測傳輸）最初有IBM普及計算團隊的開發的，它們與工業領域的合做夥伴共同開發。在過去的幾年中，該協議已經轉移到開源社區，隨着移動應用程序的開始，其受歡迎程度顯着增長，而且正在進入標準組的手中

MQTT的合集原則和目標比AMQP更簡單，，更集中-它提供了發佈和訂閱消息（沒有隊列），專門針對資源受限的設備和低帶寬、高延遲網絡，例如撥號線路和衛星鏈路。基本上，它能夠在嵌入式是系統中有效使用。

MQTT對功能更強大的「企業消息傳遞」代理商的優點之一是其故意低佔用空間使其成爲當今移動和開發「 物聯網 」風格應用程序的理想選擇。事實上，像Facebook這樣的公司正在將它做爲移動應用程序的一部分，由於它具備如此低的功耗，而且網絡帶寬很小。

一些基於MQTT的代理支持數千個併發設備鏈接。它提供三種服務質量：1）火災和遺忘/不可靠，2）「至少一次」以確保它至少發送一次（但可能被髮送超過一次），以及3）「確切地說一旦」。

MQTT的優勢是簡單（只有五種API方法），一個緊湊的二進制數據包有效負載（沒有消息屬性，壓縮標頭，比基於文本的HTTP更簡潔），它很是適合簡單的推送消息傳遞方案，如溫度更新，股票價格代碼，油壓供應或移動通知。它對於將機器鏈接在一塊兒很是有用，例如使用MQTT將Arduino設備鏈接到Web服務。

STOMP

STOMP（簡單/流式文本導向消息傳遞協議）是這三種協議中惟一一種基於文本的協議，使其在覆蓋範圍方面更相似與HTTP。與AMQP同樣，STOMP提供帶有屬性的消息（或幀）標頭或幀體。這裏的設計原則是建立一些簡單且可普遍互操做的東西。例如，可使用想telnet客戶端這樣簡單的東西鏈接到STOMP代理。

可是，STOMP不處理隊列和主題。它使用帶有「目標」字符串的SEND語義。代理必須映射到內容理解的內容，例如主題，隊列或交換。消費者而後訂閱這些目的地。因爲規範中沒有強制要求這些目的地，所以，不一樣的經濟人可能會支持不一樣的目的地風格。所以，在代理之間移植代碼並不老是直截了當的。

可是，STOMP簡單而輕便（儘管在線上優勢冗長），具備管飯的語言綁定。它還提供了一些事務語義。其中一個最有趣的例子是RabbitMQ Web Stomp，它容許您經過websockets在瀏覽器中公開消息。這開闢了一些有趣的可能性 - 好比使用全部類型的信息實時更新瀏覽器，移動應用程序或機器。

2. 消息隊列

什麼是消息隊列？

消息隊列是一種異步的服務間通訊方式，使用與無服務和微服務架構。消息在被處理和刪除以前一直存儲在隊列上。每條消息僅可被一直爲用戶處理一次。消息隊列可被用於分離重量級處理、緩存或批處理工做以及緩解高峯期工做負載。

在現代雲架構中，應用程序被分解爲多個規模較小且更易於開發、部署和維護的獨立構建模塊。消息隊列可爲這些分佈式應用程序提供通訊和協調。消息隊列能夠顯著簡化分離應用程序的編碼，同時提升性能、可靠性和可擴展性。

藉助消息隊列，系統的不一樣部分可相互通訊並異步執行處理操做。消息隊列提供一個臨時存儲消息的輕量級緩存區，以及容許軟件組件鏈接到隊列以發送接受消息的的終端節點。這些消息一般較小，能夠是請求、恢復、錯誤消息或明文消息等。要發送消息時，一個名爲「建立器」的組件將消息添加到隊列。消息將存儲在隊列中，直至名爲「處理器」的另外一組件檢索該消息並執行相關操做。

許多建立器和處理器均可以使用隊列，但一條信息只能有一盒處理器處理一次。所以，這種消息收發模式一般稱爲一對一或點對點通訊。若是消息須要由多個處理器進行處理，可採用扇出設計模式將消息隊列與發佈/訂閱消息收發結合起來。

3. 消息中間件

• RabbitMQ
• Kafka
• RocketMQ
• Qpid
• Artemis
• NSQ
• ZeroMQ

ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ是一個徹底支持JMS1.1和JMS1.4規範的JMS Provider實現。它很是快速，只是多種語言的客戶端和協議，並且能夠很是容易的嵌入到企業的應用環境中，並有許多高級功能。

主要特性

• 服從JMS規範：JMS規範提供了良好的標準和保證，包括：同步或異步的消息分發，一次或僅一次的消息分發，消息接收和訂閱等等。聽從JMS規範的好處在於，不論使用什麼JMS實現提供者，這些基礎特性都是可用的；
• 鏈接靈活性：ActiveMQ提供了普遍的鏈接協議，支持的協議有：HTTP/S，IP多播，SSL，TCP，UDP等等。對衆多協議的支持讓ActiveMQ擁有了很好的靈活性
• 支持的協議種類多：OpenWrite、STOMP、REST、XMMP、AMQP；
• 持久化插件和安全插件：ActiveMQ提供了多種持久化選擇。並且，ActiveMQ的安全性也能夠徹底一句用戶需求進行自定義鑑權和受權；
• 支持的客戶端語言種類多：除了Java以外，還有C/C++，.NET，Perl，PHP，Python，Ruby；
• 代理集羣：多個ActiveMQ代理能夠組成一個集羣來提供服務；
• 異常簡單的管理：ActiveMQ是以開發者思惟被設計的。因此，它並不須要專門的管理員，由於它提供了簡單有實用的管理特性。又不少方法能夠監控ActiveMQ不一樣層面的數據，包括實用在JConsole或者在ActiveMQ的Web console中使用JMXJMX。經過處理JMX的告警消息，經過使用命令行腳本，甚至能夠經過監控各類類型的日誌。

部署環境

ActiveMQ 能夠運行在 Java 語言所支持的平臺之上。使用 ActiveMQ 須要：

• Java JDK
• ActiveMQ 安裝包

優勢

• 跨平臺 (JAVA 編寫與平臺無關，ActiveMQ 幾乎能夠運行在任何的 JVM 上)；
• 能夠用 JDBC：能夠將 數據持久化 到數據庫。雖然使用 JDBC 會下降 ActiveMQ 的性能，可是數據庫一直都是開發人員最熟悉的存儲介質；
• 支持 JMS 規範：支持 JMS 規範提供的 統一接口;
• 支持 自動重連 和 錯誤重試機制；
• 有安全機制：支持基於 shiro，jaas 等多種 安全配置機制，能夠對 Queue/Topic 進行 認證和受權；
• 監控完善：擁有完善的 監控，包括 Web Console，JMX，Shell 命令行，Jolokia 的 RESTful API；
• 界面友善：提供的 Web Console 能夠知足大部分狀況，還有不少 第三方的組件 可使用，好比 hawtio；

缺點

• 社區活躍度不及 RabbitMQ 高；
• 根據其餘用戶反饋，會出莫名其妙的問題，會 丟失消息；
• 目前重心放到 activemq 6.0 產品 Apollo，對 5.x 的維護較少；
• 不適合用於 上千個隊列 的應用場景；

RabbitMQ

RabbitMQ 於 2007 年發佈，是一個在 AMQP (高級消息隊列協議)基礎上完成的，可複用的企業消息系統，是當前最主流的消息中間件之一。

主要特性

• 可靠性：提供了多種技術可讓你在 性能 和 可靠性 之間進行 權衡。這些技術包括 持久性機制、投遞確認、發佈者證明 和 高可用性機制；
• 靈活的路由：消息在到達隊列前是經過 交換機 進行 路由 的。RabbitMQ 爲典型的路由邏輯提供了 多種內置交換機 類型。若是你有更復雜的路由需求，能夠將這些交換機組合起來使用，你甚至能夠實現本身的交換機類型，而且當作 RabbitMQ 的 插件 來使用；
• 消息集羣：在相同局域網中的多個 RabbitMQ 服務器能夠 聚合 在一塊兒，做爲一個獨立的邏輯代理來使用；
• 隊列高可用：隊列能夠在集羣中的機器上 進行鏡像，以確保在硬件問題下還保證 消息安全；
• 支持多種協議：支持 多種消息隊列協議；
• 支持多種語言：用 Erlang 語言編寫，支持只要是你能想到的 全部編程語言；
• 管理界面： RabbitMQ 有一個易用的 用戶界面，使得用戶能夠 監控 和 管理 消息 Broker 的許多方面；
• 跟蹤機制：若是 消息異常，RabbitMQ 提供消息跟蹤機制，使用者能夠找出發生了什麼；
• 插件機制：提供了許多 插件，來從多方面進行擴展，也能夠編寫本身的插件。

部署環境

RabbitMQ 能夠運行在 Erlang 語言所支持的平臺之上，包括 Solaris，BSD，Linux，MacOSX，TRU64，Windows 等。使用 RabbitMQ 須要：

• ErLang 語言包
• RabbitMQ 安裝包

優勢

• 因爲 Erlang 語言的特性，消息隊列性能較好，支持 高併發；
• 健壯、穩定、易用、跨平臺、支持 多種語言、文檔齊全；
• 有消息 確認機制 和 持久化機制，可靠性高；
• 高度可定製的 路由；
• 管理界面 較豐富，在互聯網公司也有較大規模的應用，社區活躍度高。

缺點

• 儘管結合 Erlang 語言自己的併發優點，性能較好，可是不利於作 二次開發和維護；
• 實現了 代理架構，意味着消息在發送到客戶端以前能夠在 中央節點 上排隊。此特性使得 RabbitMQ 易於使用和部署，可是使得其 運行速度較慢，由於中央節點 增長了延遲，消息封裝後 也比較大；
• 須要學習比較複雜的接口協議，學習和維護成本較高。

RocketMQ

RocketMQ出自阿里的開源產品，用Java語言實現，在設計時參考了Kafka，並作出了本身的一些改進，消息可靠性上比Kafka更好。RocketMQ在阿里內部被普遍應用在訂單，交易，充值，流計算，消息推送，日誌流式處理，binglog分發等場景。

主要特性

• 基於隊列模型：具備高性能、高可靠、高實時、分佈式等特色；
• Producer、Consumer、隊列都支持分佈式；
• Producer向一些隊列輪流發送消息，隊列集合稱爲Topic。Consumer若是作廣播消費，則一個Consumer實例消費這個Topic對應的全部隊列；若是作集羣消費，則多個Consumer實例平均消費這個Topic對應的隊列集合；
• 可以保證嚴格的消息順序；
• 提供豐富的消息拉取模式；
• 高效的訂閱着水平擴展能力；
• 實時的消息訂閱機制；
• 億級消息堆積能力；
• 較少的外部依賴；

部署環境

RocketMQ能夠運行在Java語言所支持的平臺之上。使用RocketMQ須要：

• Java JDK
• 安裝git、Maven
• RocketMQ安裝包

優勢

• 單機支持一萬以上持久化隊列；
• RocketMQ的全部消息都是持久化的，先寫入系統PageCache，而後刷盤，能夠保證內存與磁盤都有一份數據，而訪問時，直接從內存讀取。
• 模型簡單，接口易用（JMS的接口不少場合並不實用）；
• 性能很是好，能夠容許大量堆積消息在Broker中；
• 支持多種消費模式，包括集羣消費、廣播消費等；
• 各個環節分佈式擴展設計，支持主從和高可用；
• 開發度比較活躍，版本更新更快；

缺點

• 支持的客戶端語言很少，目前是Java及C++，其中C++還不成熟；
• RocketMQ社區關注度及成熟度也不及前二者；
• 沒有Web管理界面，提供了一個CLI管理工具代理查詢、管理和診斷各類問題；
• 沒有在MQ核內心實現JMS等接口

Kafka

Apache Kafka 是一個 分佈式消息發佈訂閱 系統。它最初由 LinkedIn 公司基於獨特的設計實現爲一個 分佈式的日誌提交系統 (a distributed commit log)，以後成爲 Apache 項目的一部分。Kafka 性能高效、可擴展良好 而且 可持久化。它的 分區特性，可複製 和 可容錯 都是其不錯的特性。

主要特性

• 快速持久化：能夠在 O(1) 的系統開銷下進行 消息持久化；
• 高吞吐：在一臺普通的服務器上既能夠達到 10W/s 的 吞吐速率；
• 徹底的分佈式系統：Broker、Producer 和 Consumer 都原生自動支持 分佈式，自動實現 負載均衡；
• 支持 同步 和 異步 複製兩種 高可用機制；
• 支持 數據批量發送 和 拉取；
• 零拷貝技術(zero-copy)：減小 IO 操做步驟，提升 系統吞吐量；
• 數據遷移、擴容 對用戶透明；
• 無需停機 便可擴展機器；
• 其餘特性：豐富的 消息拉取模型、高效 訂閱者水平擴展、實時的 消息訂閱、億級的 消息堆積能力、按期刪除機制；

部署環境

使用 Kafka 須要：

• Java JDK
• Kafka 安裝包

優勢

• 客戶端語言豐富：支持 Java、.Net、PHP、Ruby、Python、Go 等多種語言；
• 高性能：單機寫入 TPS 約在 100 萬條/秒，消息大小 10 個字節；
• 提供 徹底分佈式架構，並有 replica 機制，擁有較高的 可用性 和 可靠性，理論上支持 消息無限堆積；
• 支持批量操做；
• 消費者 採用 Pull 方式獲取消息。消息有序，經過控制 可以保證全部消息被消費且僅被消費 一次；
• 有優秀的第三方 Kafka Web 管理界面 Kafka-Manager；
• 在 日誌領域 比較成熟，被多家公司和多個開源項目使用。

缺點

• Kafka 單機超過 64 個 隊列/分區 時，Load 時會發生明顯的飆高現象。隊列 越多，負載 越高，發送消息 響應時間變長；
• 使用 短輪詢方式，實時性 取決於 輪詢間隔時間；
• 消費失敗 不支持重試；
• 支持 消息順序，可是 一臺代理宕機 後，就會產生 消息亂序；
• 社區更新較慢。

4. 發佈/訂閱消息收發

發佈/訂閱消息收發是一種異步的服務間通訊方式，適用於無服務和微服務架構。在發佈/訂閱模式下，發佈到主題的任何的任何消息都會當即被主題的全部訂閱者接受。發佈/訂閱消息收發可用於啓用事件驅動架構，或分離應用程序，以提升性能、可靠性和可擴展性。

發佈/訂閱消息收發基礎知識

在現代雲架構中，應用程序被分解爲多個規模較小且易於開發、部署和維護的獨立構建塊。發佈/訂閱消息收發能夠爲這些分佈式應用程序提供及時事件通知。

發佈/訂閱模式讓消息可以異步廣播到系統中的不一樣部分。消息主題與消息隊列相似，能夠提供一個輕量型機制來廣播異步事件通知，還能夠提供能讓軟件組件鏈接主題以便發送和接受消息的終端節點。在廣播消息時，一個叫作「發佈者」的組件會將消息推送到主題。與在消息被檢索前批量處理消息的消息隊列不一樣的是，消息主題無需或使用極少消息隊列便可傳輸消息，並將消息當即推送給全部訂閱者。訂閱該主題的全部組件都會收到廣播的每一條消息，除非訂閱着設置了消息篩選策略。

消息主題的訂閱着一般執行不一樣的功能，並能夠同時對消息執行不一樣的操做。發佈者無需知道誰在使用廣播的消息而訂閱着也無需知道消息來自哪裏。這種消息收發模式與消息隊列稍有不一樣，在消息隊列中，發送消息的組件一般知道發送目的地。

技術選擇

絕不奇怪，考慮到基本消息傳遞對數據驅動的應用程序的影響，有許多技術支持某種形式的消息隊列，發佈 - 訂閱消息傳遞或二者兼而有之。

技術，如Apache的ActiveMQ的，亞馬遜SQS，IBM的WebSphere MQ，RabbitMQ的，和RocketMQ最初設計主要是爲消息排隊的用例。Apache Kafka和Google Cloud Pub / Sub等其餘技術主要用於支持發佈 - 訂閱用例。其餘一般較新的解決方案，如 Apache Pulsar， 支持 消息隊列和pub-sub消息傳遞。

RabbitMQ、Kafka和ActiveMQ都是用於提供異步通訊和解耦進程（分離消息的發送者和接受者）的消息傳遞技術。它們被稱爲消息隊列，消息代理或消息傳遞工具。RabbitMQ、Kafka和ActiveMQ都具備相同的基本用途。但能夠以不一樣的方式完成工做。Kafka始終高吞吐量的分佈式消息傳遞系統。RabbitMQ是基於AMQP的可靠消息代理。ActiveMQ和Kafka都是Apache產品，都是用Java編寫的；RabbitMQ是用Erlang編寫的。

Kafka在於分佈式架構，RabbitMQ基於AMQP協議來實現，RocketMQ的思路來源於Kafka，改爲了主從結構，在事務性和可靠性方面作成了優化。普遍來講，電商、金融等對事務一致性要求很高的，能夠考慮RabbitMQ和RocketMQ，對性能要求高的可考慮Kafka。

https://stackshare.io/stackup...