跳到主要内容
版本：7.0.2

异步出站网关

DeepSeek V3 中英对照 Asynchronous Outbound Gateway

上一节讨论的网关是同步的，即发送线程会挂起直到收到回复（或发生超时）。Spring Integration 4.3 版本新增了异步网关，它使用了 Spring AMQP 中的 AsyncRabbitTemplate。当消息发送时，线程在发送操作完成后立即返回；当消息被接收时，回复会在模板的监听器容器线程上发送。这在网关由轮询器线程调用时非常有用，因为线程会被释放，可供框架中的其他任务使用。

以下列表展示了 AMQP 异步出站网关的可用配置选项：

@Configuration
public class AmqpAsyncApplication {

    @Bean
    public IntegrationFlow asyncAmqpOutbound(AsyncRabbitTemplate asyncRabbitTemplate) {
        return f -> f
                .handle(Amqp.asyncOutboundGateway(asyncRabbitTemplate)
                        .routingKey("queue1")); // default exchange - route to queue 'queue1'
    }

    @MessagingGateway(defaultRequestChannel = "asyncAmqpOutbound.input")
    public interface MyGateway {

        String sendToRabbit(String data);

    }

}

  • 此适配器的唯一 ID。可选。

  • 消息应发送到的消息通道，以便进行转换并发布到 AMQP 交换机。必需。

  • 对已配置的 AsyncRabbitTemplate 的 Bean 引用。可选（默认为 asyncRabbitTemplate）。

  • 消息应发送到的 AMQP 交换机的名称。如果未提供，消息将发送到默认的无名交换机。与 exchange-name-expression 互斥。可选。

  • 一个 SpEL 表达式，用于评估确定消息发送到的 AMQP 交换机名称，以消息作为根对象。如果未提供，消息将发送到默认的无名交换机。与 exchange-name 互斥。可选。

  • 当注册了多个消费者时，此消费者的顺序，从而实现负载均衡和故障转移。可选（默认为 Ordered.LOWEST_PRECEDENCE [=Integer.MAX_VALUE]）。

  • 从 AMQP 队列接收并转换后，回复消息应发送到的消息通道。可选。

  • 网关将回复消息发送到 reply-channel 时的等待时间。这仅适用于 reply-channel 可能阻塞的情况——例如，容量限制已满的 QueueChannel。默认值为无限。

  • 当在 AsyncRabbitTemplate 的 receiveTimeout 属性规定的时间内未收到回复消息且此设置为 true 时，网关会向入站消息的 errorChannel 标头发送错误消息。当在 AsyncRabbitTemplate 的 receiveTimeout 属性规定的时间内未收到回复消息且此设置为 false 时，网关会向默认的 errorChannel（如果可用）发送错误消息。默认为 true。

  • 发送消息时使用的路由键。默认情况下，这是一个空的 String。与 routing-key-expression 互斥。可选。

  • 一个 SpEL 表达式，用于评估确定发送消息时使用的路由键，以消息作为根对象（例如，payload.key）。默认情况下，这是一个空的 String。与 routing-key 互斥。可选。

  • 消息的默认传递模式：PERSISTENT 或 NON_PERSISTENT。如果 header-mapper 设置了传递模式，则会被覆盖。如果存在 Spring Integration 消息头（amqp_deliveryMode），DefaultHeaderMapper 会设置该值。如果未提供此属性且标头映射器也未设置，则默认值取决于 RabbitTemplate 使用的底层 Spring AMQP MessagePropertiesConverter。如果未自定义，则默认为 PERSISTENT。可选。

  • 定义关联数据的表达式。提供此表达式时，将配置底层 AMQP 模板以接收发布者确认。需要专用的 RabbitTemplate 和 CachingConnectionFactory，且其 publisherConfirms 属性设置为 true。当收到发布者确认并提供关联数据时，根据确认类型，确认信息将被写入 confirm-ack-channel 或 confirm-nack-channel。确认信息的有效负载是由此表达式定义的关联数据，并且消息的 amqp_publishConfirm 标头设置为 true（ack）或 false（nack）。对于 nack 实例，会提供一个额外的标头（amqp_publishConfirmNackCause）。示例：headers['myCorrelationData']，payload。如果表达式解析为 Message<?> 实例（例如 "#this"），则在 ack/nack 通道上发出的消息将基于该消息，并添加额外的标头。另请参阅 发布者确认和返回的替代机制。可选。

  • 发送肯定（ack）发布者确认的通道。有效负载是由 confirm-correlation-expression 定义的关联数据。要求底层的 AsyncRabbitTemplate 将其 enableConfirms 属性设置为 true。另请参阅 发布者确认和返回的替代机制。可选（默认为 nullChannel）。

  • 自版本 4.2 起。发送否定（nack）发布者确认的通道。有效负载是由 confirm-correlation-expression 定义的关联数据。要求底层的 AsyncRabbitTemplate 将其 enableConfirms 属性设置为 true。另请参阅 发布者确认和返回的替代机制。可选（默认为 nullChannel）。

  • 设置此值后，如果在此时间（毫秒）内未收到发布者确认，网关将合成一个否定确认（nack）。待处理的确认会每隔此值的 50% 检查一次，因此实际发送 nack 的时间将在此值的 1 倍到 1.5 倍之间。另请参阅 发布者确认和返回的替代机制。默认无（不会生成 nack）。

  • 返回消息发送到的通道。提供此通道时，将配置底层 AMQP 模板以将无法投递的消息返回给网关。消息是根据从 AMQP 接收的数据构建的，并带有以下附加标头：amqp_returnReplyCode、amqp_returnReplyText、amqp_returnExchange 和 amqp_returnRoutingKey。要求底层的 AsyncRabbitTemplate 将其 mandatory 属性设置为 true。另请参阅 发布者确认和返回的替代机制。可选。

  • 当设置为 false 时，端点会在应用程序上下文初始化期间尝试连接到代理。这样做允许通过记录错误消息（如果代理宕机）来“快速失败”检测错误配置。当为 true（默认值）时，连接在发送第一条消息时建立（如果尚未因其他组件建立连接）。

另请参阅异步服务激活器获取更多信息。

important

RabbitTemplate

当您使用确认和返回机制时，我们建议注入到 AsyncRabbitTemplate 中的 RabbitTemplate 是专用的。否则，可能会遇到意外的副作用。