activemq消息持久化

我被問了很多關(guān)于ActiveMQ如何存儲(chǔ)消息（或在某些情況下不存儲(chǔ)）的基本知識(shí)。 這是它的高級(jí)解釋。 注意，上下文在JMS中。 如果您使用ActiveMQ的非JMS客戶端（即STOMP，AMQP，MQTT等），則在某些情況下行為可能有所不同。

ActiveMQ

在不丟失標(biāo)記為“持久”的消息方面，JMS持久性保證非常強(qiáng)大。 讓我們看看它如何適用于ActiveMQ

主題

主題是一種廣播機(jī)制。 它們使我們能夠在JMS領(lǐng)域中實(shí)現(xiàn)發(fā)布-訂閱語(yǔ)義。 但是，如果我們將消息標(biāo)記為“持久”并且沒有訂閱者，會(huì)發(fā)生什么情況？ 在任何普通廣播中（例如，我去市區(qū)并開始大喊ActiveMQ的出色表現(xiàn)），如果沒有訂閱者（3a，周圍沒有人聽到我的聲音……）如果我不在，一定是一個(gè)美好的夜晚在3a）會(huì)發(fā)生什么？ 沒有。 沒有人聽到。 然后我們繼續(xù)前進(jìn)。 如果您發(fā)布消息（持久的或非持久的）并且沒有訂閱者（沒有活動(dòng)的訂閱者和持久的訂閱者），ActiveMQ對(duì)該消息不做任何事情。

ActiveMQ僅在有持久訂戶（活動(dòng)或不活動(dòng)）的情況下存儲(chǔ)消息。 對(duì)于非活動(dòng)的持久訂閱，ActiveMQ會(huì)將標(biāo)記為“持久”的消息存儲(chǔ)到非易失性存儲(chǔ)中，并等待訂閱者重新加入訂閱。 屆時(shí)它將嘗試傳遞消息。

Queue列

對(duì)于隊(duì)列，ActiveMQ使用簡(jiǎn)單的默認(rèn)協(xié)議來處理“持久”消息。 我們基本上阻塞了主要生產(chǎn)者線程，并等待確認(rèn)經(jīng)紀(jì)人實(shí)際上已收到消息：

制片人：

• 生產(chǎn)者發(fā)送消息
• 生產(chǎn)者阻止，等待來自代理的ACK
  • 如果成功的確認(rèn)，生產(chǎn)者繼續(xù)

經(jīng)紀(jì)人：

• 收到消息
• 將消息存儲(chǔ)到磁盤
• 發(fā)回ACK

對(duì)于“非持久”發(fā)送，流程是不同的。 我們以“即發(fā)即棄”模式發(fā)送郵件。 主生產(chǎn)者線程不會(huì)被阻塞，并且在ActiveMQ連接傳輸線程上異步發(fā)生任何ACK或其他響應(yīng)：

• 生產(chǎn)者發(fā)送消息
• 生產(chǎn)者繼續(xù)其線程，不會(huì)阻塞
• 生產(chǎn)者最終在與主生產(chǎn)者線程不同的單獨(dú)線程上獲得ACK
  • 如果失敗，則客戶端可以訂閱JMS ExceptionListener以獲得通知

交易發(fā)送？

我們可以通過分批一次發(fā)送多個(gè)消息來提高發(fā)送給代理的性能。 這樣可以更有效地利用網(wǎng)絡(luò)以及代理存儲(chǔ)。 發(fā)送交易時(shí)，您必須意識(shí)到一個(gè)重要的區(qū)別。 TX會(huì)話的打開和關(guān)閉（回滾/提交）都是與代理的同步交互， 但是 ，TX窗口中每個(gè)消息的發(fā)送都是異步發(fā)送的。 如果一切順利，這是可以的，因?yàn)榇韺⑦@些消息分批處理。 但是，如果出現(xiàn)運(yùn)輸錯(cuò)誤怎么辦？ 還是代理用完了空間來保存這些消息？

我們需要設(shè)置一個(gè)ExceptionListener來監(jiān)視這些發(fā)送期間的錯(cuò)誤。 我們還需要（或應(yīng)該）設(shè)置一個(gè)客戶端發(fā)送“生產(chǎn)者窗口”，以允許我們?cè)诖砗谋M資源時(shí)強(qiáng)制執(zhí)行生產(chǎn)者流控制。 有關(guān)更多信息，請(qǐng)參見ActiveMQ生產(chǎn)者流控制 。

更改默認(rèn)值

生產(chǎn)者上有趣的設(shè)置，可以更改以下行為：

• useAsyncSend –始終異步等待ACK，即使在持久發(fā)送和提交中也是如此
• alwaysSyncSend –強(qiáng)制所有發(fā)送（包括非持久性或事務(wù)性發(fā)送）始終等待來自代理的ACK

人們通常想要使用默認(rèn)值。

存儲(chǔ)

對(duì)于ActiveMQ的生產(chǎn)用途，我目前建議使用共享存儲(chǔ)方法 。 在這種情況下，我們需要知道存儲(chǔ)層發(fā)生了什么，以了解ActiveMQ的保證。

默認(rèn)情況下，ActiveMQ將實(shí)現(xiàn)JMS持久性要求，該要求基本上規(guī)定了所存儲(chǔ)的消息必須在崩潰后幸免。 為此，默認(rèn)情況下，我們將在文件系統(tǒng)上執(zhí)行“ fsync”。 現(xiàn)在，每個(gè)系統(tǒng)上發(fā)生的情況將取決于您使用的操作系統(tǒng)，網(wǎng)絡(luò)，存儲(chǔ)控制器，存儲(chǔ)設(shè)備等。 對(duì)于需要持久存儲(chǔ)消息并且不是特定于ActiveMQ的任何類型的數(shù)據(jù)庫(kù)，這都是您期望的。

當(dāng)我們寫入ActiveMQ事務(wù)日志時(shí)，我們需要讓OperatingSystem通過調(diào)用fsync將日志刷新到磁盤。 基本上發(fā)生的是，我們迫使操作系統(tǒng)回寫用于將文件更改緩存到存儲(chǔ)介質(zhì)的頁(yè)面文件緩存。 它還鼓勵(lì)存儲(chǔ)介質(zhì)執(zhí)行將數(shù)據(jù)“存儲(chǔ)”到磁盤所需的操作（取決于實(shí)現(xiàn)）：

一些存儲(chǔ)控制器具有自己的緩存，需要刷新。 磁盤驅(qū)動(dòng)器具有自己的緩存，等等。其中一些緩存由電池支持，并且可能以自己的時(shí)間間隔寫回，等等。為了使您了解通過ActiveMQ運(yùn)行的消息的持久性，您應(yīng)該了解您的存儲(chǔ)層。

消費(fèi)者

最后，難題的最后一部分是我們?nèi)绾蜗蛳M(fèi)者傳遞/分發(fā)消息以及他們?nèi)绾未_認(rèn)。 ActiveMQ JMS庫(kù)為您處理了所有這些，因此您不必?fù)?dān)心是否會(huì)丟失消息。

消息將被分發(fā)給消費(fèi)者，直到達(dá)到駐留在消費(fèi)者身上的某個(gè)“預(yù)取”緩沖區(qū)為止。 這可以通過使使用者上的可用消息緩存準(zhǔn)備好進(jìn)行處理，然后在使用者使用它們時(shí)重新填充此緩存來幫助加速消息處理。 在ActiveMQ中，這些預(yù)取的消息在控制臺(tái)中表示為“運(yùn)行中”。 這一點(diǎn)取決于消費(fèi)者來處理這些消息并對(duì)其進(jìn)行確認(rèn)。 （這將取決于確認(rèn)模式。默認(rèn)的自動(dòng)確認(rèn)將在使用者獲取消息時(shí)發(fā)送ACK。對(duì)于更重要的消息處理，您可能希望使用“客戶端”確認(rèn)，其中客戶端明確說明何時(shí)確認(rèn)消息，即完成一些處理后）。

如果使用者由于某種原因失敗，則任何未確認(rèn)的消息將重新發(fā)送到另一個(gè)使用者（如果有），并按照上述相同的處理過程進(jìn)行。 代理在收到ACK之前不會(huì)從其索引中刪除該消息。 因此，這包括使用者級(jí)別和網(wǎng)絡(luò)級(jí)別的故障。 如果即使在消費(fèi)者被“成功處理”之后，這兩個(gè)級(jí)別中的任何一個(gè)都存在錯(cuò)誤（請(qǐng)注意，這是非常用例的具體含義，“成功處理”的含義），并且經(jīng)紀(jì)人沒有收到確認(rèn)，那么經(jīng)紀(jì)人很有可能將重新發(fā)送消息。 在這種情況下，您最終可能會(huì)在使用者方面產(chǎn)生重復(fù)，并且可能會(huì)希望實(shí)現(xiàn)一個(gè)冪等的使用者。 為了擴(kuò)大消息傳遞的生產(chǎn)者/消費(fèi)者，無論如何，您都需要有冪等的消費(fèi)者。

最后要注意的一點(diǎn)：不使用XA事務(wù)，JMS不會(huì)一次保證消息，也只能一次處理消息。 JMS在一次就可以保證一次傳遞的范圍內(nèi)，可以將消息標(biāo)記為“已重新傳遞”，并讓消費(fèi)者檢查該消息，但是消費(fèi)者應(yīng)負(fù)責(zé)處理多少次（或與冪等消費(fèi)者過濾掉）。

翻譯自: https://www.javacodegeeks.com/2016/05/message-durability-activemq-5-x.html

activemq消息持久化

總結(jié)

以上是生活随笔為你收集整理的activemq消息持久化_ActiveMQ 5.x中的消息持久性的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。