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 的相關知識，
點擊關注我的博客
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/162687.html
標籤：Java
下一篇：簡述 HTTP 首部欄位.