選擇容器

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

SMLC 具備但 DMLC 不具備以下功能：

batchSize: 使用 SMLC，您可以設定此值以控制在事務中交付的訊息數量或減少確認數量，但這可能會導致失敗後重復交付的數量增加。（DMLC 確實有 messagesPerAck，您可以像使用 SMLC 的 batchSize 一樣使用它來減少確認，但它不能與事務一起使用——每條訊息都在單獨的事務中交付並確認）。
consumerBatchEnabled：啟用消費者中離散訊息的批處理；有關更多資訊，請參閱訊息監聽器容器配置。
maxConcurrentConsumers 和消費者伸縮間隔或觸發器——DMLC 中沒有自動伸縮。但是，它允許您以程式設計方式更改 consumersPerQueue 屬性，並相應地調整消費者。

然而，DMLC 相對於 SMLC 具有以下優點：

在執行時新增和刪除佇列效率更高。使用 SMLC，整個消費者執行緒都會重新啟動（所有消費者都會被取消並重新建立）。使用 DMLC，未受影響的消費者不會被取消。
避免了 RabbitMQ 客戶端執行緒和消費者執行緒之間的上下文切換。
執行緒在消費者之間共享，而不是像 SMLC 中那樣為每個消費者分配一個專用執行緒。但是，請參閱執行緒和非同步消費者中關於連線工廠配置的重要注意事項。

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