SpringCloud RabbitMQ Binder概述

以下简化图显示了RabbitMQ绑定程序的工作方式：

图41.1。RabbitMQ Binder

默认情况下，RabbitMQ Binder实现将每个目的地映射到TopicExchange。对于每个消费者组，Queue绑定到该TopicExchange。每个使用者实例为其组的Queue有一个对应的RabbitMQ Consumer实例。对于分区的生产者和使用者，队列带有分区索引后缀，并将分区索引用作路由键。对于匿名使用者（没有group属性的使用者），将使用自动删除队列（具有随机唯一名称）。

通过使用可选的autoBindDlq选项，您可以配置活页夹以创建和配置死信队列（DLQ）（以及死信交换机DLX，以及路由基础结构）。默认情况下，死信队列具有目标名称，后跟.dlq。如果启用了重试（maxAttempts > 1），则在重试用尽后，失败的消息将传递到DLQ。如果禁用了重试（maxAttempts = 1），则应将requeueRejected设置为false（默认值），以便将失败的消息路由到DLQ，而不是重新排队。此外，republishToDlq使绑定程序将失败的消息发布到DLQ（而不是拒绝它）。通过此功能，可以将其他信息（例如x-exception-stacktrace标头中的堆栈跟踪）添加到标头中的消息中。此选项不需要启用重试。您只需尝试一次即可重新发布失败的消息。从1.2版开始，您可以配置重新发布邮件的传递模式。请参阅republishDeliveryMode属性。

将requeueRejected设置为true（与republishToDlq=false一起使用）会导致消息被重新排队并连续重新发送，除非失败的原因是短暂的，否则这可能不是您想要的。通常，应通过将maxAttempts设置为大于1或将republishToDlq设置为true在活页夹中启用重试。

有关这些属性的更多信息，请参见“ RabbitMQ Binder Properties”。

该框架没有提供任何标准机制来使用死信消息（或将其重新路由回主队列）。“ Dead-Letter队列处理”中介绍了一些选项。

 在Spring Cloud Stream应用程序中使用多个RabbitMQ活页夹时，重要的是禁用'RabbitAutoConfiguration'以避免将来自RabbitAutoConfiguration的相同配置应用于两个活页夹。您可以使用@SpringBootApplication批注来排除该类。

从版本2.0开始，RabbitMessageChannelBinder将RabbitTemplate.userPublisherConnection属性设置为true，以便非事务生成器避免对使用者的死锁，如果由于代理上的内存警报而阻止了缓存的连接，则可能发生死锁。

 当前，multiplex使用者（一个使用者正在监听多个队列）仅受消息驱动的使用者支持；被轮询的使用者只能从单个队列中检索消息。