一、什么是消息中間件
兩個(gè)系統(tǒng)或兩個(gè)客戶端之間進(jìn)行消息傳送，利用高效可靠的消息傳遞機(jī)制進(jìn)行平臺(tái)無(wú)關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來(lái)進(jìn)行分布式系統(tǒng)的集成。通過(guò)提供消息傳遞和消息排隊(duì)模型，它可以在分布式環(huán)境下擴(kuò)展進(jìn)程間的通信。
消息中間件，總結(jié)起來(lái)作用有三個(gè)：異步化提升性能、降低耦合度、流量削峰。?
系統(tǒng)A發(fā)送消息給中間件后，自己的工作已經(jīng)完成了，不用再去管系統(tǒng)B什么時(shí)候完成操作。而系統(tǒng)B拉去消息后，執(zhí)行自己的操作也不用告訴系統(tǒng)A執(zhí)行結(jié)果，所以整個(gè)的通信過(guò)程是異步調(diào)用的。
二、消息中間件的應(yīng)用場(chǎng)景
2.1 異步通信
有些業(yè)務(wù)不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一個(gè)消息放入隊(duì)列，但并不立即處理它。想向隊(duì)列中放入多少消息就放多少，然后在需要的時(shí)候再去處理它們。
2.2 緩沖
在任何重要的系統(tǒng)中，都會(huì)有需要不同的處理時(shí)間的元素。消息隊(duì)列通過(guò)一個(gè)緩沖層來(lái)幫助任務(wù)最高效率的執(zhí)行，該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過(guò)系統(tǒng)的速度。以調(diào)節(jié)系統(tǒng)響應(yīng)時(shí)間。
2.3 解耦
降低工程間的強(qiáng)依賴程度，針對(duì)異構(gòu)系統(tǒng)進(jìn)行適配。在項(xiàng)目啟動(dòng)之初來(lái)預(yù)測(cè)將來(lái)項(xiàng)目會(huì)碰到什么需求，是極其困難的。通過(guò)消息系統(tǒng)在處理過(guò)程中間插入了一個(gè)隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過(guò)程都要實(shí)現(xiàn)這一接口，當(dāng)應(yīng)用發(fā)生變化時(shí)，可以獨(dú)立的擴(kuò)展或修改兩邊的處理過(guò)程，只要確保它們遵守同樣的接口約束。?
三、常用消息隊(duì)列（ActiveMQ、RabbitMQ、RocketMQ、Kafka）比較
| 特性MQ | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 生產(chǎn)者消費(fèi)者模式 | 支持 | 支持 | 支持 | 支持 |
| 發(fā)布訂閱模式 | 支持 | 支持 | 支持 | 支持 |
| 請(qǐng)求回應(yīng)模式 | 支持 | 支持 | 不支持 | 不支持 |
| Api完備性 | 高 | 高 | 高 | 高 |
| 多語(yǔ)言支持 | 支持 | 支持 | java | 支持 |
| 單機(jī)吞吐量 | 萬(wàn)級(jí) | 萬(wàn)級(jí) | 萬(wàn)級(jí) | 十萬(wàn)級(jí) |
| 消息延遲 | 無(wú) | 微秒級(jí) | 毫秒級(jí) | 毫秒級(jí) |
| 可用性 | 高（主從） | 高（主從） | 非常高（分布式） | 非常高（分布式） |
| 消息丟失 | 低 | 低 | 理論上不會(huì)丟失 | 理論上不會(huì)丟失 |
| 文檔的完備性 | 高 | 高 | 高 | 高 |
| 提供快速入門(mén) | 有 | 有 | 有 | 有 |
| 社區(qū)活躍度 | 高 | 高 | 有 | 高 |
| 商業(yè)支持 | 無(wú) | 無(wú) | 商業(yè)云 | 商業(yè)云 |
四、消息中間件的角色
Queue：?隊(duì)列存儲(chǔ)，常用與點(diǎn)對(duì)點(diǎn)消息模型 ，默認(rèn)只能由唯一的一個(gè)消費(fèi)者處理。一旦處理消息刪除。
Topic：?主題存儲(chǔ)，用于訂閱/發(fā)布消息模型，主題中的消息，會(huì)發(fā)送給所有的消費(fèi)者同時(shí)處理。只有在消息可以重復(fù)處 理的業(yè)務(wù)場(chǎng)景中可使用，Queue/Topic都是 Destination 的子接口
ConnectionFactory：?連接工廠，客戶用來(lái)創(chuàng)建連接的對(duì)象，例如ActiveMQ提供的ActiveMQConnectionFactory
Connection：?JMS Connection封裝了客戶與JMS提供者之間的一個(gè)虛擬的連接。
Destination：?消息的目的地，目的地是客戶用來(lái)指定它生產(chǎn)的消息的目標(biāo)和它消費(fèi)的消息的來(lái)源的對(duì)象。JMS1.0.2規(guī)范中定義了兩種消息傳遞域：點(diǎn)對(duì)點(diǎn)（PTP）消息傳遞域和發(fā)布/訂閱消息傳遞域。
點(diǎn)對(duì)點(diǎn)消息傳遞域的特點(diǎn)如下：
- 每個(gè)消息只能有一個(gè)消費(fèi)者。
- 消息的生產(chǎn)者和消費(fèi)者之間沒(méi)有時(shí)間上的相關(guān)性。無(wú)論消費(fèi)者在生產(chǎn)者發(fā)送消息的時(shí)候是否處于運(yùn)行狀態(tài)，它都可以提取消息。
發(fā)布/訂閱消息傳遞域的特點(diǎn)如下：
- 每個(gè)消息可以有多個(gè)消費(fèi)者。
- 生產(chǎn)者和消費(fèi)者之間有時(shí)間上的相關(guān)性。
- 訂閱一個(gè)主題的消費(fèi)者只能消費(fèi)自它訂閱之后發(fā)布的消息。JMS規(guī)范允許客戶創(chuàng)建持久訂閱，這在一定程度上放松了時(shí)間上的相關(guān)性要求 。持久訂閱允許消費(fèi)者消費(fèi)它在未處于激活狀態(tài)時(shí)發(fā)送的消息。 在點(diǎn)對(duì)點(diǎn)消息傳遞域中，目的地被成為隊(duì)列（queue）；在發(fā)布/訂閱消息傳遞域中，目的地被成為主題（topic）。
五、JMS的消息格式
JMS消息由以下三部分組成的：
-
消息頭：
每個(gè)消息頭字段都有相應(yīng)的getter和setter方法。
-
消息屬性：
如果需要除消息頭字段以外的值，那么可以使用消息屬性。
-
消息體：
JMS定義的消息類(lèi)型有TextMessage、MapMessage、BytesMessage、StreamMessage和ObjectMessage。
消息類(lèi)型：
| 屬性 | 類(lèi)型 |
|---|---|
| TextMessage | 文本消息 |
| MapMessage | k/v |
| BytesMessage | 字節(jié)流 |
| StreamMessage | java原始的數(shù)據(jù)流 |
| ObjectMessage | 序列化的java對(duì)象 |
六、消息可靠性機(jī)制
只有在被確認(rèn)之后，才認(rèn)為已經(jīng)被成功地消費(fèi)了，消息的成功消費(fèi)通常包含三個(gè)階段?：客戶接收消息、客戶處理消息和消息被確認(rèn)。在事務(wù)性會(huì)話中，當(dāng)一個(gè)事務(wù)被提交的時(shí)候，確認(rèn)自動(dòng)發(fā)生。在非事務(wù)性會(huì)話中，消息何時(shí)被確認(rèn)取決于創(chuàng)建會(huì)話時(shí)的應(yīng)答模式（acknowledgement mode）。該參數(shù)有以下三個(gè)可選值：
-
Session.AUTO_ACKNOWLEDGE：當(dāng)客戶成功的從receive方法返回的時(shí)候，或者從MessageListener.onMessage方法成功返回的時(shí)候，會(huì)話自動(dòng)確認(rèn)客戶收到的消息。 -
Session.CLIENT_ACKNOWLEDGE：客戶通過(guò)消息的acknowledge方法確認(rèn)消息。需要注意的是，在這種模式中，確認(rèn)是在會(huì)話層上進(jìn)行：確認(rèn)一個(gè)被消費(fèi)的消息將自動(dòng)確認(rèn)所有已被會(huì)話消費(fèi)的消息。例如，如果一個(gè)消息消費(fèi)者消費(fèi)了10個(gè)消息，然后確認(rèn)第5個(gè)消息，那么所有10個(gè)消息都被確認(rèn)。 -
Session.DUPS_ACKNOWLEDGE：該選擇只是會(huì)話遲鈍的確認(rèn)消息的提交。如果JMS Provider失敗，那么可能會(huì)導(dǎo)致一些重復(fù)的消息。如果是重復(fù)的消息，那么JMS Provider必須把消息頭的JMSRedelivered字段設(shè)置為true。
6.1 優(yōu)先級(jí)
可以使用消息優(yōu)先級(jí)來(lái)指示JMS Provider首先提交緊急的消息。優(yōu)先級(jí)分10個(gè)級(jí)別，從0（最低）到9（最高）。如果不指定優(yōu)先級(jí)，默認(rèn)級(jí)別是4。需要注意的是，JMS Provider并不一定保證按照優(yōu)先級(jí)的順序提交消息。
6.2 消息過(guò)期
可以設(shè)置消息在一定時(shí)間后過(guò)期，默認(rèn)是永不過(guò)期。
6.3 臨時(shí)目的地
可以通過(guò)會(huì)話上的createTemporaryQueue方法和createTemporaryTopic方法來(lái)創(chuàng)建臨時(shí)目的地。它們的存在時(shí)間只限于創(chuàng)建它們的連接所保持的時(shí)間。只有創(chuàng)建該臨時(shí)目的地的連接上的消息消費(fèi)者才能夠從臨時(shí)目的地中提取消息。
七、什么是ActiveMQ
ActiveMQ是一種開(kāi)源的基于JMS（Java Message Servie）規(guī)范的一種消息中間件的實(shí)現(xiàn)，ActiveMQ的設(shè)計(jì)目標(biāo)是提供標(biāo)準(zhǔn)的，面向消息的，能夠跨越多語(yǔ)言和多系統(tǒng)的應(yīng)用集成消息通信中間件。
官網(wǎng)地址：activemq.apache.org/
7.1 存儲(chǔ)方式
1. KahaDB存儲(chǔ)：?KahaDB是默認(rèn)的持久化策略，所有消息順序添加到一個(gè)日志文件中，同時(shí)另外有一個(gè)索引文件記錄指向這些日志的存儲(chǔ)地址，還有一個(gè)事務(wù)日志用于消息回復(fù)操作。是一個(gè)專(zhuān)門(mén)針對(duì)消息持久化的解決方案,它對(duì)典型的消息使用模式進(jìn)行了優(yōu)化
特性： 1、日志形式存儲(chǔ)消息； 2、消息索引以 B-Tree 結(jié)構(gòu)存儲(chǔ)，可以快速更新； 3、 完全支持 JMS 事務(wù)； 4、支持多種恢復(fù)機(jī)制kahadb 可以限制每個(gè)數(shù)據(jù)文件的大小。不代表總計(jì)數(shù)據(jù)容量。
2. AMQ 方式：?只適用于 5.3 版本之前。 AMQ 也是一個(gè)文件型數(shù)據(jù)庫(kù)，消息信息最終是存儲(chǔ)在文件中。內(nèi)存中也會(huì)有緩存數(shù)據(jù)。
3. JDBC存儲(chǔ) ：?使用JDBC持久化方式，數(shù)據(jù)庫(kù)默認(rèn)會(huì)創(chuàng)建3個(gè)表，每個(gè)表的作用如下：
activemq_msgs：queue和topic的消息都存在這個(gè)表中 activemq_acks：存儲(chǔ)持久訂閱的信息和最后一個(gè)持久訂閱接收的消息ID activemq_lock：跟kahadb的lock文件類(lèi)似，確保數(shù)據(jù)庫(kù)在某一時(shí)刻只有一個(gè)broker在訪問(wèn)
4. LevelDB存儲(chǔ) ：?LevelDB持久化性能高于KahaDB，但是在ActiveMQ官網(wǎng)對(duì)LevelDB的表述：LevelDB官方建議使用以及不再支持，推薦使用的是KahaDB
5.Memory 消息存儲(chǔ)：?顧名思義，基于內(nèi)存的消息存儲(chǔ)，就是消息存儲(chǔ)在內(nèi)存中。persistent=”false”,表示不設(shè)置持 久化存儲(chǔ)，直接存儲(chǔ)到內(nèi)存中，在broker標(biāo)簽處設(shè)置。
7.2 協(xié)議
協(xié)議官網(wǎng)API：activemq.apache.org/configuring…
-
Transmission Control Protocol (TCP)：
- 這是默認(rèn)的Broker配置，TCP的Client監(jiān)聽(tīng)端口是61616。
- 在網(wǎng)絡(luò)傳輸數(shù)據(jù)前，必須要序列化數(shù)據(jù)，消息是通過(guò)一個(gè)叫wire protocol的來(lái)序列化成字節(jié)流。默認(rèn)情況下，ActiveMQ把wire protocol叫做OpenWire，它的目的是促使網(wǎng)絡(luò)上的效率和數(shù)據(jù)快速交互。
- TCP連接的URI形式：tcp://hostname:port?key=value&key=value
- TCP傳輸?shù)膬?yōu)點(diǎn)：
(1)TCP協(xié)議傳輸可靠性高，穩(wěn)定性強(qiáng) (2)高效性：字節(jié)流方式傳遞，效率很高 (3)有效性、可用性：應(yīng)用廣泛，支持任何平臺(tái)
-
New I/O API Protocol（NIO）
-
NIO協(xié)議和TCP協(xié)議類(lèi)似，但NIO更側(cè)重于底層的訪問(wèn)操作。它允許開(kāi)發(fā)人員對(duì)同一資源可有更多的client調(diào)用和服務(wù)端有更多的負(fù)載。
-
適合使用NIO協(xié)議的場(chǎng)景：
(1)可能有大量的Client去鏈接到Broker上一般情況下，大量的Client去鏈接Broker是被操作系統(tǒng)的線程數(shù)所限制的。因此，NIO的實(shí)現(xiàn)比TCP需要更少的線程去運(yùn)行，所以建議使用NIO協(xié)議 (2)可能對(duì)于Broker有一個(gè)很遲鈍的網(wǎng)絡(luò)傳輸NIO比TCP提供更好的性能文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-557662.html
-
鏈接：https://juejin.cn/post/6882194277234032654
?文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-557662.html
-
到了這里，關(guān)于ActiveMQ詳細(xì)入門(mén)教程系列的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
