AMQP 消息头
概述
Spring Integration AMQP 适配器会自动映射所有 AMQP 属性和头。（这与 4.3 版本不同——之前只映射标准头）。默认情况下，这些属性通过使用 DefaultAmqpHeaderMapper 在 Spring Integration MessageHeaders 之间进行复制。
您可以传入自己实现的 AMQP 特定头映射器，因为适配器具有支持这样做的属性。
AMQP MessageProperties 中的任何用户定义头都会复制到 AMQP 消息或从 AMQP 消息复制，除非 DefaultAmqpHeaderMapper 的 requestHeaderNames 或 replyHeaderNames 属性明确否定。默认情况下，对于出站映射器，不映射任何 x-* 头。请参阅本节后面出现的 注意事项。
要覆盖默认行为并恢复到 4.3 之前的行为，请在属性中使用 STANDARD_REQUEST_HEADERS 和 STANDARD_REPLY_HEADERS。
|
映射用户定义头时，值还可以包含简单的通配符模式（例如 |
从 4.1 版本开始，AbstractHeaderMapper（DefaultAmqpHeaderMapper 的超类）允许为 requestHeaderNames 和 replyHeaderNames 属性配置 NON_STANDARD_HEADERS 令牌（除了现有的 STANDARD_REQUEST_HEADERS 和 STANDARD_REPLY_HEADERS），以映射所有用户定义头。
org.springframework.amqp.support.AmqpHeaders 类标识了 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
如本节前面所述，使用 的头映射模式是复制所有头的常用方法。然而，这可能会产生一些意想不到的副作用，因为某些 RabbitMQ 专有属性/头也会被复制。例如，当您使用 联邦交换时，接收到的消息可能具有名为 x-received-from 的属性，其中包含发送消息的节点。如果您在入站网关上使用通配符 进行请求和回复头映射，则此头会被复制，这可能会导致联邦交换出现一些问题。此回复消息可能会被联邦交换回发送代理，发送代理可能会认为消息正在循环，因此会静默丢弃它。如果您希望使用通配符头映射的便利性，您可能需要在下游流中过滤掉一些头。例如，为了避免将 x-received-from 头复制回回复，您可以在将回复发送到 AMQP 入站网关之前使用 <int:header-filter … header-names="x-received-from">。或者，您可以明确列出您实际希望映射的属性，而不是使用通配符。出于这些原因，对于入站消息，映射器（默认情况下）不映射任何 x-* 头。它也不将 deliveryMode 映射到 amqp_deliveryMode 头，以避免该头从入站消息传播到出站消息。相反，此头映射到 amqp_receivedDeliveryMode，该头在输出时不进行映射。
从 4.3 版本开始，头映射中的模式可以通过在模式前加上 ! 来否定。被否定的模式具有优先级，因此像 STANDARD_REQUEST_HEADERS,thing1,ba*,!thing2,!thing3,qux,!thing1 这样的列表不会映射 thing1（也不会映射 thing2 或 thing3）。映射的是标准头加上 bad 和 qux。否定技术对于例如在接收器下游以不同方式完成 JSON 反序列化逻辑时，不映射传入消息的 JSON 类型头非常有用。为此，应为入站通道适配器/网关的头映射器配置 !json_* 模式。
如果您有一个以 ! 开头的用户定义头，并且您确实希望映射它，您需要使用 \ 进行转义，如下所示：STANDARD_REQUEST_HEADERS,\!myBangHeader。现在映射名为 !myBangHeader 的头。
|
从 5.1 版本开始，如果出站消息上不存在相应的 |
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 头映射中。入站映射会忽略头映射值。contentType 不再映射到头映射中的条目。