消息通信之關於消息隊列MQ必須瞭解的相關概念

目錄

• 系統通信方式有哪些?
• 消息隊列的應用場景
• 消息隊列通信模型
• 常見的消息協議
  • AMQP
  • MQTT
  • ATOMP
  • JMS
• 小結

系統通信方式有哪些?

• RPC調用

  RPC 全稱 Remote Procedure Call——遠程過程調用，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的方式。

  RPC 調用分類
  通信協議層面	基於 HTTP 協議的 RPC；基於二進制協議的 RPC；基於 TCP 協議的 RPC
  是否跨平臺	單語言 RPC，如 RMI, Remoting；跨平臺 RPC，如 google protobuffer, restful json，http XML。
  調用過程	同步通訊RPC和異步通訊RPC

• 消息隊列

  消息隊列」是在消息的傳輸過程當中保存消息的容器。

消息隊列的應用場景

• 異步處理

  有些業務不想也不須要當即處理消息。消息隊列提供了異步處理機制，容許用戶把一個消息放入隊列，在須要的時候進行處理;例如用戶註冊的時候發送驗證郵件能夠經過異步處理的方式在另一個線程內完成發送郵件操做.

• 解耦

  在應用開發過程當中隨着需求的增長各個模塊進行過分耦合,各模塊之間造成相互調用的關係,咱們能夠利用消息隊列造成中間層進行解耦.

• 流量削峯

  在應用某一時段會發生大流量的請求,例如雙十一會形成大量請求數據庫,數據庫很快就會造成瓶頸.咱們可將數據請求持久化在消息隊列中,進行逐步處理.

• 日誌收集

  在項目開發和運維的心中日誌是一個很重要的部分,若是儘量全面而又有效的收集日誌進行分析是一個勢在必得的任務,咱們可使用消息隊列來構建統一日誌處理平臺.

• 事務最終一致

  在行業中使用消息隊列來保證一個事務的最終一致性也是常見分佈式事務的解決方案.

消息隊列通信模型

一個最基本的消息隊列應該具備消息發送者,消息處理中心,消息消費者三個功能.

在MQ中消息隊列主要有兩種通信模型分別是PTP點對點和Pub/Sub發佈訂閱

常見的消息協議

消息協議是指用於實現消息隊列功能時雙方通訊的一個約定, 例如 如何區分客戶端是生產消息仍是消費消息? 客戶端向消息處理中心發送"發送: I am a Javaer"字符串,那麼咱們根據xxx約定字符中包含發送的表明生產消息,那麼咱們就能夠知道該客戶端要發送消息內容是" I am a Javaer",常見的消息協議有AMQP,MQTT,STOMP,XMPP等

AMQP

AMQP即Advanced Message Queuing Protocol，高級消息隊列協議，是面向消息中間件設計的應用層協議的一個開放標準。 它的主要特色是面向消息、隊列、路由(包括點對點和發佈/訂閱)]、可靠性和安全。

AMQP容許來自不一樣供應商的消息生產者和消費者實現真正的互操做擴展，就如同SMTP、HTTP、FTP等協議採用的方式同樣。而此前對於消息中間件的標準化努力則集中在API層面上(好比JMS)，且沒有提供互操做性的途徑。不一樣於JMS的僅僅定義API，AMQP是一個線路級的協議——它描述了經過網絡傳輸的字節流的數據格式。所以，聽從這個協議的任何語言編寫的工具都可以操做AMQP消息。

AMQP模型圖

• Exchange即交換器，用來接收Producer發佈的消息，並經過設定的路由規則將消息路由給服務器中的Queue。

• Binding即綁定器，能夠理解爲路由規則。它的做用就是把Exchange和Queue按照路由規則綁定起來。

• Binding Key即綁定關鍵字，Exchange視自身類型來決定Binding的路由行爲。

• Routing Key即消息的路由關鍵字，Exchange根據這個關鍵字決定如何路由某條消息。

MQTT

MQTT 最初由 IBM 於上世紀 90 年代晚期發明和開發。它最初的用途是將石油管道上的傳感器與衛星相連接。顧名思義，它是一種支持在各方之間異步通訊的消息協議。異步消息協議在空間和時間上將消息發送者與接收者分離，所以能夠在不可靠的網絡環境中進行擴展。雖然叫作消息隊列遙測傳輸，但它與消息隊列毫無關係，而是使用了一個發佈和訂閱的模型。在 2014 年底，它正式成爲了一種 OASIS 開放標準，並且在一些流行的編程語言中受到支持（經過使用多種開源實現）。

MQTT模型圖

ATOMP

STOMP，Streaming Text Orientated Message Protocol，是流文本定向消息協議，是一種爲MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協議。它提供了一個可互操做的鏈接格式，容許STOMP客戶端與任意STOMP消息代理(Broker)進行交互。因爲其設計簡單，很容易開發客戶端，所以在多種語言和多種平臺上獲得普遍應用。其中最流行的STOMP消息代理是Apache ActiveMQ。

ATOMP模型圖

JMS

注意: JMS不是消息隊列協議的一種，更不是消息隊列產品!

注意: JMS不是消息隊列協議的一種，更不是消息隊列產品!

注意: JMS不是消息隊列協議的一種，更不是消息隊列產品!

關於JMS你須要瞭解一點有趣的歷史.

消息隊列（Message Queue）起源於一位來自 MIT 的硬件設計教育工做者 Vivek Ranadivé 設想了一種通用軟件總線，就像主板上的總線那樣，供其餘應用程序接入。Vivek在1983年成立了 Teknekron，高盛等公司做爲第一批用戶再金融交易中採用了 Teknekron的軟件，同時還誕生了第一代消息隊列軟件：Teknekron 的 The Information Bus（TIB）。

Teknekron 的 TIB 容許應用開發者創建一系列規則去描述消息內容，只要消息按照這些規則發佈出去，任何消費者應用均可以訂閱感興趣的內容，信息的生產者和消費者徹底解耦，而且能夠再傳輸過程當中靈活混合。這個特性引發了電信特別是新聞機構的注意。1994年路透社收購了 Teknekron 。

因爲消息隊列再金融交易中應用的反響，BIM 在1990年也開始研發本身的消息隊列軟件（BIM MQ），而且逐步演化成 WebSphere MQ 並統治着商業消息隊列平臺市場。同時微軟開發了Microsoft Message Queue（MSMQ）。然而這些商業MQ問題在供應商壁壘，各個廠商的 MQ 之間沒法互通。爲了解決這個問題，Java Message Service（JMS）在2001年誕生了，試圖經過提供公共 Java API的方式隱藏MQ各個供應商提供的實際接口，從而跨越壁壘和解決互通問題，可是因爲使用單獨的標準化接口來膠合衆多不一樣的接口使應用程序反而變得更加脆弱。

爲了解決各個MQ在各個生產商之間的通信問題，Java Message Service（JMS）在2001年誕生了，試圖經過提供公共 Java API的方式隱藏MQ各個供應商提供的實際接口.是Java面向消息中間件的一套規範的Java API接口.

在JMS誕生以前大多數產品都支持點對點和發佈/訂閱兩種方式的通信模型.因此JMS就將這兩種消息模型抽象成兩類規範,由MQ廠商選擇實現. 因此咱們可使用JMS的Java API在Java語言上操做具體的MQ產品.

小結

下一章節咱們開始進入正式學習MQ消息通信具體相關產品了,定個小目標,寫個簡單的MQ