RabbitMQ消息属性详解

content-type属性

如同各种标准化的HTTP规范，content-type传输消息体的MIME类型。例如，如果你的应用程序正在发送JSON序列化的数据值，那么将content-type属性设置为application/json将允许尚待开发的消费者应用程序在收到消息时检查消息类型并对消息进行正确解码。

在 RabbitMQ 中，默认的 content-type 是 application/octet-stream。

application/octet-stream 是一个常见的 MIME 类型，它表示二进制数据流，也可以理解为未知的二进制文件类型。"octet" 指的是 8 位字节，表示该类型可以包含任意的二进制数据。由于它是一个通用的二进制数据流类型，它不会对数据进行解析或做出任何假设，而是将数据视为纯粹的字节序列。

application/octet-stream 类型的文件通常没有特定的格式或解析方式，因此接收者需要根据具体的需求和上下文来处理该文件。它可以用于传输任何类型的数据，例如图像、音频、视频、压缩文件等。

在 RabbitMQ 中，默认将消息的 content-type 设置为 application/octet-stream，因为 RabbitMQ 不对消息的内容进行解析或做任何假设，它仅负责将消息传递给消费者。消费者可以根据自己的需求和上下文来解析和处理接收到的消息数据。

content-encoding****属性

默认情况下，通过AMQP发送的消息并不会被压缩。在处理如XML这种过于繁杂的标记语言时，甚至在消息数量较大的场景下处理像JSON或YAML等较少使用标记的轻量级格式时，这都可能会是个问题。你的发布者可以在发布消息之前压缩消息，并在收到消息时进行解压缩，如同我们使用gzip在服务器上压缩网页然后在浏览器端实时解压缩这些网页之后再进行展示一样。

RabbitMQ 的content-type和content-encoding是如何结合使用的****？

在 RabbitMQ 中，content-type 和 content-encoding 是两个相关但独立的消息属性，用于描述消息的内容类型和内容编码方式。

content-type 属性指定了消息体的内容类型，例如 application/json、text/plain、image/jpeg 等。它告诉消费者如何解析和处理消息的内容。

content-encoding 属性指定了消息体的内容编码方式，例如 gzip、deflate、identity 等。它告诉消费者消息体是否经过了压缩或其他编码方式的处理。

这两个属性可以结合使用，以便消费者能够正确地解码和处理消息。以下是一些示例：

消费者在接收到消息时，首先会检查 content-type 属性来确定消息的内容类型。然后，根据 content-encoding 属性，消费者可以选择是否需要解码消息体。

如果 content-encoding 属性为 identity，则消息体未经过任何编码处理，消费者可以直接读取和处理消息体。

如果 content-encoding 属性指定了某种编码方式（例如 gzip），则消费者需要根据指定的编码方式对消息体进行解码，以获取原始的消息内容。

需要注意的是，content-type 和 content-encoding 是消息的属性，由生产者在发送消息时设置。消费者在接收到消息时，可以读取这些属性来正确处理消息的内容。

message-id和correlation-id

在AMQP规范中，message-id和correlation-id是“应用级别使用”的属性，并没有提供正式的行为定义。这意味着就规范而言，你可以利用它们实现任何目的。这两个字段允许多达255个字节的UTF-8编码数据，并以未压缩的方式存储在Basic.Properties数据结构中。

【Message-id】某些消息类型（如登录事件）并不需要与其关联的唯一标识，但我们很容易想象如销售订单或支持类请求等的消息需要具备这个唯一标识。当消息流经松耦合系统中的各个组件时，message-id属性使得消息能够在消息头中携带数据，该数据可以唯一地识别该消息。message-id 是消息的唯一标识符，由生产者在发送消息时设置。它用于唯一标识一条消息，并且在整个消息的生命周期中保持不变。message-id 属性可以用于跟踪消息、识别重复消息或在消息处理过程中进行日志记录。

【Correlation-id】虽然在AMQP规范中没有关于correlation-id的正式定义，但它的一个用途是指定该消息是另一个消息的响应，通过携带关联消息的message-id可以做到这一点。另一种选择是使用它来传送关联消息的事务ID或其他类似数据。correlation-id 是用于关联消息的属性，通常在消息请求和响应之间使用。当一个系统发送请求消息时，它可以设置 correlation-id 属性为一个唯一的值。然后，当该请求消息被处理并得到响应时，响应消息的 correlation-id 属性会与请求消息的 correlation-id 相匹配，以表明响应消息与哪个请求消息相关联。

通过使用 correlation-id 属性，可以轻松地将请求和响应进行匹配和关联。这在分布式系统或异步消息传递中特别有用，允许跟踪消息的处理和建立请求-响应模式。

需要注意的是，message-id 和 correlation-id 都是可选的消息属性，生产者可以选择是否设置它们。如果生产者没有显式设置这些属性，RabbitMQ 会为消息自动生成一个唯一的 message-id。

消费者在接收到消息时，可以读取 message-id 和 correlation-id 属性来处理消息，并根据需要进行跟踪、日志记录或关联请求和响应。

timestamp属性

RabbitMQ 中的消息可以包含一个名为 timestamp 的属性，用于表示消息的时间戳。timestamp 属性指示消息发送的时间，它是一个整数值，表示自1970年1月1日以来的毫秒数。

生产者在发送消息时可以设置 timestamp 属性，以指定消息的时间戳。这对于在消息中包含时间信息，或者与消息的时间相关的处理非常有用。

消费者在接收到消息时可以读取 timestamp 属性，以获取消息的时间戳。这允许消费者根据消息的时间戳进行处理，例如根据消息的发送时间进行排序、计算消息的延迟等。

需要注意的是，RabbitMQ 并不会自动为每条消息设置 timestamp 属性，它是可选的。如果生产者没有显式设置 timestamp 属性，则消息的 timestamp 默认为未设置状态。因此，消费者在处理消息时应该检查 timestamp 属性是否存在，以避免处理未设置时间戳的消息。

expiration属性

在 RabbitMQ 中，消息可以具有一个名为 expiration 的属性，用于指定消息的过期时间。expiration 属性是一个字符串，表示消息在队列中可以保留的时间。

当消息在队列中等待被消费时，RabbitMQ 会根据消息的 expiration 属性进行判断。如果消息在队列中的时间超过了指定的过期时间，RabbitMQ 将会自动将该消息从队列中移除，并发送给死信交换机（Dead Letter Exchange）进行进一步处理。

通过设置 expiration 属性，可以实现消息的自动过期和延迟处理。这对于处理具有时间敏感性的消息非常有用，例如在一定时间内未被消费的消息可以被认为是过期的，从而进行相应的处理。

需要注意的是，expiration 属性的值是以毫秒为单位的时间间隔，指示消息在队列中保留的时长。如果 expiration 属性设置为 0 或负数，则表示消息不会过期，会一直保留在队列中。

在 RabbitMQ 中，默认情况下，消息的 expiration 属性是未设置的（unset）。这意味着消息不会自动过期，除非你在发送消息时显式地设置了 expiration 属性。

如果你没有设置消息的 expiration 属性，消息将保留在队列中直到被消费或手动从队列中删除。

需要注意的是，RabbitMQ 中可以配置针对队列级别的消息过期策略，该策略可以在创建队列时指定。这将应用于所有发送到该队列的消息，除非单独设置了消息的 expiration 属性。如果设置了队列级别的消息过期策略，它将覆盖消息的个别 expiration 设置。但是，默认情况下，RabbitMQ 不会对消息应用任何过期策略，消息将保留在队列中直到被处理。

delivery-mode

delivery-mode属性是一个字节字段，向消息代理服务器表明在将消息投递给任何正在等待的消费者之前，是否希望先将它持久化到磁盘上。在RabbitMQ中，持久化消息意味着即使RabbitMQ服务器重新启动，消息也会保留在队列中直到被消费。delivery-mode属性有两个可能的值：1表示非持久化消息，2表示持久化消息。

需要注意的是，默认情况下，RabbitMQ 将消息视为非持久性消息，即 delivery-mode 属性为 1。这意味着，如果没有显式地设置消息的 delivery-mode 属性，消息将被标记为非持久性消息。

app-id和user-id

在 RabbitMQ 中，消息可以包含两个与身份相关的属性：app-id 和 user-id。

app-id 属性用于标识发送消息的应用程序的标识符。它可以是应用程序的名称、ID 或其他标识符。app-id 属性可以帮助消费者识别消息来自哪个应用程序，并根据需要进行处理或路由。

user-id 属性用于标识发送消息的用户的标识符。它可以是用户的名称、ID 或其他标识符。user-id 属性用于在多用户环境中跟踪消息的来源，并可能用于进行权限验证或其他身份验证操作。

这些属性通常由生产者在发送消息时设置，以提供有关消息来源和身份的信息。消费者在接收到消息时可以读取这些属性，以便根据需要进行相应的处理。

消费者在接收到消息时可以通过读取消息的 app-id 和 user-id 属性来识别消息的来源和用户，然后根据需要进行相应的处理。这对于应用程序的日志记录、审计跟踪、权限验证等场景非常有用。

headers消息头自定义属性

headers属性是一个键/值对表，允许用户自定义任意的键和值。键可以是ASCII或Unicode字符串，最大长度为255个字符。而值可以是任何有效的AMQP值类型。

与其他属性不同，headers属性允许你添加任何你想要添加的数据到消息头表中。它还具有另一个独特的功能：RabbitMQ可以根据headers表中填充的值路由消息，而不需要依赖于路由键。

priority优先级属性

在 RabbitMQ 中，消息可以具有一个名为 priority 的属性，用于指定消息的优先级。priority 属性是一个整数值，范围从 0 到 9，其中 0 表示最低优先级，9 表示最高优先级。

通过设置消息的 priority 属性，可以使具有较高优先级的消息在消息队列中被优先处理。RabbitMQ 使用优先级来决定消息的处理顺序。在相同的队列中，具有更高优先级的消息将优先于具有较低优先级的消息被消费。

需要注意的是，RabbitMQ 默认情况下是不支持消息优先级的，除非你在队列的定义中明确启用了消息优先级。在创建队列时，可以通过设置 x-max-priority 参数来启用队列的消息优先级支持。

消费者在接收消息时可以读取消息的 priority 属性，并根据消息的优先级进行相应的处理。具有更高优先级的消息将优先于具有较低优先级的消息被消费。