RabbitMQ高級特性之-優先級隊列（Priority Queue）

背景

RabbitMQ 自 V3.5.0 有優先級隊列實現。使用客戶端提供的可選參數可將任何隊列轉換為優先級（但與使用可選參數而不是策略的其他功能不同）。其實現支持有限數量的優先事項：255。但推薦值介于： 1 ~ 10。

使用客戶端提供的可選參數

要聲明優先級隊列，使用 x-max-priority 參數。此參數應為介于 1 和 255 之間的正整數，指示隊列應支持的最大優先級。例如

Channel ch = ...; Map args = new HashMap(); args.put("x-max-priority", 10); ch.queueDeclare("my-priority-queue", true, false, false, args);

1

2

3

4

然后，發布者可以使用basic.properties的priority字段發布優先級消息。數字越大，優先級越高。

設計不支持使用策略的優先級聲明。

行為

AMQP 0-9-1 規范對于優先級預期如何工作有點模糊。它說，所有隊列必須支持至少 2 個優先級，并且可能最多支持 10 個優先級。但它沒定義如何處理沒有優先級屬性的消息。

與 AMQP 0-9-1 規范不同，RabbitMQ 隊列默認情況下不支持優先級。創建優先級隊列時，開發人員可以選擇認為合適的最大優先級。在選擇值時，必須斟酌。

每個隊列的優先級存在一些內存中和磁盤上的成本，還有額外的 CPU 成本，尤其是在使用時，因此可能不希望創建大量級別。

消息優先級字段定義為未簽名的字節，因此實際上優先級應在 0 和 255 之間。

沒有priority屬性的消息其優先級被視為 0。優先級高于隊列最大值的消息將被視為以最大優先級發布。

優先級和資源使用的最大數量

如果需要優先級隊列，推薦1 ~ 10。當前使用更多優先級將消耗更多的 CPU 資源，通過使用更多的 Erlang 進程。運行時調度也會受到影響。

與消費者的交互

了解使用者使用優先級隊列時的工作方式非常重要。默認情況下，消費者在確認任何消息之前可能會收到大量消息，但僅受網絡背壓限制。

因此，如果這種饑餓的使用者連接到一個空隊列，然后將消息發布到該隊列中，則消息可能不會花費任何時間在隊列中等待。在這種情況下，優先級隊列將沒有機會優先處理它們。

在大多數情況下，您需要在使用者的手動確認模式下使用 basic.qos 方法，以限制隨時可以發送的消息數，從而允許對郵件進行優先級排序。

與其他功能的協作避坑

通常，優先級隊列具有標準RabbitMQ隊列的所有功能：支持持久性，分頁，鏡像等。開發人員應該注意幾個交互。

應該過期的消息仍然只會從隊列的開頭過期。這意味著與普通隊列不同，即使每個隊列TTL也會導致過期的低優先級消息滯留在未過期的高優先級消息之后。這些消息將永遠不會傳遞，但是將出現在隊列統計信息中。

設置了最大長度的隊列將照常從隊列的開頭丟棄消息以強制執行該限制。這意味著較高優先級的消息可能會被丟棄，以取代較低優先級的消息，這可能不是所期望的。

為什么不支持策略定義

為隊列定義可選參數的最方便方法是通過策略。建議使用策略配置TTL，隊列長度限制和其他可選隊列參數。

但是，策略不能用于配置優先級，因為策略是動態的，可以在聲明隊列后進行更改。優先級隊列在聲明隊列后永遠無法更改其支持的優先級數量，因此使用策略不是一個安全的選擇。

參考

https://www.rabbitmq.com/priority.html

https://www.rabbitmq.com/queues.html#optional-arguments

RabbitMQ

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。