非同步訊息傳遞技術的比較:JMS、AMQP和MQTT
訊息傳遞作為基本通訊機制已經在全世界成功運用。無論是人與人、機器與人還是機器與機器之間,訊息傳遞一直都是唯一常用的通訊方式。在雙方(或更多)之間交換訊息有兩種基本機制。
- 同步訊息傳遞
- 非同步訊息傳遞
同步訊息傳遞在這種情況下使用,當訊息傳送者希望在某個時間範圍內收到響應,然後再進行下一個任務。基本上就是他在收到響應前一直處於“阻塞”狀態。
非同步訊息意味著傳送者並不要求立即收到響應,而且也不會阻塞整個流程。響應可有可無,傳送者總會執行剩下的任務。
上面提到的技術,當兩臺計算機上的程式相互通訊的時候,就廣泛使用了非同步訊息傳遞。隨著微服務架構的興起,很明顯我們需要使用非同步訊息傳遞模型來構建服務。
這一直是軟體工程中的基本問題,而且不同的人和組織機構會提出不同的方法。我將介紹在企業IT系統中廣泛使用的三種最成功的非同步訊息傳遞技術。
Java訊息傳遞服務(Java Messaging Service (JMS))
JMS是最成功的非同步訊息傳遞技術之一。隨著Java在許多大型企業應用中的使用,JMS就成為了企業系統的首選。它定義了構建訊息傳遞系統的API。
下面是JMS的主要特性:
- 面向Java平臺的標準訊息傳遞API
- 在Java或JVM語言比如Scala、Groovy中具有互用性
- 無需擔心底層協議
- 有queues和topics兩種訊息傳遞模型
- 支援事務
- 能夠定義訊息格式(訊息頭、屬性和內容)
高階訊息佇列協議(Advanced Message Queueing Protocol (AMQP))
JMS非常棒而且人們也非常樂意使用它。微軟開發了NMS(.NET訊息傳遞服務)來支援他們的平臺和程式語言,它效果還不錯。但是碰到了互用性的問題。兩套使用兩種不同程式語言的程式如何通過它們的非同步訊息傳遞機制相互通訊呢。此時就需要定義一個非同步訊息傳遞的通用標準。JMS或者NMS都沒有標準的底層協議。它們可以在任何底層協議上執行,但是API是與程式語言繫結的。AMQP解決了這個問題,它使用了一套標準的底層協議,加入了許多其他特徵來支援互用性,為現代應用豐富了訊息傳遞需求。
下面是AMQP的主要特性:
- 獨立於平臺的底層訊息傳遞協議
- 消費者驅動訊息傳遞
- 跨語言和平臺的互用性
- 它是底層協議的
- 有5種交換型別direct,fanout,topic,headers,system
- 面向快取的
- 可實現高效能
- 支援長週期訊息傳遞
- 支援經典的訊息佇列,迴圈,儲存和轉發
- 支援事務(跨訊息佇列)
- 支援分散式事務(XA,X/OPEN,MS DTC)
- 使用SASL和TLS確保安全性
- 支援代理安全伺服器
- 元資料可以控制訊息流
- 不支援LVQ
- 客戶端和服務端對等
- 可擴充套件
訊息佇列遙測傳輸(Message Queueing Telemetry Transport (MQTT))
現在我們已經有了面向基於Java的企業應用的JMS和麵向所有其他應用需求的AMQP。為什麼我們還需要第三種技術?它是專門為小裝置設計的。計算效能不高的裝置不能適應AMQP上的複雜操作,它們需要一種簡單而且可互用的方式進行通訊。這是MQTT的基本要求,而如今,MQTT是物聯網(IOT)生態系統中主要成分之一。
下面是MQTT的主要特性:
- 面向流,記憶體佔用低
- 為小型無聲裝置之間通過低頻寬傳送短訊息而設計
- 不支援長週期儲存和轉發
- 不允許分段訊息(很難傳送長訊息)
- 支援主題釋出-訂閱
- 不支援事務(僅基本確認)
- 訊息實際上是短暫的(短週期)
- 簡單使用者名稱和密碼,基於沒有足夠資訊熵的安全
- 不支援安全連線
- 訊息不透明
- Topic是全域性的(一個全域性的名稱空間)
- 支援最新值佇列(Last Value Queue (LVQ) )
- 客戶端和服務端不對稱
- 不能擴充套件
由CSDN重磅打造的2016中國雲端計算技術大會(CCTC 2016)將於5月13日-15日在北京舉辦,大會特設“中國Spark技術峰會”、“Container技術峰會”、“OpenStack技術峰會”、“大資料核心技術與應用實戰峰會”等四大技術主題峰會,以及“雲端計算核心技術架構”、“雲端計算平臺構建與實踐”等專場技術論壇。80+位一線網際網路公司的技術專家將到場分享他們在雲端計算、大資料領域的技術實踐,目前大會剩票不多,欲購從速。詳情請點選CCTC 2016大會官網(http://cctc.csdn.net/)。
相關推薦
非同步訊息傳遞技術的比較:JMS、AMQP和MQTT
訊息傳遞作為基本通訊機制已經在全世界成功運用。無論是人與人、機器與人還是機器與機器之間,訊息傳遞一直都是唯一常用的通訊方式。在雙方(或更多)之間交換訊息有兩種基本機制。同步訊息傳遞 非同步訊息傳遞 同步訊息傳遞在這種情況下使用,當訊息傳送者希望在某個時間範圍內收
.Net 三款工作流引擎比較:WWF、netBPM 和 ccflow
下面將對目前比較主流的三款工作流進行介紹和比較,然後通過三款流程引擎分別設計一個較典型的流程來給大家分別演示這三款建立流程的過程.這三款工作流程引擎分別是 Windows Workflow Foundation,NetBPM, CCFlow. NetBPM 與 CCFlow 是兩款國內知名的開源
阿里雲大資料三次技術突圍:Greenplum、Hadoop和飛天
對於企業來說,到底什麼是雲端計算?相信很多企業都有這樣的困惑,讓我們一起回到這個原始的起點探討究竟什麼是雲端計算?雲端計算對於企業而言到底意味什麼? 雲端計算的三條發展路徑及三種落地形態 當回到最初的起點再審視雲端計算的發展路徑,可以發現,經過十餘年的發
三款工作流引擎比較:WWF、netBPM 和 ccflow 下面將對目前比較主流的三款工作流進行介紹和比較,然後通過三款流程引擎分別設計一個較典型的流程來給大家分別演示這三款建立流程的過程.這
下面將對目前比較主流的三款工作流進行介紹和比較,然後通過三款流程引擎分別設計一個較典型的流程來給大家分別演示這三款建立流程的過程.這三款工作流程引擎分別是 Windows Workflow Foundation,NetBPM, CCFlow. NetBPM 與 CCFlow 是兩款國內知名的開源軟體,尤其是
Android 訊息機制:Handler、MessageQueue 和 Looper
在這篇文章中,我們將會討論 Android 的訊息機制。提到 Handler,有過一些 Android 開發經驗的都應該很清楚它的作用,通常我們使用它來通知主執行緒更新 UI。但是 Handler 需要底層的 MessageQueue 和 Looper 來支援才能運作。這篇文章中,我們將會討論它們三個之間的關
走進以太坊技術之路:瓶頸、困境和方案
一、以太坊目前存在的技術瓶頸 以太坊網路目前存在的主要問題是:可擴充套件性、智慧合約的安全性、共識協議與隱私性。 1. 可擴充套件性困境 2017年的以太坊養貓遊戲中,佔到整個以太坊16%的交易量,導致以太坊網路大面積擁堵。網路擁堵問題暴露出了以太坊區塊鏈亟需擴容的現狀。以太坊被設計成為一個
多執行緒學習(4):三種實現Java多執行緒的方法:Thread、Callable和Runable 的比較與區別
2018年10月03日 目錄 前言 前言 JVM允許應用程式併發執行多執行緒:最常用的是兩個方法:(1)基礎Thread類,重寫run()方法;(2)或實現Runnable 介面,實現介面的run()方法;(3)另外一種方法是:實現callable 介面
視訊直播關鍵技術:流暢、擁塞和延時追趕
這兩年網際網路領域的一個熱門關鍵詞就是視訊直播,從剛開始的遊戲直播和秀場娛樂開始,現在各個行業裡都植入了直播元素。網易雲信多年以來,一直深耕於音視訊領域,這篇文章將和大家聊一聊視訊直播的幾個關鍵技術。 相關閱讀推薦 清晰度 4K、1080p、720p,這些概念
訊息中介軟體/佇列:ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMq
Kafka最高,RabbitMq 次之, ActiveMq 最差。 2)吞吐量對比: kafka具有高的吞吐量,內部採用訊息的批量處理,zero-copy機制,資料的儲存和獲取是本地磁碟順序批量操作,具有O(1)的複雜度,訊息處理的效率很高。 rabbitMQ在吞吐量方面稍遜於kafka,他們的出發點不一樣,
開源協議比較:BSD、Apache、GLP、LGLP、MIT
BSD開源協議(original BSD license、FreeBSD license、Original BSD license) BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以”為所欲為”,可以自由的使用,修改原始碼,也可以將修改後的程式碼作為開源或者專有軟體再發布。 但
Android的訊息處理機制:Message、Handlerhe和Looper原始碼解析
android的訊息處理有三個核心類:Looper,Handler和Message。其實還有一個Message Queue(訊息佇列),但是MQ被封裝到Looper裡面了,我們不會直接與MQ打交道,因此我沒將其作為核心類。下面一一介紹: 執行緒的魔法師 Looper Loo
開源日誌系統比較:scribe、chukwa、kafka、flume
1. 背景介紹許多公司的平臺每天會產生大量的日誌(一般為流式資料,如,搜尋引擎的pv,查詢等),處理這些日誌需要特定的日誌系統,一般而言,這些系統需要具有以下特徵:(1) 構建應用系統和分析系統的橋樑,並將它們之間的關聯解耦;(2) 支援近實時的線上分析系統和類似於Hadoo
這才是2018年的技術趨勢:雲、大資料、IOT深度融合
2018年,在應用需求的推動下,雲端計算、大資料、物聯網等新技術的融合發展將更加明顯,其中的雲端計算也將繼續演化,步入全新的3.0時代。 在這個言必談AI(人工智慧)的時代,似乎再說其他技術就顯得low了,但從實際應用的角度而言,企業目前剛剛在雲端計算、大資料、物聯網等
MQTT是一項訊息傳遞技術,安卓自建小範圍可用
MQTT是一項訊息傳遞技術,由IBM再2001年釋出。 總結一下,機制就是使用一個代理伺服器message broker, 客戶端client連線上這個伺服器,然後告訴伺服器說,我可以接收哪些型別的訊息, 同時,client也可以釋出自己的訊息,這些訊息根據協議的內容,可以被其他cl
全面解密QQ紅包技術方案:架構、技術實現、移動端優化、創新玩法等
本文來自騰訊QQ技術團隊工程師許靈鋒、周海發的技術分享。 一、引言 自 2015 年春節以來,QQ 春節紅包經歷了企業紅包(2015 年)、刷一刷紅包(2016 年)和 AR 紅包(2017 年)幾個階段,通過不斷創新玩法,活躍度節節攀升,成為春節一大玩點,給火紅的春節帶來一抹亮色。2017
二分鐘快速掌握Caffeine 三種填充策略:手動、同步和非同步
一、簡介 Caffeine — 一個高效能的 Java 快取庫。快取和 Map 之間的一個根本區別在於快取可以回收儲存的 item。回收策略為在指定時間刪除哪些物件。此策略直接影響快取的命中率 — 快取庫的一個重要特徵。Caffeine 因使用 Window TinyLf
Android Handler 非同步訊息處理機制三:妙用手法 建立強大的圖片載入類
上一篇部落格介紹了Android非同步訊息處理機制,如果你還不瞭解,可以看:Android 非同步訊息處理機制 讓你深入理解 Looper、Handler、Message三者關係 。那篇部落格的最後,提出可以把非同步訊息處理機制不僅僅是在MainActivit
技術筆記:字串、List、陣列、日期等常見操作方法
string類 string s="ABC科學";int i=s.IndexOf("科");//字串的搜尋。 int n=string.Compare(s1,s2);//n=0則兩個相同。n< 0
Embedded資料庫比較:Access、SQLite、HSQLDB、Sybase、MySQL、DB4O
引自:http://www.cnblogs.com/kenkofox/archive/2011/03/18/1988422.html 一、Access 資料型別有些另類,而且密碼太容易被攻破,效能不高,只能用在Windows程式上。 一般說來,單個表不超過1
開源日誌採集系統比較:scribe、chukwa、kafka、flume
1. 背景介紹 許多公司的平臺每天會產生大量的日誌(一般為流式資料,如,搜尋引擎的pv,查詢等),處理這些日誌需要特定的日誌系統,一般而言,這些系統需要具有以下特徵: (1)構建應用系統和分析系統的橋樑,並將它們之間的關聯解耦; (2)支援近實時的線上分析系統和類似於