關于ActiveMQ的消息優先級支持 ， 郵件列表上通常會不斷出現一些問題，以及有關觀察到的行為和“真正支持什么”的好問題？ 我希望可以幫助您了解幕后情況以及可以支持的優先級。 詳細信息可能會有些麻煩。 如果您對這些細節不感興趣，請查看ActiveMQ Wiki ，以獲取高級概述。

首先，由于ActiveMQ支持JMS 1.1，所以讓我們看一下JMS規范對支持“ JMSPriority”的看法：

JMS定義了一個十級優先級值，最低優先級為0，最高優先級為9。 此外，客戶應將優先級0-4視為正常優先級，將優先級5-9視為快速優先級。 JMS不需要提供者嚴格執行消息的優先級排序； 但是，它應該盡力在普通郵件之前傳遞快速郵件。

ActiveMQ觀察到三個不同級別的“優先級”：

• 默認（JMSPriority == 4）
• 高（JMSPriority> 4 && <= 9）
• 低（JMSPriority> 0 && <4）

如果您沒有為MessageProducer或單個消息指定優先級（請參閱MessageProducer＃send（message，deliveryMode，優先級，timeToLive） ），則ActiveMQ的客戶端將默認使用JMSPriority ==4。作為JMS使用者，您可以期望如果生產者未使用優先級或目標上未使用其他形式的選擇標準，則按FIFO順序進行。

規范指出，ActiveMQ還“盡其所能”在“正?！毕⒅皞鬟f加速消息。 代理使用的消息存儲對完成操作有很大的幫助，但是通常，您可以期望代理僅接受JDBC支持的消息存儲的嚴格（0-9）優先級支持。 對于支持KahaDB的消息存儲庫，僅支持“類別優先級”（“低”，“默認”，“高”，其中每個類別中的優先級并非總是有區別的，即5和9被視為“高”）。 但是，使用正確的設置和消息傳遞配置文件，即使使用KahaDB，您也可以影響[嚴格]優先級的排序方式，因此讓我們快速看一下。

啟用郵件優先級

您可以使用activemq.xml配置文件中的以下設置在隊列上啟用消息優先級：

<destinationPolicy><policyMap><policyEntries><policyEntry queue='queueName' prioritizeMessages='true' /></policyEntries></policyMap> </destinationPolicy>

對于queueName ，具有通配符支持，因此您可以在消息層次結構上啟用優先級支持。

啟用優先級支持后，代理將在其消息游標中使用優先級鏈表結構，并向KahaDB提示在將消息存儲到磁盤時使用優先級類別。 優先級排序的嚴格程度有不同的級別，但是在最壞的情況下，您可以假定優先級將按類別維護。 以下因素起作用，這些因素控制使用KahaDB存儲時優先級排序的嚴格程度：

• 在隊列游標中啟用/禁用緩存
• MaxPageInSize，用于從一批存儲中分頁多少條消息
• 消費者預取
• 過期消息檢查
• 代理內存設置
• 持久/非持久消息

下一節將詳細介紹KahaDB中為支持優先級而發生的事情，而下一節將探討代理內存中的情況，并最終將其分發給消費者，并指出與上述不同的因素發揮作用。

KahaDB優先級分類

首先，我們將從如何將消息存儲在磁盤上以及如何加載到目標位置開始。 KahaDB（默認消息存儲）是基于文件的消息數據庫，代理使用該數據庫將消息持久存儲在“日志”或“日志”中。 代理還通過保持一個單獨的“索引”來跟蹤日志中包含哪些消息，該“索引”保存有關消息的信息（例如其在日志中的位置，與之關聯的目的地，訂購等）。 索引還具有消息“優先級”的概念，該概念由三個B + Tree結構實現，每個優先級級別一個（請參見org.apache.activemq.store.kahadb.MessageDatabase中的MessageOrderIndex）。 此實現細節是消息優先級的基礎，并且在從存儲中刪除消息時，對其余的代理有影響。

從商店中檢索消息時，將成批完成（maxPageInSize），并且首先檢索“ highPriority” BTree中的消息。 當高優先級消息耗盡時，存儲將隨后提供默認優先級，并隨后提供低優先級消息。

您可以像這樣設置maxPageInSize：

<policyEntry queue='queueName' prioritizeMessages='true'maxPageSize='500'>

頁面大小越大，批處理中的消息數量就越大，每次“快照”一次可以看到的消息越多。 對于進入內存的每個批次，將嚴格按照商店游標的說明來優先考慮其消息的優先級。 缺點是，如果您的消息量很大，一次輸入500條消息可能會耗盡代理內存。 默認設置為200。

消息光標優先級列表

當持久性消息從生產者進入代理時，它們將存儲在磁盤上，但也將被緩存在內存中，等待分發給消費者。 這是默認設置，因此無需顯式設置。 其背后的想法是能夠調度到快速使用方，而不必直接從磁盤檢索它（如果使用方變慢，則代理將自動調整自身，以使其在填充后不使用緩存，從而避免OOM）。 這樣做的好處是，當對隊列使用優先級支持時，用于游標的內部列表將支持嚴格的優先級（0-9），因此對于當前在內存（在緩存中）的所有消息，它們將按照從高到低的順序正確排序。 訣竅在于，當緩存中的所有消息都是“低優先級消息”，然后高優先級消息進入代理但由于緩存已滿而無法容納在緩存中時，該消息將消失直接在商店中進行索引，并在“高優先級”索引中進行索引，但是在下一批優先級消息被分頁到內存中之前，將無法在低優先級消息之前進行分發。

當NON持久消息進入代理時，它們將不會進入消息存儲。 它們將盡可能長時間地保留在內存中，并且僅在內存超過定義的閾值（默認情況下> 70％）時才會推送到磁盤（在臨時存儲中）。 因此，上面的緩存消息的相同行為適用于非持久消息，即內存中的消息將嚴格排序（0-9），但是一旦將它們推送到磁盤，則只會觀察到類別。

如果禁用游標的緩存（具有以下設置）

<policyEntry queue='queueName' prioritizeMessages='true'useCache='false' />

那么您可以幫助消除上述情況，即當高優先級消息進入時，高速緩存將充滿低優先級消息（由于無法分頁到內存而卡在磁盤上）。 但是，這樣做會降低吞吐量，因為必須先將磁盤中的消息分頁到發送給使用者之前，這會減慢調度速度。 但是請注意，這樣做時，即使光標中具有優先級列表，您也更有可能看到不遵循“嚴格”優先級的消息。 但是，它們將正確遵循優先級類別（高，默認，低）。 綜上所述，如果禁用緩存，則與啟用緩存并填充優先級較低的消息相比，可以更快地發送優先級較高的消息。 但是，僅禁用高速緩存并不能使您獲得嚴格的優先權。

禁用緩存有助于將優先級較高的消息先于優先級較低的消息發送給使用者，但是要使其按預期工作（并且已經使我痛苦），則需要禁用異步message expiry check 。 此過期檢查每30秒將郵件分頁到內存中，無論它們是否準備好進行分派（默認情況下），并對其執行TTL檢查（生存時間），并丟棄那些應過期的郵件。 這種檢查有效地將消息帶入內存，并且將停滯正常的“頁面調度”，足以錯過更高優先級的消息。

<policyEntry queue='queueName' prioritizeMessages='true'useCache='false' expireMessagesPeriod='0' >

但是，關閉過期檢查將使過期消息在存儲區中保留的時間更長，因為唯一的過期檢查將在發送之前立即進行，因此請對此進行有根據的決定，以及所有需要修改的ActiveMQ設置。 但是要朝著嚴格的順序優先順序的方向發展，您需要禁用此功能。

最后，消費者的預取在實現“嚴格訂購”方面發揮了作用。 默認情況下，隊列使用者的預取設置為1000，這意味著將批量發送1000條消息。 這有助于加快消費者在使用消息時的速度，但是就優先級而言，從本質上講，它還像消息的緩存一樣（如上所述），可能會導致看不到“嚴格排序”。 如果您的預取中填充了較低優先級的消息，并且代理中出現了一條新的高優先級消息，那么您也不會看到它，直到下一條消息分發給消費者為止。 因此，預取越低，在優先級較低的消息之前看到較高優先級的消息的可能性就越大。 預取為1時，您將始終獲得商店游標知道的最高優先級消息。

<policyEntry queue='queueName' prioritizeMessages='true'useCache='false' expireMessagesPeriod='0' queuePrefetch='1' >

客戶端消息優先級

ActiveMQ還在消息客戶端中內置了優先級支持，并且默認情況下啟用了該功能。 這意味著，當將消息發送到您的使用者時（甚至在使用預取功能在您的使用者接收消息之前），它們將被緩存在使用者方，并且默認情況下具有優先級。 這與您是否在代理方使用優先級支持無關。 這可能會影響您在消費者上看到的訂購，因此請記住這一點。 要禁用它，請在代理URL上設置以下配置選項，例如tcp://0.0.0.0:61616?jms.messagePrioritySupported=false

但是如上所述，您需要將預取降低到1，以獲得獲得嚴格排序的最佳機會。

權衡

因此，最終可以通過KahaDB獲得嚴格排序的消息，但是要進行重大權衡，這并不適用于所有消息傳遞情況。 您想要優化的快速消息傳遞嗎？ 還是要放慢消息傳遞速度，以實現對優先級的嚴格排序。 每種情況都不同，應根據具體情況進行評估。 但是，一般而言，您可以依賴類別級別的優先級。

在大隊列中對消息進行重新排序并保持高性能是有問題的，大多數Message Queue供應商都做得不好。 ActiveMQ的優先級支持很強，但是正如ActiveMQ Wiki上討論的描述消息優先級的問題一樣，存在另一個很好的選擇，即：使用消息選擇器并以高優先級的消息最終被首先使用的方式平衡使用者。 這種方法往往會提供更多的靈活性和控制力，但這是另一篇文章。

參考： ActiveMQ消息優先級：克里斯汀·波斯塔（ Christian Posta）–軟件博客博客上的JCG合作伙伴克里斯蒂安·波斯塔（ Christian Posta）的工作方式 。

翻譯自: https://www.javacodegeeks.com/2013/04/activemq-message-priorities-how-it-works.html

總結

以上是生活随笔為你收集整理的ActiveMQ消息优先级：工作原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。