選擇容器

版本 2.0 引入了 DirectMessageListenerContainer (DMLC)。以前，只有 SimpleMessageListenerContainer (SMLC) 可用。SMLC 使用內部佇列和每個消費者專用的執行緒。如果容器配置為監聽多個佇列，則使用相同的消費者執行緒處理所有佇列。併發性由 concurrentConsumers 和其他屬性控制。當訊息從 RabbitMQ 客戶端到達時，客戶端執行緒透過佇列將其傳遞給消費者執行緒。需要這種架構是因為在早期版本的 RabbitMQ 客戶端中，無法實現多個併發投遞。較新版本的客戶端採用了改進的執行緒模型，現在可以支援併發。這使得引入了 DMLC，其中監聽器現在直接在 RabbitMQ 客戶端執行緒上被呼叫。因此，它的架構實際上比 SMLC 更“簡單”。然而，這種方法存在一些限制，SMLC 的某些特性在 DMLC 中不可用。此外，併發性由 consumersPerQueue 控制（以及客戶端庫的執行緒池）。此容器不可用 concurrentConsumers 和相關屬性。

以下特性在 SMLC 中可用，但在 DMLC 中不可用

  • batchSize：在 SMLC 中，您可以設定此值來控制在事務中投遞多少訊息或減少確認次數，但這可能導致在故障後重復投遞的數量增加。（DMLC 確實有 messagesPerAck，您可以使用它來減少確認次數，與 batchSize 和 SMLC 的效果相同，但它不能與事務一起使用——每條訊息在單獨的事務中投遞和確認）。

  • consumerBatchEnabled：啟用消費者中離散訊息的批次處理；更多資訊請參見訊息監聽器容器配置。

  • maxConcurrentConsumers 和消費者伸縮間隔或觸發器——DMLC 中沒有自動伸縮。但是，它允許您以程式設計方式更改 consumersPerQueue 屬性，並相應地調整消費者。

然而，DMLC 相比 SMLC 具有以下優勢

  • 在執行時新增和移除佇列更高效。使用 SMLC，整個消費者執行緒會重新啟動（所有消費者被取消並重新建立）。使用 DMLC，未受影響的消費者不會被取消。

  • 避免了 RabbitMQ 客戶端執行緒與消費者執行緒之間的上下文切換。

  • 執行緒在消費者之間共享，而不是像 SMLC 中那樣每個消費者都有專用執行緒。然而，請參閱關於 執行緒與非同步消費者 中連線工廠配置的重要說明。

有關適用於每個容器的配置屬性的資訊，請參見訊息監聽器容器配置。