2. 程式人生 > >常用訊息佇列對比、選擇參考和訊息佇列認知

常用訊息佇列對比、選擇參考和訊息佇列認知

阿新 • • 發佈：2019-01-04

目錄：

1、訊息佇列之常用協議

1.1、AMQP

1.2、MQTT協議

1.3、STOMP協議

1.4、XMPP協議

2、訊息佇列之模型

3、訊息佇列的組成模組

4、常用訊息佇列介紹

4.1、RabbitMQ

4.2、ActiveMQ

4.3、RocketMQ

4.4、Kafka

5、結論:

1、訊息佇列之常用協議

1.1、AMQP

  • AMQP即Advanced Message Queuing Protocol,一個提供統一訊息服務的應用層標準高階訊息佇列協議,
  • 是應用層協議的一個開放標準,為面向訊息的中介軟體設計。
  • 基於此協議的客戶端與訊息中介軟體可傳遞訊息，並不受客戶端/中介軟體不同產品，不同開發語言等條件的限制。
  • 優點：可靠、通用

1.2、MQTT協議

  • MQTT（Message Queuing Telemetry Transport，訊息佇列遙測傳輸）是IBM開發的一個即時通訊協
  • 議，有可能成為物聯網的重要組成部分。該協議支援所有平臺，幾乎可以把所有聯網物品和外部連線起來，
  • 被用來當做感測器和致動器（比如通過Twitter讓房屋聯網）的通訊協議。
  • 優點：格式簡潔、佔用頻寬小、移動端通訊、PUSH、嵌入式系統

1.3、STOMP協議

  • STOMP（Streaming Text Orientated Message Protocol）是流文字定向訊息協議，是一種為MOM(Message Oriented Middleware，面向訊息的中介軟體設計的簡單文字協議。STOMP提供一個可互操作的連線格式，允許客戶端與任意STOMP訊息代理（Broker）進行互動。
  • 優點：命令模式（非topicqueue模式）

1.4、XMPP協議

  • XMPP（可擴充套件訊息處理現場協議，Extensible Messaging and Presence Protocol）是基於可擴充套件標記語言（XML）的協議，多用於即時訊息（IM）以及線上現場探測。適用於伺服器之間的準即時操作。核心是基於XML流傳輸，這個協議可能最終允許因特網使用者向因特網上的其他任何人傳送即時訊息，即使其作業系統和瀏覽器不同。
  • 優點：通用公開、相容性強、可擴充套件、安全性高，但XML編碼格式佔用頻寬大
  • 其他基於TCP/IP自定義的協議
  • 有些特殊框架（如：redis、kafka、zeroMq等）根據自身需要未嚴格遵循MQ規範，而是基於TCPIP自行封裝了一套協議，通過網路socket介面進行傳輸，實現了MQ的功能。

2、訊息佇列之模型

  1. Pub/Sub釋出訂閱（廣播）：使用topic作為通訊載體
  2. PTP點對點:使用queue作為通訊載體

3、訊息佇列的組成模組

  • Broker：訊息伺服器，作為server提供訊息核心服務
  • Producer:訊息生產者，業務的發起方，負責生產訊息傳輸給broker
  • Consumer：訊息消費者，業務的處理方，負責從broker獲取訊息並進行業務邏輯處理
  • Topic:主題，釋出訂閱模式下的訊息統一彙集地，不同生產者向topic傳送訊息，由MQ伺服器分發到不同的訂閱者，實現訊息的廣播
  • Queue：佇列，PTP模式下，特定生產者向特定queue傳送訊息，消費者訂閱特定的queue完成指定訊息的接收
  • Message：訊息體，根據不同通訊協議定義的固定格式進行編碼的資料包，來封裝業務資料，實現訊息的傳輸

4、常用訊息佇列介紹

本部分主要介紹四種常用的訊息佇列（RabbitMQ/ActiveMQ/RocketMQ/Kafka）的主要特性、優點、缺點。

4.1、RabbitMQ

RabbitMQ 2007年釋出，是一個在AMQP(高階訊息佇列協議)基礎上完成的，可複用的企業訊息系統，是當前最主流的訊息中介軟體之一。

主要特性：

  1. 可靠性: 提供了多種技術可以讓你在效能和可靠性之間進行權衡。這些技術包括永續性機制、投遞確認、釋出者證實和高可用性機制；
  2. 靈活的路由： 訊息在到達佇列前是通過交換機進行路由的。RabbitMQ為典型的路由邏輯提供了多種內建交換機型別。如果你有更復雜的路由需求，可以將這些交換機組合起來使用，你甚至可以實現自己的交換機型別，並且當做RabbitMQ的外掛來使用；
  3. 訊息叢集：在相同區域網中的多個RabbitMQ伺服器可以聚合在一起，作為一個獨立的邏輯代理來使用；
  4. 佇列高可用：佇列可以在叢集中的機器上進行映象，以確保在硬體問題下還保證訊息安全；
  5. 多種協議的支援：支援多種訊息佇列協議；
  6. 伺服器端用Erlang語言編寫，支援只要是你能想到的所有程式語言；
  7. 管理介面: RabbitMQ有一個易用的使用者介面，使得使用者可以監控和管理訊息Broker的許多方面；
  8. 跟蹤機制：如果訊息異常，RabbitMQ提供訊息跟蹤機制，使用者可以找出發生了什麼；
  9. 外掛機制：提供了許多外掛，來從多方面進行擴充套件，也可以編寫自己的外掛；

使用RabbitMQ需要：

  • ErLang語言包
  • RabbitMQ安裝包

RabbitMQ可以執行在Erlang語言所支援的平臺之上：

Solaris

BSD

Linux

MacOSX

TRU64

Windows NT/2000/XP/Vista/Windows 7/Windows 8

Windows Server 2003/2008/2012

Windows 95, 98

VxWorks

優點：

  1. 由於erlang語言的特性，mq 效能較好，高併發；
  2. 健壯、穩定、易用、跨平臺、支援多種語言、文件齊全；
  3. 有訊息確認機制和持久化機制，可靠性高；
  4. 高度可定製的路由；
  5. 管理介面較豐富，在網際網路公司也有較大規模的應用；
  6. 社群活躍度高；

缺點：

  1. 儘管結合erlang語言本身的併發優勢，效能較好，但是不利於做二次開發和維護；
  2. 實現了代理架構，意味著訊息在傳送到客戶端之前可以在中央節點上排隊。此特性使得RabbitMQ易於使用和部署，但是使得其執行速度較慢，因為中央節點增加了延遲，訊息封裝後也比較大；
  3. 需要學習比較複雜的介面和協議，學習和維護成本較高；

4.2、ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現。它非常快速，支援多種語言的客戶端和協議，而且可以非常容易的嵌入到企業的應用環境中，並有許多高階功能。

主要特性：

  1. 服從 JMS 規範：JMS 規範提供了良好的標準和保證，包括：同步或非同步的訊息分發，一次和僅一次的訊息分發，訊息接收和訂閱等等。遵從 JMS 規範的好處在於，不論使用什麼 JMS 實現提供者，這些基礎特性都是可用的；
  2. 連線性：ActiveMQ 提供了廣泛的連線選項，支援的協議有：HTTP/S，IP 多播，SSL，STOMP，TCP，UDP，XMPP等等。對眾多協議的支援讓 ActiveMQ 擁有了很好的靈活性。
  3. 支援的協議種類多：OpenWire、STOMP、REST、XMPP、AMQP ；
  4. 持久化外掛和安全外掛：ActiveMQ 提供了多種持久化選擇。而且，ActiveMQ 的安全性也可以完全依據使用者需求進行自定義鑑權和授權；
  5. 支援的客戶端語言種類多：除了 Java 之外，還有：C/C++，.NET，Perl，PHP，Python，Ruby；
  6. 代理叢集：多個 ActiveMQ 代理可以組成一個叢集來提供服務；
  7. 異常簡單的管理：ActiveMQ 是以開發者思維被設計的。所以，它並不需要專門的管理員，因為它提供了簡單又使用的管理特性。有很多中方法可以監控 ActiveMQ 不同層面的資料，包括使用在 JConsole 或者 ActiveMQ 的Web Console 中使用 JMX，通過處理 JMX 的告警訊息，通過使用命令列指令碼，甚至可以通過監控各種型別的日誌。

使用ActiveMQ需要：

  • Java JDK
  • ActiveMQ安裝包

ActiveMQ可以執行在Java語言所支援的平臺之上。

優點：

  1. 跨平臺(JAVA編寫與平臺無關有，ActiveMQ幾乎可以執行在任何的JVM上)
  2. 可以用JDBC：可以將資料持久化到資料庫。雖然使用JDBC會降低ActiveMQ的效能，但是資料庫一直都是開發人員最熟悉的儲存介質。將訊息存到資料庫，看得見摸得著。而且公司有專門的DBA去對資料庫進行調優，主從分離；
  3. 支援JMS ：支援JMS的統一介面;
  4. 支援自動重連；
  5. 有安全機制：支援基於shiro，jaas等多種安全配置機制，可以對Queue/Topic進行認證和授權。
  6. 監控完善：擁有完善的監控，包括Web Console，JMX，Shell命令列，Jolokia的REST API；
  7. 介面友善：提供的Web Console可以滿足大部分情況，還有很多第三方的元件可以使用，如hawtio；
  8. 缺點：
  9. 社群活躍度不及RabbitMQ高；
  10. 根據其他使用者反饋，會出莫名其妙的問題，會丟失訊息；
  11. 目前重心放到activemq6.0產品-apollo，對5.x的維護較少；
  12. 不適合用於上千個佇列的應用場景；

4.3、RocketMQ

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

主要特性：

  1. 是一個佇列模型的訊息中介軟體，具有高效能、高可靠、高實時、分散式特點；
  2. Producer、Consumer、佇列都可以分散式；
  3. Producer向一些佇列輪流傳送訊息，佇列集合稱為Topic，Consumer如果做廣播消費，則一個consumer例項消費這個Topic對應的所有佇列，如果做叢集消費，則多個Consumer例項平均消費這個topic對應的佇列集合；
  4. 能夠保證嚴格的訊息順序；
  5. 提供豐富的訊息拉取模式；
  6. 高效的訂閱者水平擴充套件能力；
  7. 實時的訊息訂閱機制；
  8. 億級訊息堆積能力；
  9. 較少的依賴；

使用RocketMQ需要：

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

RocketMQ可以執行在Java語言所支援的平臺之上。

優點：

  1. 單機支援 1 萬以上持久化佇列
  2. RocketMQ 的所有訊息都是持久化的，先寫入系統 PAGECACHE，然後刷盤，可以保證記憶體與磁碟都有一份資料，
  3. 訪問時，直接從記憶體讀取。
  4. 模型簡單，介面易用（JMS 的介面很多場合並不太實用）；
  5. 效能非常好，可以大量堆積訊息在broker中；
  6. 支援多種消費，包括叢集消費、廣播消費等。
  7. 各個環節分散式擴充套件設計，主從HA；
  8. 開發度較活躍，版本更新很快。

缺點：

支援的客戶端語言不多，目前是java及c++，其中c++不成熟；

RocketMQ社群關注度及成熟度也不及前兩者；

沒有web管理介面，提供了一個CLI(命令列介面)管理工具帶來查詢、管理和診斷各種問題；

沒有在 mq 核心中去實現JMS等介面；

4.4、Kafka

Apache Kafka是一個分散式訊息釋出訂閱系統。它最初由LinkedIn公司基於獨特的設計實現為一個分散式的提交日誌系統( a distributed commit log)，，之後成為Apache專案的一部分。Kafka系統快速、可擴充套件並且可持久化。它的分割槽特性，可複製和可容錯都是其不錯的特性。

主要特性：

  1. 快速持久化，可以在O(1)的系統開銷下進行訊息持久化；
  2. 高吞吐，在一臺普通的伺服器上既可以達到10W/s的吞吐速率；
  3. .完全的分散式系統，Broker、Producer、Consumer都原生自動支援分散式，自動實現負載均衡；
  4. 支援同步和非同步複製兩種HA；
  5. 支援資料批量傳送和拉取；
  6. zero-copy：減少IO操作步驟；
  7. 資料遷移、擴容對使用者透明；
  8. 無需停機即可擴充套件機器；
  9. 其他特性：嚴格的訊息順序、豐富的訊息拉取模型、高效訂閱者水平擴充套件、實時的訊息訂閱、億級的訊息堆積能力、定期刪除機制；

使用Kafka需要：

  • Java JDK
  • Kafka安裝包

優點：

  1. 客戶端語言豐富，支援java、.net、php、ruby、python、go等多種語言；
  2. 效能卓越，單機寫入TPS約在百萬條/秒，訊息大小10個位元組；
  3. 提供完全分散式架構, 並有replica機制, 擁有較高的可用性和可靠性, 理論上支援訊息無限堆積；
  4. 支援批量操作；
  5. 消費者採用Pull方式獲取訊息, 訊息有序, 通過控制能夠保證所有訊息被消費且僅被消費一次;
  6. 有優秀的第三方Kafka Web管理介面Kafka-Manager；
  7. 在日誌領域比較成熟，被多家公司和多個開源專案使用；

缺點：

  1. Kafka單機超過64個佇列/分割槽，Load會發生明顯的飆高現象，佇列越多，load越高，傳送訊息響應時間變長
  2. 使用短輪詢方式，實時性取決於輪詢間隔時間；
  3. 消費失敗不支援重試；
  4. 支援訊息順序，但是一臺代理宕機後，就會產生訊息亂序；
  5. 社群更新較慢；

RabbitMQ/ActiveMQ/RocketMQ/Kafka對比

這裡列舉了上述四種訊息佇列的差異對比：

常用訊息佇列對比和選擇參考和訊息佇列認知

 

5、結論:

Kafka在於分散式架構，RabbitMQ基於AMQP協議來實現，RocketMQ/思路來源於kafka，改成了主從結構，在事務性可靠性方面做了優化。廣泛來說，電商、金融等對事務性要求很高的，可以考慮RabbitMQ和RocketMQ，對效能要求高的可考慮Kafka。

參考：

http://www.cnblogs.com/yangk5636/p/9232183.html

https://www.cnblogs.com/javalyy/p/8856731.html

 

相關推薦

常用訊息佇列對比、選擇參考和訊息佇列認知

目錄： 1、訊息佇列之常用協議 1.1、AMQP 1.2、MQTT協議 1.3、STOMP協議 1.4、XMPP協議 2、訊息佇列之模型 3、訊息佇列的組成模組 4、常用訊息佇列介紹 4.1、RabbitMQ 4.2、ActiveMQ 4.3、Rocket

分散式、中介軟體和訊息佇列到底是怎麼的一種工作模式？

本文轉自：悟空問答 分散式 相對於以前單一系統，所有的功能，服務都部署在一臺伺服器上，一掛全掛！分散式採用了把系統提供的服務分佈在不同的伺服器上的策略，這樣的架構就叫做分散式架構！ 我有一個系統A，提供一個很簡單的介面，根據員工編號查詢員工姓名和他的考

樣式表的類別、選擇器和優先級

樣式 tex import 沒有 內聯 逗號 16px 屬性 strong 類別： 內聯：寫在標簽裏面，以style=”樣式“，其控制精確，但是代碼重用性差。 內嵌：嵌在頁面的head裏面，以<style type="text/css"></style&g

總結4種常用排序(快排、選擇排序、冒泡排序、插入排序)

快速排序 length 長度 遞歸 繼續 index 效率 第一個元素 自己 一、 選擇排序 概念理解: 在一個長度為3的數組中，在第一趟遍歷3個數據，找出其中最小的數值與第一個元素交換； 第二趟遍歷2個數據，找出其中最小的元素與第一個數交換(註意:這裏的第一個數是指遍歷

堆、堆排序和優先佇列的那些事

1. 什麼是堆？ 堆是一種資料結構，它是一顆完全二叉樹。 堆分為最大堆和最小堆： 最大堆：任意節點的值不大於其父親節點的值。 最小堆：任意節點的值不小於其父親節點的值。 如下圖所示，就是個最大堆： 注：本文中的程式碼實現是最大堆，最小堆的實現相似，不再冗贅。 2. 堆有什麼用途？ 堆最常用於優先

JAVA常用演算法之冒泡、選擇、快速

排序：對一組資料進行從小到大（或從大到小）的順序排列。 排序演算法有很多種，這裡介紹Java中面試經常出現的三種排序方式：冒泡、選擇、快速。 冒泡： 顧明思義，是氣泡從液體的底部到頂部的過程，就像串糖葫蘆一樣，先決定最下面的資料。在演算法的過程中是把一組資

使用jedis實現Redis訊息佇列(MQ)的釋出(publish)和訊息監聽(subscribe)

前言： 本文基於jedis 2.9.0.jar、commons-pool2-2.4.2.jar以及json-20160810.jar 其中jedis連線池需要依賴commons-pool2包，json

用objective-c 實現常用演算法（冒泡、選擇、快速、插入）

原文網址：http://www.360doc.com/content/14/0508/15/11029609_375813213.shtml 研究了下用oc實現常用的演算法，參考了一些資料後自己用程式碼檢驗了下，以下程式碼均測試可用。其中arr引數是一個可變陣列，其中存

漫步IOS--部分排序一：氣泡排序、選擇排序和快速排序

1 氣泡排序 氣泡排序的思路：從序列的一頭開始，每次比較相鄰的兩個數，將大的往後移.當走到序列結尾的時候，最後一個即是最大的；然後再從頭開始比較，只是這次比較到倒數第二個就好，因為最後一個已經確定是最大了。如此往復，直到沒有需要比較的元素為止。個人表述有限，可參考維基百

順序結構、選擇結構和迴圈結構的程式設計例題

1 在三種選擇結構中,能用2個條件,控制從3個操作中選擇一個操作執行的選擇結構是____選擇結構【分析】能用1個條件,控制某個操作做或不做的選擇結構是單分支結構；能用1個條件，控制從2個操作中選擇一個操作執行的選擇結構是雙分支結構；能用n(n＞l)個條件，控制從n＋ l個操作

ArcGis Engine程式設計之子集、選擇集和版面檢視

實驗：子集和選擇集的使用 1.應用QueryFilter，查詢記錄的子集迴圈，並以訊息框顯示統計結果。 public partial class Form1 : Form { public Form1() {

常用算法之----選擇排序、插入排序和希爾排序

插入 @override == 撰寫 [] 步長 1.5 shells 撲克 一些說明 我將會寫一系列關於算法的博客，因為我是程序員，並不是計算機科學家，也即我是搞工程的，並不是搞學術的，所以對於我來說，最重要的就是 1.有哪些算法 2.這些算法的原理 3.這些

四層和七層負載均衡的特點及常用負載均衡Nginx、Haproxy、LVS對比

web服務器 keepaliv 保持 obi 負載均衡 ted 根據 方案 面向 一、四層與七層負載均衡在原理上的區別 圖示： 四層負載均衡與七層負載均衡在工作原理上的簡單區別如下圖： 概述： 1.四層負載均衡工作在OSI模型中的四層，即傳輸層。四層負載均衡只能根據報文中

SpringBoot整合ActiveMQ訊息佇列和雙向佇列、點對點與釋出訂閱

ActiveMQ 是Apache出品，最流行的，能力強勁的開源訊息匯流排。ActiveMQ 是一個完全支援JMS1.1和J2EE 1.4規範的 JMS Provider實現，儘管JMS規範出臺已經是很久的事情了，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。 &nbs

遊戲引擎選擇、Mac下和Windows下UnrealEngine 4體驗對比

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！        

訊息佇列：Ubuntu16.04安裝和Web頁面管理RabbitMQ（樓主親測、真實有效）

RabbitMQ 總來來說，RabbitMQ的安裝還是有一些難度的。不同的方式，安裝的方法也是完全不一樣，還要解決蠻多依賴。加上現在有些網站，極其不負責，很多博文都沒有經過測試檢驗就直接發出來的。樓主來親測一下，希望能對大家有好的幫助。 一、安裝前的準備 要確保，你有Erla

RabbitMQ系列之七 分散式訊息佇列應用場景之非同步處理、應用解耦、流量削鋒和訊息通訊理解分析

摘要：訊息佇列中介軟體是分散式系統中重要的元件，主要解決應用耦合，非同步訊息，流量削鋒等問題。實現高效能，高可用，可伸縮和最終一致性架構。是大型分散式系統不可缺少的中介軟體。 目前在生產環境，使用較多的訊息佇列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，

JS-呼叫棧、事件迴圈、訊息佇列（也叫任務隊和回撥佇列）、作業佇列（微任務佇列）

一：呼叫棧是個什麼鬼東西，它具有棧的屬性--後進先出 先看一段簡單的JS程式碼： const second = function(){ console.log('hello there'); } const first = function() { console.log('hi,first'); secon

微信小程式裡面的標籤和html標籤的對比、微信小程式基礎之常用控制元件

微信小程式和html5標籤的區別： HTML5 微信小程式 <h1></h1>...<h6></h6> <p>&l

響應式佈局的常用解決方案對比(媒體查詢、百分比、rem和vw/vh）

簡要介紹：前端開發中，靜態網頁通常需要適應不同解析度的裝置，常用的自適應解決方案包括媒體查詢、百分比、rem和vw/vh等。本文從px單位出發，分析了px在移動端佈局中的不足，接著介紹了幾種不同的自適應解決方案。 本文原文在我的github主頁中，如果喜歡