|
此版本仍在开发中,尚未被视为稳定版本。对于最新的稳定版本,请使用 Spring Integration 6.4.0! |
AMQP 消息标头
概述
Spring 集成 AMQP 适配器会自动映射所有 AMQP 属性和头文件。
(这是对 4.3 的更改 - 以前,仅映射标准标头)。
默认情况下,这些属性将复制到 Spring 集成中或从中复制MessageHeaders通过使用DefaultAmqpHeaderMapper.
你可以传入你自己的特定于 AMQP 的 Headers 映射器的实现,因为适配器具有支持这样做的属性。
AMQP 中的任何用户定义的标头MessageProperties复制到 AMQP 消息或从 AMQP 消息中复制,除非requestHeaderNames或replyHeaderNames的属性DefaultAmqpHeaderMapper.
默认情况下,对于出站映射器,没有x-*标头被映射。
请参阅本节后面出现的注意事项,了解原因。
要覆盖默认值并恢复到 4.3 之前的行为,请使用STANDARD_REQUEST_HEADERS和STANDARD_REPLY_HEADERS在 Properties 中。
映射用户定义的标头时,值还可以包含简单的通配符模式(例如thing*或*thing) 进行匹配。
匹配所有标头。* |
从版本 4.1 开始,AbstractHeaderMapper(一个DefaultAmqpHeaderMappersuperclass) 允许NON_STANDARD_HEADERStoken 的requestHeaderNames和replyHeaderNames属性(除了现有的STANDARD_REQUEST_HEADERS和STANDARD_REPLY_HEADERS) 映射所有用户定义的标头。
这org.springframework.amqp.support.AmqpHeadersclass 标识DefaultAmqpHeaderMapper:
-
amqp_appId -
amqp_clusterId -
amqp_contentEncoding -
amqp_contentLength -
content-type(参见这contentType页眉) -
amqp_correlationId -
amqp_delay -
amqp_deliveryMode -
amqp_deliveryTag -
amqp_expiration -
amqp_messageCount -
amqp_messageId -
amqp_receivedDelay -
amqp_receivedDeliveryMode -
amqp_receivedExchange -
amqp_receivedRoutingKey -
amqp_redelivered -
amqp_replyTo -
amqp_timestamp -
amqp_type -
amqp_userId -
amqp_publishConfirm -
amqp_publishConfirmNackCause -
amqp_returnReplyCode -
amqp_returnReplyText -
amqp_returnExchange -
amqp_returnRoutingKey -
amqp_channel -
amqp_consumerTag -
amqp_consumerQueue
如本节前面所述,使用 Headers 映射模式是复制所有 Headers 的常见方法。
但是,这可能会产生一些意想不到的副作用,因为某些 RabbitMQ 专有属性/标头也会被复制。
例如,当您使用联合身份验证时,收到的消息可能具有名为*x-received-from,其中包含发送消息的节点。
如果您在入站网关上对请求和回复标头映射使用通配符,则会复制此标头,这可能会导致联合身份验证出现一些问题。
此回复消息可能会联合回发送代理,发送代理可能会认为消息正在循环,因此会以静默方式删除该消息。
如果您希望使用通配符标头映射的便利性,则可能需要筛选掉下游流中的一些标头。
例如,为避免将*x-received-from标头返回到你可以使用的回复<int:header-filter … header-names="x-received-from">在将回复发送到 AMQP 入站网关之前。
或者,您可以显式列出实际要映射的那些属性,而不是使用通配符。
由于这些原因,对于入站邮件,映射器(默认情况下)不会映射任何x-*头。
它也不会映射deliveryMode到amqp_deliveryMode标头,以避免该标头从入站消息传播到出站消息。
相反,此标头映射到amqp_receivedDeliveryMode,该 URL 不会映射到输出上。 |
从版本 4.3 开始,可以通过在模式前面加上!.
否定模式获得优先级,因此STANDARD_REQUEST_HEADERS,thing1,ba*,!thing2,!thing3,qux,!thing1不映射thing1(或thing2也不thing3).
标准接头加上bad和qux映射。
否定技术可能很有用,例如,当 JSON 反序列化逻辑在接收方下游以不同的方式完成时,不为传入消息映射 JSON 类型的标头。
为此,一个!json_*pattern 应该为 inbound channel adapter/gateway 的 header mapper 配置。
如果您有一个以!,则需要使用 进行转义,如下所示:\STANDARD_REQUEST_HEADERS,\!myBangHeader.
名为!myBangHeader现在已映射。 |
从版本 5.1 开始,DefaultAmqpHeaderMapper将回退到映射MessageHeaders.ID和MessageHeaders.TIMESTAMP自MessageProperties.messageId和MessageProperties.timestamp分别,如果相应的amqp_messageId或amqp_timestamp出站邮件上不存在报头。
入站属性将映射到amqp_*标头。
填充messageId属性。 |
这contentType页眉
与其他标头不同,AmqpHeaders.CONTENT_TYPE未以amqp_;这允许跨不同技术透明地传递 contentType 标头。
例如,发送到 RabbitMQ 队列的入站 HTTP 消息。
这contentType标头映射到 Spring AMQP 的MessageProperties.contentType属性,该属性随后映射到 RabbitMQ 的content_type财产。
在 5.1 版本之前,此标头也映射为MessageProperties.headers地图;这是不正确的,此外,该值可能是错误的,因为底层 Spring AMQP 消息转换器可能已经更改了内容类型。
这样的变化将反映在一等舱content_type属性,但不在 RabbitMQ 标头映射中。
入站映射忽略了 headers 映射值。contentType不再映射到 Headers 映射中的条目。