MQ系列（0）——MQ簡介

mq簡介

mq 就是消息隊列（Message Queue）。想必你們對隊列的數據結構已經很熟悉了，消息隊列能夠簡單理解爲：把要傳輸的數據放在隊列中，mq 就是存放和發送消息的這麼一個隊列中間件。在消息隊列中，把數據放到消息隊列的角色叫作 生產者，從消息隊列中消費獲取數據的叫作 消費者。

那麼消息隊列有哪些使用場景呢? 六字真言：異步削峯解耦。

MQ的異步

異步概念想必你們都熟悉了，就是 a應用（或程序） 將數據傳遞給b應用（或程序）後，不等待b的響應結果直接作下一步動做，而b並行執行，提升效率。使用mq，就能完美支持異步：a將數據發送到mq，而後本身該幹嗎幹嗎，b監聽mq的消息，來了消息就消費它。這樣就作到程序或者應用間的異步。

mq的削峯

首先咱們要知道什麼是削峯：削峯的全稱應該叫削峯填谷。削峯就是當應用或者程序的請求量過大的時候，將一部分請求延時處理，放到請求量不大時間段去處理它。mq削峯填谷的原理也很簡單，mq在應用程序中至關於一個 「蓄水池」 的做用——當 「水流量（請求）」 過大的時候，「蓄水池（mq）」 將 "水" 先存起來。當有能力去消費這些水的時候再去從 「蓄水池」 放水。實際的過程是——請求數據先發到 mq ，應用程序監聽mq 並消費消息。當請求量大於消費量的時候，請求積壓在mq中存儲；當消費量大於請求量的時候，請求就會慢慢被處理完。這聽上去就像小學作的游泳池放水排水的數學題。

mq的解耦

mq解耦性是顯而易見的，應用程序直接不直接互相耦合，甚至能夠不用知道對方的存在。它想要發出什麼樣的請求，或者拿什麼數據，都是去找mq。mq就像個搬運工同樣在這些應用之間搬運數據。

mq 協議及產品

mq 協議有兩種，jms 和 AMQP 。一般而言提到JMS（Java MessageService）其實是指 JMS API 。JMS 是由Sun公司早期提出的消息標準，旨在爲java應用提供統一的消息操做，包括create、send、receive

等。JMS已經成爲 Java Enterprise Edition 的一部分。從使用角度看，JMS和JDBC擔任差很少的角色，用戶都是根據相應的接口能夠和實現了 JMS 的服務進行通訊，進行相關的操做。

JMS角色概念：

• JMS provider：實現了JMS接口的消息中間件，如ActiveMQ
• JMS client：生產或者消費消息的應用
• JMS producer/publisher：JMS消息生產者
• JMS consumer/subscriber ：JMS消息消費者
• JMS message：消息，在各個JMS client傳輸的對象；
• JMS queue：Provider存放等待被消費的消息的地方
• JMS topic：一種提供多個訂閱者消費消息的一種機制；在MQ中經常被提到，topic模式。

  AMQP（advanced message queuing protocol） 在2003年時被提出，最先用於解決金融領不一樣平臺之間的消息傳遞交互問題。AMQP是一種 binary wire-level protocol（連接協議）。AMQP 不從 API 的層面層對使用規範進行限定，而是直接定義網絡交換的數據格式。這意味着實現了amqp協議的消息隊列中間件支持跨平臺。咱們可使用 Java 的 AMQP provider 而 consumer 能夠是golang 。

在AMQP中，消息路由（messagerouting）和JMS存在一些差異，在AMQP中增長了 Exchange 和 binding 的角色。producer 將消息發送給 Exchange ，binding 決定 Exchange 的消息應該發送到那個 queue，而consumer直接從queue中消費消息。queue和exchange的bind有consumer來決定。

相對而言，AMQP的消息隊列使用的更爲普遍。如 rabbitMQ , kafka , rocketMQ 等都是實現AMQP協議的消息隊列。接下來咱們將會學習 rabbitMQ 和 kafka 的相關知識。

點擊關注個人博客