ActiveMQ知识概括
生活随笔
收集整理的這篇文章主要介紹了
ActiveMQ知识概括
小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
ActiveMQ知識(shí)概括
- ActiveMQ簡(jiǎn)介
- Java實(shí)現(xiàn)ActiveMQ
- JMS規(guī)范與落地
- ActiveMQ的broker
- Spring，SpringBoot整合ActiveMQ
- ActiveMQ的傳輸協(xié)議
- ActiveMQ的消息存儲(chǔ)和持久化
- ActiveMQ多節(jié)點(diǎn)集群
- ActiveMQ高級(jí)特性
ActiveMQ簡(jiǎn)介
ActiveMQ安裝：
- 安裝步驟：
①去ActiveMQ官網(wǎng)下載壓縮包。
②解壓壓縮包到指定目錄。
③啟動(dòng)ActiveMQ：service activemq start
④查看activemq狀態(tài)：service activemq status
⑤關(guān)閉activemq服務(wù)：service activemq stop - 啟動(dòng)時(shí)指定日志輸出文件：
①activemq日志默認(rèn)的位置是在：%activemq安裝目錄%/data/activemq.log
②這是我們啟動(dòng)時(shí)指定日志輸出文件：service activemq start > /usr/local/raohao/activemq.log - 查看程序啟動(dòng)是否成功的3種方式（通用）：
①ps -ef | grep activemq
②netstat -anp | grep 61616
③lsof -i： 61616
ActiveMQ控制臺(tái)：
- 訪問(wèn)activemq管理頁(yè)面地址：http://IP地址:8161/。默認(rèn)的用戶名和密碼是admin/admin。
- 備注：
①ActiveMQ采用61616端口提供JMS服務(wù)。
②ActiveMQ采用8161端口提供管理控制臺(tái)服務(wù)。 - 默認(rèn)程序連接activemq(JMS服務(wù))是不需要密碼的，為了安裝起見(jiàn)，一般都會(huì)設(shè)置密碼，提高安全性。
- ActiveMQ控制臺(tái)之隊(duì)列：
①Number Of Pending Messages：等待消費(fèi)的消息，這個(gè)是未出隊(duì)列的數(shù)量，公式=總接收數(shù)-總出隊(duì)列數(shù)。
②Number Of Consumers：消費(fèi)者數(shù)量，消費(fèi)者端的消費(fèi)者數(shù)量。
③Messages Enqueued：進(jìn)隊(duì)消息數(shù)，進(jìn)隊(duì)列的總消息量，包括出隊(duì)列的。這個(gè)數(shù)只增不減。
④Messages Dequeued：出隊(duì)消息數(shù)，可以理解為是消費(fèi)者消費(fèi)掉的數(shù)量。
- ActiveMQ控制臺(tái)之主題：
- ActiveMQ控制臺(tái)之訂閱者：
Java實(shí)現(xiàn)ActiveMQ
pom.xml導(dǎo)入依賴：
<!-- activemq 所需要的jar 包--> <dependency><groupId>org.apache.activemq</groupId><artifactId>activemq-all</artifactId><version>5.15.9</version> </dependency> <!-- activemq 和 spring 整合的基礎(chǔ)包 --> <dependency><groupId>org.apache.xbean</groupId><artifactId>xbean-spring</artifactId><version>3.16</version> </dependency>JMS編碼總體規(guī)范：
- 架構(gòu)：
- JMS開(kāi)發(fā)的基本步驟：
①創(chuàng)建一個(gè)connection factory
②通過(guò)connection factory來(lái)創(chuàng)建JMS connection
③啟動(dòng)JMS connection
④通過(guò)connection創(chuàng)建JMS session
⑤創(chuàng)建JMS destination
⑥創(chuàng)建JMS producer或者創(chuàng)建JMS message并設(shè)置destination
⑦創(chuàng)建JMS consumer或者是注冊(cè)一個(gè)JMS message listener
⑧發(fā)送或者接受JMS message(s)
⑨關(guān)閉所有的JMS資源(connection, session, producer, consumer等)
Destination簡(jiǎn)介：
- Destination是目的地。下面拿jvm和mq，做個(gè)對(duì)比。目的地，我們可以理解為是數(shù)據(jù)存儲(chǔ)的地方。
- Destination分為兩種：隊(duì)列和主題。
①在點(diǎn)對(duì)點(diǎn)的消息傳遞域中,目的地被稱為隊(duì)列(queue)
②在發(fā)布訂閱消息傳遞域中,目的地被稱為主題(topic)
③下圖介紹：
隊(duì)列消息（Queue）總結(jié)：
- 兩種消費(fèi)方式：
①同步阻塞方式(receive)：訂閱者或接收者抵用MessageConsumer的receive()方法來(lái)接收消息，receive方法在能接收到消息之前（或超時(shí)之前）將一直阻塞。
②異步非阻塞方式（監(jiān)聽(tīng)器onMessage()）：訂閱者或接收者通過(guò)MessageConsumer的setMessageListener(MessageListener listener)注冊(cè)一個(gè)消息監(jiān)聽(tīng)器，當(dāng)消息到達(dá)之后，系統(tǒng)會(huì)自動(dòng)調(diào)用監(jiān)聽(tīng)器MessageListener的onMessage(Message message)方法。 - 隊(duì)列的特點(diǎn)：
①每個(gè)消息只能有一個(gè)消費(fèi)者，類似1對(duì)1的關(guān)系。好比個(gè)人快遞自己領(lǐng)取自己的。
②消息的生產(chǎn)者和消費(fèi)者之間沒(méi)有時(shí)間上的相關(guān)性。無(wú)論消費(fèi)者在生產(chǎn)者發(fā)送消息的時(shí)候是否處于運(yùn)行狀態(tài)，消費(fèi)者都可以提取消息。好比我們的發(fā)送短信，發(fā)送者發(fā)送后不見(jiàn)得接收者會(huì)即收即看。
③消息被消費(fèi)后隊(duì)列中不會(huì)再存儲(chǔ)，所以消費(fèi)者不會(huì)消費(fèi)到已經(jīng)被消費(fèi)掉的消息。 - 消息消費(fèi)情況：
①情況1：只啟動(dòng)消費(fèi)者1。結(jié)果：消費(fèi)者1會(huì)消費(fèi)所有的數(shù)據(jù)。
②情況2：先啟動(dòng)消費(fèi)者1，再啟動(dòng)消費(fèi)者2。結(jié)果：消費(fèi)者1消費(fèi)所有的數(shù)據(jù)。消費(fèi)者2不會(huì)消費(fèi)到消息。
③情況3：生產(chǎn)者發(fā)布6條消息，在此之前已經(jīng)啟動(dòng)了消費(fèi)者1和消費(fèi)者2。結(jié)果：消費(fèi)者1和消費(fèi)者2平攤了消息。各自消費(fèi)3條消息。
④疑問(wèn)：怎么去將消費(fèi)者1和消費(fèi)者2不平均分?jǐn)偰?#xff1f;而是按照各自的消費(fèi)能力去消費(fèi)。我覺(jué)得，現(xiàn)在activemq就是這樣的機(jī)制。
主題消息(Topic)介紹：
- 在發(fā)布訂閱消息傳遞域中，目的地被稱為主題（topic）
- 發(fā)布/訂閱消息傳遞域的特點(diǎn)如下：
①生產(chǎn)者將消息發(fā)布到topic中，每個(gè)消息可以有多個(gè)消費(fèi)者，屬于1：N的關(guān)系；
②生產(chǎn)者和消費(fèi)者之間有時(shí)間上的相關(guān)性。訂閱某一個(gè)主題的消費(fèi)者只能消費(fèi)自它訂閱之后發(fā)布的消息。
③生產(chǎn)者生產(chǎn)時(shí)，topic不保存消息它是無(wú)狀態(tài)的不落地，假如無(wú)人訂閱就去生產(chǎn)，那就是一條廢消息，所以，一般先啟動(dòng)消費(fèi)者再啟動(dòng)生產(chǎn)者。
④默認(rèn)情況下如上所述，但是JMS規(guī)范允許客戶創(chuàng)建持久訂閱，這在一定程度上放松了時(shí)間上的相關(guān)性要求。持久訂閱允許消費(fèi)者消費(fèi)它在未處于激活狀態(tài)時(shí)發(fā)送的消息。一句話，好比我們的微信公眾號(hào)訂閱
tpoic和queue對(duì)比：
| 工作模式. | “訂閱-發(fā)布"模式，如果當(dāng)前沒(méi)有訂閱者，消息將會(huì)被丟棄。如果有多個(gè)訂閱者，那么這些訂閱者都會(huì)收到消息 | “負(fù)載均衡"模式，如果當(dāng)前沒(méi)有消費(fèi)者，消息也不會(huì)云棄;如果有多個(gè)消費(fèi)者，那么—條消息也只會(huì)發(fā)送始其中一個(gè)消費(fèi)者，并且要求消費(fèi)者ack信息 |
| 有無(wú)狀態(tài) | 無(wú)狀態(tài) | Queue數(shù)據(jù)默認(rèn)會(huì)在mq服務(wù)器上以文件形式保存，比如Active MQ—般保存在SAMQ_HOME\datakr-storeldata下面。也可以配置成DB存儲(chǔ)。 |
| 傳遞完整性 | 如果沒(méi)有訂閱者，消息會(huì)被丟棄 | 消息不會(huì)云棄 |
| 處理效率 | 由于消息要按照訂閱者的數(shù)量進(jìn)行復(fù)制，所以處理性能會(huì)隨著訂閱者的增加而明顯降低,并且還要結(jié)合不同消息協(xié)議自身的性能差異 | 由于—條消息只發(fā)送給—個(gè)消費(fèi)者，所以就算消費(fèi)者再多，性能也不會(huì)有明顯降低。當(dāng)然不同消息協(xié)議的具體性能也是有差異的 |
JMS規(guī)范與落地
JMS是什么：
- JMS是Java消息服務(wù)
- Java消息服務(wù)指的是兩個(gè)應(yīng)用程序之間進(jìn)行異步通信的API，它為標(biāo)準(zhǔn)協(xié)議和消息服務(wù)提供了一組通用接口，包括創(chuàng)建、發(fā)送、讀取消息等，用于支持Java應(yīng)用程序開(kāi)發(fā)。在JavaEE中，當(dāng)兩個(gè)應(yīng)用程序使用JMS進(jìn)行通信時(shí)，它們之間不是直接相連的，而是通過(guò)一個(gè)共同的消息收發(fā)服務(wù)組件關(guān)聯(lián)起來(lái)以達(dá)到解耦/異步削峰的效果。
JMS的組成結(jié)構(gòu)和特點(diǎn)：
消息頭：
- JMS的消息頭有哪些屬性：
①JMSDestination：消息目的地
②JMSDeliveryMode：消息持久化模式
③JMSExpiration：消息過(guò)期時(shí)間
④JMSPriority：消息的優(yōu)先級(jí)
⑤JMSMessageID：消息的唯一標(biāo)識(shí)符。后面我們會(huì)介紹如何解決冪等性。 - 說(shuō)明： 消息的生產(chǎn)者可以set這些屬性，消息的消費(fèi)者可以get這些屬性。這些屬性在send方法里面也可以設(shè)置。
消息體：
- 封裝具體的消息數(shù)據(jù)
- 5種消息體格式：
①TextMessage——普通字符串消息，包含一個(gè)string
②MapMessage——一個(gè)Map類型的消息，key為string類型，而值為Java的基本類型
③BytesMessage——二進(jìn)制數(shù)組消息，包含一個(gè)byte[]
④StreamMessage——Java數(shù)據(jù)流消息，用標(biāo)準(zhǔn)流操作來(lái)順序的填充和讀取。
⑤ObjectMessage——對(duì)象消息，包含一個(gè)可序列化的Java對(duì)象 - 發(fā)送和接受的消息體類型必須一致對(duì)應(yīng)
消息屬性：
- 如果需要除消息頭字段之外的值，那么可以使用消息屬性。他是識(shí)別/去重/重點(diǎn)標(biāo)注等操作，非常有用的方法。
- 他們是以屬性名和屬性值對(duì)的形式制定的?？梢詫傩允菫橄㈩^得擴(kuò)展，屬性指定一些消息頭沒(méi)有包括的附加信息，比如可以在屬性里指定消息選擇器。消息的屬性就像可以分配給一條消息的附加消息頭一樣。它們?cè)试S開(kāi)發(fā)者添加有關(guān)消息的不透明附加信息。它們還用于暴露消息選擇器在消息過(guò)濾時(shí)使用的數(shù)據(jù)。
- 下圖是設(shè)置消息屬性的API：set對(duì)應(yīng)類型Property(String name，對(duì)應(yīng)類型 value)
JMS的可靠性：
- PERSISTENT：持久性
- Transaction：事務(wù)
- Acknowledge：簽收
消息的持久化：
- 什么是持久化消息？
①保證消息只被傳送一次和成功使用一次。在持久性消息傳送至目標(biāo)時(shí)，消息服務(wù)將其放入持久性數(shù)據(jù)存儲(chǔ)。如果消息服務(wù)由于某種原因?qū)е率?#xff0c;它可以恢復(fù)此消息并將此消息傳送至相應(yīng)的消費(fèi)者。雖然這樣增加了消息傳送的開(kāi)銷，但卻增加了可靠性。
②我的理解：在消息生產(chǎn)者將消息成功發(fā)送給MQ消息中間件之后。無(wú)論是出現(xiàn)任何問(wèn)題，如：MQ服務(wù)器宕機(jī)、消費(fèi)者掉線等。都保證（topic要之前注冊(cè)過(guò)，queue不用）消息消費(fèi)者，能夠成功消費(fèi)消息。如果消息生產(chǎn)者發(fā)送消息就失敗了，那么消費(fèi)者也不會(huì)消費(fèi)到該消息。 - 參數(shù)設(shè)置說(shuō)明：
①非持久：非持久化：當(dāng)服務(wù)器宕機(jī)，消息不存在。
messageProducer.setDeliveryMode(DeliveryMode.NON_PERSISTENT)
②持久：持久化：當(dāng)服務(wù)器宕機(jī)，消息依然存在。
messageProducer.setDeliveryMode(DeliveryMode.PERSISTENT)
③Queue默認(rèn)是持久。 - 持久的Queue：持久化消息這是隊(duì)列的默認(rèn)傳遞模式，此模式保證這些消息只被傳送一次和成功使用一次。對(duì)于這些消息，可靠性是優(yōu)先考慮的因素?？煽啃缘牧硪粋€(gè)重要方面是確保持久性消息傳送至目標(biāo)后，消息服務(wù)在向消費(fèi)者傳送它們之前不會(huì)丟失這些消息。
- 持久的Topic：一定要先運(yùn)行一次消費(fèi)者,類似于像MQ注冊(cè),我訂閱了這個(gè)主題。然后再運(yùn)行主題生產(chǎn)者，無(wú)論消費(fèi)著是否在線,都會(huì)接收到,在線的立即接收到,不在線的等下次上線把沒(méi)接收到的接收。類似微信公眾號(hào)訂閱發(fā)布。
消息事務(wù)：
- producer提交時(shí)的事務(wù)：
①false：只要執(zhí)行send，就進(jìn)入到隊(duì)列中，關(guān)閉事務(wù)，那第2個(gè)簽收參數(shù)的設(shè)置需要有效。
②true：先執(zhí)行send再執(zhí)行commit，消息才被真正提交到隊(duì)列中，消息需要需要批量提交，需要緩沖處理。 - consumer消費(fèi)時(shí)的事務(wù)：
①false：activeMQ默認(rèn)認(rèn)為你執(zhí)行了commit，消費(fèi)了消息。
②true：只有執(zhí)行了commit，activeMQ才認(rèn)為你消費(fèi)了消息，控制臺(tái)的消費(fèi)數(shù)才會(huì)上升。不執(zhí)行commit的話，會(huì)重復(fù)消費(fèi)消息！ - 事務(wù)偏生產(chǎn)者/簽收偏消費(fèi)者！
消息簽收：
- 非事務(wù)：
①自動(dòng)簽收（Session.AUTO_ACKNOWLEDGE）：該方式是默認(rèn)的。該種方式，無(wú)需我們程序做任何操作，框架會(huì)幫我們自動(dòng)簽收收到的消息。
②手動(dòng)簽收（Session.CLIENT_ACKNOWLEDGE）：手動(dòng)簽收。該種方式，需要我們手動(dòng)調(diào)用Message.acknowledge()，來(lái)簽收消息。如果不簽收消息，該消息會(huì)被我們反復(fù)消費(fèi)，只到被簽收。
③允許重復(fù)消息（Session.DUPS_OK_ACKNOWLEDGE）：多線程或多個(gè)消費(fèi)者同時(shí)消費(fèi)到一個(gè)消息，因?yàn)榫€程不安全，可能會(huì)重復(fù)消費(fèi)。該種方式很少使用到。
④事務(wù)下的簽收（Session.SESSION_TRANSACTED）：開(kāi)始事務(wù)的情況下，可以使用該方式。該種方式很少使用到。 - 事務(wù)：
①由于消費(fèi)者開(kāi)啟了事務(wù),沒(méi)有提交事務(wù)(就算手動(dòng)簽收也沒(méi)用),服務(wù)器認(rèn)為,消費(fèi)者沒(méi)有收到消息。
②生產(chǎn)事務(wù)開(kāi)啟，只有commit后才能將全部消息變?yōu)橐严M(fèi)。 - 簽收和事務(wù)的關(guān)系：
①在事務(wù)性會(huì)話中，當(dāng)一個(gè)事務(wù)被成功提交則消息被自動(dòng)簽收。如果事務(wù)回滾，則消息會(huì)被再次傳送。事務(wù)優(yōu)先于簽收，開(kāi)始事務(wù)后，簽收機(jī)制不再起任何作用。
②非事務(wù)性會(huì)話中，消息何時(shí)被確認(rèn)取決于創(chuàng)建會(huì)話時(shí)的應(yīng)答模式。
③消費(fèi)者事務(wù)開(kāi)啟，只有commit后才能將全部消息變?yōu)橐严M(fèi)。
④事務(wù)偏向生產(chǎn)者，簽收偏向消費(fèi)者。也就是說(shuō)生產(chǎn)者使用事務(wù)更好點(diǎn)，消費(fèi)者使用簽收機(jī)制更好點(diǎn)。
JMS的點(diǎn)對(duì)點(diǎn)總結(jié)：
- 點(diǎn)對(duì)點(diǎn)模型是基于隊(duì)列的，生產(chǎn)者發(fā)送消息到隊(duì)列，消費(fèi)者從隊(duì)列接收消息，隊(duì)列的存在使得消息的異步傳輸成為可能。和我們平時(shí)給朋友發(fā)送短信類似。
①如果在Session關(guān)閉時(shí)有部分消息被收到但還沒(méi)有被簽收（acknowledge），那當(dāng)消費(fèi)者下次連接到相同的隊(duì)列時(shí)，這些消息還會(huì)被再次接收。
②隊(duì)列可以長(zhǎng)久的保存消息直到消費(fèi)者收到消息。消費(fèi)者不需要因?yàn)閾?dān)心消息會(huì)丟失而時(shí)刻和隊(duì)列保持激活的鏈接狀態(tài)，充分體現(xiàn)了異步傳輸模式的優(yōu)勢(shì)
JMS的發(fā)布訂閱總結(jié)：
- 非持久訂閱：
①非持久訂閱只有當(dāng)客戶端處于激活狀態(tài)，也就是和MQ保持連接狀態(tài)才能收發(fā)到某個(gè)主題的消息。如果消費(fèi)者處于離線狀態(tài)，生產(chǎn)者發(fā)送的主題消息將會(huì)丟失作廢，消費(fèi)者永遠(yuǎn)不會(huì)收到。一句話：先訂閱注冊(cè)才能接受到發(fā)布，只給訂閱者發(fā)布消息。 - 持久訂閱：
①客戶端首先向MQ注冊(cè)一個(gè)自己的身份ID識(shí)別號(hào)，當(dāng)這個(gè)客戶端處于離線時(shí)，生產(chǎn)者會(huì)為這個(gè)ID保存所有發(fā)送到主題的消息，當(dāng)客戶再次連接到MQ的時(shí)候，會(huì)根據(jù)消費(fèi)者的ID得到所有當(dāng)自己處于離線時(shí)發(fā)送到主題的消息當(dāng)持久訂閱狀態(tài)下，不能恢復(fù)或重新派送一個(gè)未簽收的消息。持久訂閱才能恢復(fù)或重新派送一個(gè)未簽收的消息。 - 用哪個(gè)?
①當(dāng)所有的消息必須被接收，則用持久訂閱。當(dāng)消息丟失能夠被容忍，則用非持久訂閱。
ActiveMQ的broker
簡(jiǎn)介：
- 相當(dāng)于一個(gè)ActiveMQ服務(wù)器實(shí)例說(shuō)白了，Broker其實(shí)就是實(shí)現(xiàn)了用代碼的形式啟動(dòng)ActiveMQ將MQ嵌入到Java代碼中，以便隨時(shí)用隨時(shí)啟動(dòng)，在用的時(shí)候再去啟動(dòng)這樣能節(jié)省了資源，也保證了可用性。
嵌入式Broker：
- POM.XML：
- 主啟動(dòng)類：
- 和Linux上的ActiveMQ是一樣的,Broker相當(dāng)于一個(gè)Mini版本的ActiveMQ
Spring，SpringBoot整合ActiveMQ
Spring整合ActiveMQ：
- Maven修改，需要添加Spring支持JMS的包：
- Spring配置文件：
- 隊(duì)列（Queue）：
- 主題（Topic）：
- 在Spring里面實(shí)現(xiàn)消費(fèi)者不啟動(dòng)，直接通過(guò)配置監(jiān)聽(tīng)完成：
SpringBoot整合ActiveMQ：
- POM文件：
- YML文件：
- 配置bean：
- 隊(duì)列(queue)：
- 主題(topic)：
- 持久化訂閱：
SpringBoot整合ActiveMQ之Queue與Topoic并存：
- application.properties中定義相關(guān)配置項(xiàng)：
- 定義配置類：
- 定義監(jiān)聽(tīng)器實(shí)現(xiàn)：
ActiveMQ的傳輸協(xié)議
ActiveMQ傳輸協(xié)議簡(jiǎn)介：
- ActiveMQ支持的client-broker通訊協(xié)議有：TVP、NIO、UDP、SSL、Http(s)、VM。
- 其中配置Transport Connector的文件在ActiveMQ安裝目錄的conf/activemq.xml中的標(biāo)簽之內(nèi)。見(jiàn)下圖實(shí)際配置：
- 在上文給出的配置信息中，URI描述信息的頭部都是采用協(xié)議名稱：例如描述
①amqp協(xié)議的監(jiān)聽(tīng)端口時(shí)，采用的URI描述格式為“amqp://······”；
②描述Stomp協(xié)議的監(jiān)聽(tīng)端口時(shí)，采用URI描述格式為“stomp://······”；
③唯獨(dú)在進(jìn)行openwire協(xié)議描述時(shí)，URI頭卻采用的“tcp://······”。這是因?yàn)锳ctiveMQ中默認(rèn)的消息協(xié)議就是openwire
ActiveMQ傳輸協(xié)議有哪些：
- Transmission Control Protocol(TCP)默認(rèn)：
①這是默認(rèn)的Broker配置，TCP的Client監(jiān)聽(tīng)端口61616
②在網(wǎng)絡(luò)傳輸數(shù)據(jù)前，必須要先序列化數(shù)據(jù)，消息是通過(guò)一個(gè)叫wire protocol的來(lái)序列化成字節(jié)流。 ③TCP連接的URI形式如：tcp://HostName:port?key=value&key=value，后面的參數(shù)是可選的。 ④TCP傳輸?shù)牡膬?yōu)點(diǎn)：
<1>TCP協(xié)議傳輸可靠性高，穩(wěn)定性強(qiáng)
<2>高效率：字節(jié)流方式傳遞，效率很高
<3>有效性、可用性：應(yīng)用廣泛，支持任何平臺(tái)
⑤關(guān)于Transport協(xié)議的可選配置參數(shù)可以參考官網(wǎng) - New I/O API Protocol(NIO)：
①NIO協(xié)議和TCP協(xié)議類似，但NIO更側(cè)重于底層的訪問(wèn)操作。它允許開(kāi)發(fā)人員對(duì)同一資源可有更多的client調(diào)用和服務(wù)器端有更多的負(fù)載。
②適合使用NIO協(xié)議的場(chǎng)景：
<1>可能有大量的Client去連接到Broker上，一般情況下，大量的Client去連接Broker是被操作系統(tǒng)的線程所限制的。因此，NIO的實(shí)現(xiàn)比TCP需要更少的線程去運(yùn)行，所以建議使用NIO協(xié)議。
<2>可能對(duì)于Broker有一個(gè)很遲鈍的網(wǎng)絡(luò)傳輸，NIO比TCP提供更好的性能。
③NIO連接的URI形式：nio://hostname:port?key=value&key=value
④關(guān)于Transport協(xié)議的可選配置參數(shù)可以參考官網(wǎng) - AMQP協(xié)議：
①Advanced Message Queuing Protocol，一個(gè)提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級(jí)消息隊(duì)列協(xié)議，是應(yīng)用層協(xié)議的一個(gè)開(kāi)放標(biāo)準(zhǔn)，為面向消息的中間件設(shè)計(jì)。
②基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同開(kāi)發(fā)語(yǔ)言等條件限制。 - Stomp協(xié)議：
①STOMP，Streaming Text Orientation Message Protocol，是流文本定向消息協(xié)議，是一種為MOM(Message Oriented Middleware，面向消息中間件)設(shè)計(jì)的簡(jiǎn)單文本協(xié)議。 - Secure Sockets Layer Protocol(SSL)：
①安全加密協(xié)議。 - MQTT協(xié)議：
①M(fèi)QTT(Message Queuing Telemetry Transport，消息隊(duì)列遙測(cè)傳輸)是IBM開(kāi)發(fā)的一個(gè)即時(shí)通訊協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。該協(xié)議支持所有平臺(tái)，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來(lái)，被用來(lái)當(dāng)作傳感器和致動(dòng)器(比如通過(guò)Twitter讓房屋聯(lián)網(wǎng))的通信協(xié)議。 - WS協(xié)議(websocket)：
①websocket協(xié)議。
配置nio協(xié)議：
- ActiveMQ這些協(xié)議傳輸?shù)牡讓幽J(rèn)都是使用BIO網(wǎng)絡(luò)的IO模型。只有當(dāng)我們指定使用nio才使用NIO的IO模型。
- 修改配置文件activemq.xml：
①在<transportConnectors>節(jié)點(diǎn)下添加如下內(nèi)容：
<transportConnector name="nio" uri="nio://0.0.0.0:61618?trace=true" />
②修改完成后重啟activemq：service activemq restart
③查看管理后臺(tái)，可以看到頁(yè)面多了nio - NIO協(xié)議增強(qiáng)：
①URI格式以"nio"開(kāi)頭，代表這個(gè)端口使用TCP協(xié)議為基礎(chǔ)的NIO網(wǎng)絡(luò)模型。但是這樣的設(shè)置方式，只能使這個(gè)端口支持Openwire協(xié)議。
②如果我們既需要使用某一個(gè)端口支持NIO網(wǎng)絡(luò)模型,又需要它支持多個(gè)協(xié)議：
<1>可以使用auto關(guān)鍵字
<2>使用"+"符號(hào)來(lái)為端口設(shè)置多種特性
③配置：<transportConnector name="auto+nio" uri="auto+nio://localhost:5671"/>
ActiveMQ的消息存儲(chǔ)和持久化
ActiveMQ的消息持久化簡(jiǎn)介：
- 為了避免意外宕機(jī)以后丟失信息，需要做到重啟后可以恢復(fù)消息隊(duì)列，消息系統(tǒng)一半都會(huì)采用持久化機(jī)制。ActiveMQ的消息持久化機(jī)制有JDBC，AMQ，KahaDB和LevelDB，無(wú)論使用哪種持久化方式，消息的存儲(chǔ)邏輯都是一致的。
- 就是在發(fā)送者將消息發(fā)送出去后，消息中心首先將消息存儲(chǔ)到本地?cái)?shù)據(jù)文件、內(nèi)存數(shù)據(jù)庫(kù)或者遠(yuǎn)程數(shù)據(jù)庫(kù)等。再試圖將消息發(fā)給接收者，成功則將消息從存儲(chǔ)中刪除，失敗則繼續(xù)嘗試嘗試發(fā)送。消息中心啟動(dòng)以后，要先檢查指定的存儲(chǔ)位置是否有未成功發(fā)送的消息，如果有，則會(huì)先把存儲(chǔ)位置中的消息發(fā)出去。
- 一句話：ActiveMQ宕機(jī)了，消息不會(huì)丟失的機(jī)制。
ActiveMQ的消息持久化有哪些：
- AMQ Mesage Store(了解）：
①AMQ是一種文件存儲(chǔ)形式，它具有寫入速度快和容易恢復(fù)的特點(diǎn)。消息存儲(chǔ)再一個(gè)個(gè)文件中文件的默認(rèn)大小為32M，當(dāng)一個(gè)文件中的消息已經(jīng)全部被消費(fèi)，那么這個(gè)文件將被標(biāo)識(shí)為可刪除，在下一個(gè)清除階段，這個(gè)文件被刪除。AMQ適用于ActiveMQ5.3之前的版本。
②基于文件的存儲(chǔ)方式，是以前的默認(rèn)消息存儲(chǔ)，現(xiàn)在不用了。 - KahaDB消息存儲(chǔ)(默認(rèn))：
①基于日志文件，從ActiveMQ5.4開(kāi)始默認(rèn)的持久化插件。
②KahaDB是目前默認(rèn)的存儲(chǔ)方式，可用于任何場(chǎng)景，提高了性能和恢復(fù)能力。消息存儲(chǔ)使用一個(gè)事務(wù)日志和僅僅用一個(gè)索引文件來(lái)存儲(chǔ)它所有的地址。KahaDB是一個(gè)專門針對(duì)消息持久化的解決方案，它對(duì)典型的消息使用模型進(jìn)行了優(yōu)化。數(shù)據(jù)被追加到data logs中。當(dāng)不再需要log文件中的數(shù)據(jù)的時(shí)候，log文件會(huì)被丟棄。 - JDBC消息存儲(chǔ)：使用JDBC。
- LevelDB消息存儲(chǔ)(了解)：
①這種文件系統(tǒng)是從ActiveMQ5.8之后引進(jìn)的，它和KahaDB非常相似，也是基于文件的本地?cái)?shù)據(jù)庫(kù)存儲(chǔ)形式，但是它提供比KahaDB更快的持久性。
②但它不使用自定義B-Tree實(shí)現(xiàn)來(lái)索引獨(dú)寫日志，而是使用基于LevelDB的索引。 - JDBC Message Store with ActiveMQ Journal：JDBC加強(qiáng)版。
KahaDB的存儲(chǔ)原理：
- KahaDB在消息保存的目錄中有4類文件和一個(gè)lock，跟ActiveMQ的其他幾種文件存儲(chǔ)引擎相比，這就非常簡(jiǎn)潔了。
①db-number.log：KahaDB存儲(chǔ)消息到預(yù)定大小的數(shù)據(jù)紀(jì)錄文件中，文件名為db-number.log。當(dāng)數(shù)據(jù)文件已滿時(shí)，一個(gè)新的文件會(huì)隨之創(chuàng)建，number數(shù)值也會(huì)隨之遞增，它隨著消息數(shù)量的增多，如沒(méi)32M一個(gè)文件，文件名按照數(shù)字進(jìn)行編號(hào)，如db-1.log，db-2.log······。當(dāng)不再有引用到數(shù)據(jù)文件中的任何消息時(shí)，文件會(huì)被刪除或者歸檔。
②db.data： 該文件包含了持久化的BTree索引，索引了消息數(shù)據(jù)記錄中的消息，它是消息的索引文件，本質(zhì)上是B-Tree（B樹），使用B-Tree作為索引指向db-number。log里面存儲(chǔ)消息。
③db.free：當(dāng)問(wèn)當(dāng)前db.data文件里面哪些頁(yè)面是空閑的，文件具體內(nèi)容是所有空閑頁(yè)的ID
④db.redo：用來(lái)進(jìn)行消息恢復(fù)，如果KahaDB消息存儲(chǔ)再?gòu)?qiáng)制退出后啟動(dòng)，用于恢復(fù)BTree索引。
⑤lock：文件鎖，表示當(dāng)前kahadb獨(dú)寫權(quán)限的broker。
JDBC存儲(chǔ)消息：
- 添加mysql數(shù)據(jù)庫(kù)的驅(qū)動(dòng)包到lib文件夾
- jdbcPersistenceAdapter配置：
①dataSource指定將要引用的持久化數(shù)據(jù)庫(kù)的bean名稱。
②createTablesOnStartup是否在啟動(dòng)的時(shí)候創(chuàng)建數(shù)據(jù)表，默認(rèn)值是true,這樣每次啟動(dòng)都會(huì)去創(chuàng)建數(shù)據(jù)表了，一股是第一次啟動(dòng)的時(shí)候設(shè)置為true之后改成false。
- 數(shù)據(jù)庫(kù)連接池配置：
- 建庫(kù)SQL和創(chuàng)表說(shuō)明：
①建一個(gè)名為activemq的數(shù)據(jù)庫(kù)
②如果新建數(shù)據(jù)庫(kù)ok，上述配置ok，代碼運(yùn)行ok，3張表會(huì)自動(dòng)生成
③如果表沒(méi)生成，可能需要自己創(chuàng)建
②三張表的說(shuō)明：
<1>ACTIVEMQ_MSGS
<2>ACTIVEMQ_ACKS
<3>ACTIVEMQ_LOCK
- 驗(yàn)證總結(jié)：
①點(diǎn)對(duì)點(diǎn)：在點(diǎn)對(duì)點(diǎn)類型中當(dāng)DeliveryMode設(shè)置為NON_PERSISTENCE時(shí)，消息被保存在內(nèi)存中當(dāng)DeliveryMode設(shè)置為PERSISTENCE時(shí)，消息保存在broker的相應(yīng)的文件或者數(shù)據(jù)庫(kù)中。而且點(diǎn)對(duì)點(diǎn)類型中消息一旦被Consumer消費(fèi)，就從數(shù)據(jù)中刪除。消費(fèi)前的消息會(huì)被存放到數(shù)據(jù)庫(kù)，上面的消息被消費(fèi)后被MQ自動(dòng)刪除。
②發(fā)布/訂閱：設(shè)置了持久訂閱數(shù)據(jù)庫(kù)里面會(huì)保存訂閱者的信息，消費(fèi)者消費(fèi)所有的數(shù)據(jù)后。ACTIVEMQ_MSGS數(shù)據(jù)表的數(shù)據(jù)并沒(méi)有消失。持久化topic的消息不管是否被消費(fèi)，是否有消費(fèi)者，產(chǎn)生的數(shù)據(jù)永遠(yuǎn)都存在，且只存儲(chǔ)一條。這個(gè)是要注意的，持久化的topic大量數(shù)據(jù)后可能導(dǎo)致性能下降。這里就像公總號(hào)一樣，消費(fèi)者消費(fèi)完后，消息還會(huì)保留。 - 小總結(jié)：
①如果是queue在沒(méi)有消費(fèi)者消費(fèi)的情況下會(huì)將消息保存到activemq_msgs表中，只要有任意一個(gè)消費(fèi)者消費(fèi)了，就會(huì)刪除。
②消費(fèi)過(guò)的消息如果是topic，一般是先啟動(dòng)消費(fèi)訂閱者然后再生產(chǎn)的情況下會(huì)將持久訂閱者永久保存到qctivemq_acks，而消息則永久保存在activemq_msgs，在acks表中的訂閱者有一個(gè)last_ack_id對(duì)應(yīng)了activemq_msgs中的id字段，這樣就知道訂閱者最后收到的消息是哪一條。 - 注意：
①在配置關(guān)系型數(shù)據(jù)庫(kù)作為ActiveMQ的持久化存儲(chǔ)方案時(shí)，有坑 數(shù)據(jù)庫(kù)jar包注意把對(duì)應(yīng)版本的數(shù)據(jù)庫(kù)jar或者你自己使用的非自帶的數(shù)據(jù)庫(kù)連接池jar包
②createTablesOnStartup屬性默認(rèn)為true，每次啟動(dòng)activemq都會(huì)自動(dòng)創(chuàng)建表，在第一次啟動(dòng)后，應(yīng)改為false，避免不必要的損失。
③java.lang.IllegalStateException: LifecycleProcessor not initialized確認(rèn)計(jì)算機(jī)主機(jī)名名稱沒(méi)有下劃線
JDBC Message store with ActiveMQ Journal：
- 說(shuō)明：
①這種方式克服了JDBC Store的不足，JDBC每次消息過(guò)來(lái)，都需要去寫庫(kù)讀庫(kù)。ActiveMQ Journal，使用高速緩存寫入技術(shù)，大大提高了性能。當(dāng)消費(fèi)者的速度能夠及時(shí)跟上生產(chǎn)者消息的生產(chǎn)速度時(shí)，journal文件能夠大大減少需要寫入到DB中的消息。
②舉個(gè)例子：生產(chǎn)者生產(chǎn)了1000條消息，這1000條消息會(huì)保存到j(luò)ournal文件，如果消費(fèi)者的消費(fèi)速度很快的情況下，在journal文件還沒(méi)有同步到DB之前，消費(fèi)者已經(jīng)消費(fèi)了90%的以上消息，那么這個(gè)時(shí)候只需要同步剩余的10%的消息到DB。如果消費(fèi)者的速度很慢，這個(gè)時(shí)候journal文件可以使消息以批量方式寫到DB。
③為了高性能，這種方式使用日志文件存儲(chǔ)+數(shù)據(jù)庫(kù)存儲(chǔ)。先將消息持久到日志文件，等待一段時(shí)間再將未消費(fèi)的消息持久到數(shù)據(jù)庫(kù)。該方式要比JDBC性能要高。 - 配置：
- 總結(jié)：以前是實(shí)時(shí)寫入mysql，在使用了journal后，數(shù)據(jù)會(huì)被journal處理，如果在一定時(shí)間內(nèi)journal處理（消費(fèi)）完了，就不寫入mysql，如果沒(méi)消費(fèi)完，就寫入mysql，起到一個(gè)緩存的作用
總結(jié)：
- jdbc效率低，kahaDB效率高，jdbc+Journal效率較高。
- 持久化消息主要指的是：MQ所在服務(wù)器宕機(jī)了消息不會(huì)丟試的機(jī)制。
- 持久化機(jī)制演變的過(guò)程：從最初的AMQ Message Store方案到ActiveMQ V4版本退出的High Performance Journal（高性能事務(wù)支持）附件，并且同步推出了關(guān)于關(guān)系型數(shù)據(jù)庫(kù)的存儲(chǔ)方案。ActiveMQ5.3版本又推出了對(duì)KahaDB的支持（5.4版本后被作為默認(rèn)的持久化方案），后來(lái)ActiveMQ 5.8版本開(kāi)始支持LevelDB，到現(xiàn)在5.9提供了標(biāo)準(zhǔn)的Zookeeper+LevelDB集群化方案。
- ActiveMQ消息持久化機(jī)制有：
| AMQ | 基于日志文件 |
| KahaDB | 基于日志文件，從ActiveMQ5.4開(kāi)始默認(rèn)使用 |
| JDBC | 基于第三方數(shù)據(jù)庫(kù) |
| Replicated LevelDB Store | 從5.9開(kāi)始提供了LevelDB和Zookeeper的數(shù)據(jù)復(fù)制方法，用于Master-slave方式的首選數(shù)據(jù)復(fù)制方案。 |
ActiveMQ多節(jié)點(diǎn)集群
簡(jiǎn)介：
- 基于zookeeper和LevelDB搭建ActiveMQ集群。集群僅提供主備方式的高可用集群功能，避免單點(diǎn)故障。
- 引入消息隊(duì)列之后該如何保證其高可用性。
三種集群方式對(duì)比：
- 基于shareFileSystem共享文件系統(tǒng)（KahaDB）
- 基于JDBC
- 基于可復(fù)制的LevelDB
官網(wǎng)集群原理圖：
- 使用Zookeeper集群注冊(cè)所有的ActiveMQBroker但只有其中一個(gè)Broker可以提供服務(wù)，它將被視為Master,其他的Broker處于待機(jī)狀態(tài)被視為Slave。如果Master因故障而不能提供服務(wù)，Zookeeper會(huì)從Slave中選舉出一個(gè)Broker充當(dāng)Master。Slave連接Master并同步他們的存儲(chǔ)狀態(tài)，Slave不接受客戶端連接。所有的存儲(chǔ)操作都將被復(fù)制到連接至Maste的Slaves。如果Master宕機(jī)得到了最新更新的Slave會(huì)變成Master。故障節(jié)點(diǎn)在恢復(fù)后會(huì)重新加入到集群中并連接Master進(jìn)入Slave模式。所有需要同步的消息操作都將等待存儲(chǔ)狀態(tài)被復(fù)制到其他法定節(jié)點(diǎn)的操作完成才能完成。
- 所以，如給你配置了replicas=3，name法定大小是（3/2）+1 =2。Master將會(huì)存儲(chǔ)更新然后等待（2-1）=1個(gè)Slave存儲(chǔ)和更新完成，才匯報(bào)success，至于為什么是2-1，陽(yáng)哥的zookeeper講解過(guò)自行復(fù)習(xí)。有一個(gè)ode要作為觀察者存在。當(dāng)一個(gè)新的Master被選中，你需要至少保障一個(gè)法定mode在線以能夠找到擁有最新?tīng)顟B(tài)的ode，這個(gè)ode才可以成為新的Master。因此，推薦運(yùn)行至少3個(gè)replica nodes以防止一個(gè)node失敗后服務(wù)中斷。
zookeeper+replicated-leveldb-store的主從集群簡(jiǎn)介：
ActiveMQ高級(jí)特性
異步投遞Async Sends簡(jiǎn)介：
- 對(duì)于一個(gè)Slow Consumer,使用同步發(fā)送消息可能出現(xiàn)Producer堵塞的情況,慢消費(fèi)者適合使用異步發(fā)送。
- 同步發(fā)送與異步發(fā)送詳解：
①ActiveMQ支持同步，異步兩種發(fā)送的模式將消息發(fā)送到broker，模式的選擇對(duì)發(fā)送延時(shí)有巨大的影響。producer能達(dá)到怎么樣的產(chǎn)出率（產(chǎn)出率=發(fā)送數(shù)據(jù)總量/時(shí)間）主要受發(fā)送延時(shí)的影響，使用異步發(fā)送可以顯著提高發(fā)送的性能。
②ActiveMQ默認(rèn)使用異步發(fā)送的模式：除非明確指定使用同步發(fā)送的方式或者在未使用事務(wù)的前提下發(fā)送持久化的消息，這兩種情況都是同步發(fā)送的。
③如果你沒(méi)有使用事務(wù)且發(fā)送的是持久化的消息，每一次發(fā)送都是同步發(fā)送的且會(huì)阻塞producer知道broker返回一個(gè)確認(rèn)，表示消息已經(jīng)被安全的持久化到磁盤。確認(rèn)機(jī)制提供了消息安全的保障，但同時(shí)會(huì)阻塞客戶端帶來(lái)了很大的延時(shí)。
④很多高性能的應(yīng)用，允許在失敗的情況下有少量的數(shù)據(jù)丟失。如果你的應(yīng)用滿足這個(gè)特點(diǎn)，你可以使用異步發(fā)送來(lái)提高生產(chǎn)率，即使發(fā)送的是持久化的消息。
⑤異步發(fā)送它可以最大化producer端的發(fā)送效率。我們通常在發(fā)送消息量比較密集的情況下使用異步發(fā)送，它可以很大的提升Producer性能；不過(guò)這也帶來(lái)了額外的問(wèn)題，就是需要消耗更多的Client端內(nèi)存同時(shí)也會(huì)導(dǎo)致broker端性能消耗增加；此外它不能有效的確保消息的發(fā)送成功。在userAsyncSend=true的情況下客戶端需要容忍消息丟失的可能。 - 異步發(fā)送配置：
- 異步消息如何確定發(fā)送成功?
①異步發(fā)送丟失消息的場(chǎng)景是：生產(chǎn)者設(shè)置userAsyncSend=true，使用producer.send(msg)持續(xù)發(fā)送消息。如果消息不阻塞，生產(chǎn)者會(huì)認(rèn)為所有send的消息均被成功發(fā)送至MQ。如果MQ突然宕機(jī)，此時(shí)生產(chǎn)者端內(nèi)存中尚未被發(fā)送至MQ的消息都會(huì)丟失。
②所以正確的異步發(fā)送方法是需要接收回調(diào)的。同步發(fā)送和異步發(fā)送的區(qū)別就在此，同步發(fā)送等send不阻塞了就表示一定發(fā)送成功了，異步發(fā)送需要客戶端回執(zhí)并由客戶端再判斷一次是否發(fā)送成功。
延遲投遞和定時(shí)投遞簡(jiǎn)介：
- 四大屬性：
| AMQ_SCHEDULED_DELAY | long | 延遲投遞的時(shí)間 |
| AMQ_SCHEDULED_PERIOD | long | 重復(fù)投遞的時(shí)間間隔 |
| AMQ_SCHEDULED_REPEAT | int | 重復(fù)投遞次數(shù) |
| AMQ_SCHEDULED_CRON | string | Cron表達(dá)式 |
- 配置：要在activemq.xml中配置schedulerSupport屬性為true
- Java代碼里面封裝的輔助消息類型：ScheduledMessage
消息消費(fèi)的重試機(jī)制：
- 是什么？
①消費(fèi)者收到消息，之后出現(xiàn)異常了，沒(méi)有告訴broker確認(rèn)收到該消息，broker會(huì)嘗試再將該消息發(fā)送給消費(fèi)者。嘗試n次，如果消費(fèi)者還是沒(méi)有確認(rèn)收到該消息，那么該消息將被放到死信隊(duì)列重，之后broker不會(huì)再將該消息發(fā)送給消費(fèi)者。 - 具體哪些情況會(huì)引發(fā)消息重發(fā)？
①Client用了transactions且再session中調(diào)用了rollback
②Client用了transactions且再調(diào)用commit之前關(guān)閉或者沒(méi)有commit
③Client再CLIENT_ACKNOWLEDGE的傳遞模式下，session中調(diào)用了recover - 請(qǐng)說(shuō)說(shuō)消息重發(fā)時(shí)間間隔和重發(fā)次數(shù)？
①間隔：1
②次數(shù)：6 - 有毒消息Poison ACK：
①一個(gè)消息被redelivedred超過(guò)默認(rèn)的最大重發(fā)次數(shù)（默認(rèn)6次）時(shí)，消費(fèi)的回個(gè)MQ發(fā)一個(gè)“poison ack”表示這個(gè)消息有毒，告訴broker不要再發(fā)了。這個(gè)時(shí)候broker會(huì)把這個(gè)消息放到DLQ（私信隊(duì)列）。 - 屬性說(shuō)明：
- 修改配置參數(shù)：
- 整合spring：
死信隊(duì)列：
- 簡(jiǎn)介：
①異常消息規(guī)避處理的集合，主要處理失敗的消息。
②ActiveMQ中引入了“死倍隊(duì)列”(Dead Letter Queue〉的概念。即一條消息再被重發(fā)了多次后（默認(rèn)為重發(fā)6次redeliveryCounter==6)，將會(huì)被ActiveMQ移入“死信隊(duì)列”。開(kāi)發(fā)人員可以在這個(gè)Queue中查看處理出錯(cuò)的消息，進(jìn)行人工干預(yù)。 - 死信隊(duì)列控制臺(tái)：
- 使用：
- 死信隊(duì)列的配置（一般采用默認(rèn)）：
①sharedDeadLetterStrategy：
<1>不管是queue還是topic，失敗的消息都放到這個(gè)隊(duì)列中。下面修改activemq.xml的配置，可以達(dá)到修改隊(duì)列的名字。
<2>將所有的eadLetter保存在一個(gè)共享的隊(duì)列中，這是ActiveMQ broker端默認(rèn)的策略。共享隊(duì)列默認(rèn)為“ActiveMQ.DLQ”，可以通過(guò)“deadLetterQueue”屬性來(lái)設(shè)定。
②individualDeadLetterStrategy：
<1>可以為queue和topic單獨(dú)指定兩個(gè)死信隊(duì)列。還可以為某個(gè)話題，單獨(dú)指定一個(gè)死信隊(duì)列。
③自動(dòng)刪除過(guò)期消息：
<1>過(guò)期消息是值生產(chǎn)者指定的過(guò)期時(shí)間，超過(guò)這個(gè)時(shí)間的消息。
<2>有時(shí)需要直接刪除過(guò)期的消息而不需要發(fā)送到死隊(duì)列中，“processExpired”表示是否將過(guò)期消息放入死信隊(duì)列，默認(rèn)為true。
④存放非持久消息到死信隊(duì)列中：
<1>默認(rèn)情況下，Activemq不會(huì)把非持久的死消息發(fā)送到死信隊(duì)列中。
<2>processNonPersistent”表示是否將“非持久化”消息放入死信隊(duì)列，默認(rèn)為false。
<3>非持久性如果你想把非持久的消息發(fā)送到死隊(duì)列中，需要設(shè)置屬性processNonPersistent=“true"
消息不被重復(fù)消費(fèi)，冪等性：
- 網(wǎng)絡(luò)延遲傳輸中，會(huì)造成進(jìn)行MQ重試中，在重試過(guò)程中，可能會(huì)造成重復(fù)消費(fèi)。
- 如果消息是做數(shù)據(jù)庫(kù)的插入操作，給這個(gè)消息做一個(gè)唯一主鍵，那么就算出現(xiàn)重復(fù)消費(fèi)的情況，就會(huì)導(dǎo)致主鍵沖突，避免數(shù)據(jù)庫(kù)出現(xiàn)臟數(shù)據(jù)。
- 如果上面兩種情況還不行，準(zhǔn)備一個(gè)第三服務(wù)方來(lái)做消費(fèi)記錄。以redis為例，給消息分配一個(gè)全局id，只要消費(fèi)過(guò)該消息，將<id,message>以K-V形式寫入redis。那消費(fèi)者開(kāi)始消費(fèi)前，先去redis中查詢有沒(méi)消費(fèi)記錄即可。
- 冪等性如何解決，根據(jù)messageid去查這個(gè)消息是否被消費(fèi)了。
總結(jié)
以上是生活随笔為你收集整理的ActiveMQ知识概括的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： OJ题——狐狸算卦
- 下一篇： 20181013优秀的软件推荐专栏（每日