5、RabbitMQ的消息属性（读书笔记）

简介

当使用RabbitMQ发布消息时，消息又AMQP规范中的三个低层帧类型组成：

1. Basic.publish方法帧；
2. 内容头帧；
3. 消息体帧；

这三种帧类型按顺序一块儿工做，以便消息传递时无缺无损。

其中，内容头帧中的消息属性是一种预约义的值，这些值经过设置Basic.Properties数据结构进行指定：

• content-type属性：让消费者知道如何解释消息体；
• content-encoding属性：指示消息体使用某种特殊的方式进行压缩或编码；
• message-id和correlation-id属性：表示惟一消息标识和消息响应标识，用于在工做流程中实现消息跟踪；
• timestamp属性：表示消息建立时间；
• expiration属性：表示消息的过时时间；
• delivery-mode属性：将消息写入磁盘或内存队列；
• app-id和user-id属性：帮助追踪出现问题的消息发布者应用程序；
• type属性：表示发布者和消费者之间的契约；
• reply-to属性：实现响应消息的路由；
• headers属性：定义自由格式的属性和实现RabbitMQ路由；

不建议使用的属性有：priority和cluster-id属性。

content-type属性介绍

content-type属性用于描述消息体的数据格式，如同各类标准化的HTTP规范，content-type传输消息体也可使用MIME类型。例如，若是应用程序正在发送JSON序列化的数据值，那么能够将content-type设置为application/json。若是客户端支持自动序列化，能够在消费消息时，帮你进行序列化的工做。

content-encoding属性

默认状况下，经过AMQP发送的消息不会被压缩。但若是在消息数量较大的场景下，则可能会但愿对消息进行压缩。AMQP提供了content-encoding属性设置压缩编码：

不要混淆content-encoding和content-type。与HTTP规范同样，content-encoding用于指示content-type以外的某种编码级别。它是一个修饰字段，一般用于代表消息体的内容已经使用gzip或其余形式的压缩方式进行了压缩。

结合content-type属性后，content-encoding属性使消费者应用程序可以基于一种明确的契约与发布者进行交互。

message-id和correlation-id属性

在AMQP规范中，message-id和correlation-id是“应用级别使用”的属性，原则上，你能够利用它们实现任何目的。这两个字段容许255个字节的UTF-8编码数据，并以未压缩的方式存储在Basic.Properties数据结构中。

message-id属性能够存放消息的惟一标识。

correlation-id属性能够指定该消息是另外一个消息的响应（另外一个消息的标识）。

timestamp属性

经过使用timestamp属性来指示消息的建立时间，消费者能够用来评估消息投递过程的性能。

该属性没有时区上下文，所以建议在全部消息中使用UTC或其余统一的时区。

expiration属性

若是消息没有被消费，expiration属性会告诉RabbitMQ什么时候应该丢弃消息。它的格式是一个短字符串，容许255个字符。

想要利用expiration属性来实现RabbitMQ消息的自动过时，它必须包含一个UNIX纪元时间或整数时间戳，而后把它存储为字符串。若是把一个已经超时的消息发布到服务器，则该消息不会被路由到任何队列，而是被直接丢弃。

RabbitMQ还有一个可让消息过时的功能，在声明队列时，将一个x-message-ttl参数和队列定义在一块儿，这个值也是一个UNIX纪元时间戳，精度是毫秒，数据类型是整数值。

delivery-mode属性

delivery-mode多是不少人研发人员最感兴趣的一个属性，由于它关乎与RabbitMQ的性能。它表示在将消息投递给任何消费者以前，是否但愿先将它持久化到磁盘上，delivery-mode又2个值：1表示非持久化消息，2表示持久化消息。

不要把消息持久化和队列持久化（durable）混淆，队列持久化是告诉RabbitMQ队列的定义在重启RabbitMQ后是否仍然有效。只有设置了消息的delivery-mode才会告诉RabbitMQ消息是否应该被持久化。一个队列可能包含持久化和未持久化的消息。

前面说过delivery-mode属性关乎性能，是由于内存IO比磁盘IO要快，所以将delivery-mode设置为1将会尽量下降消息投递的延迟性。

尽管这能够保证RabbitMQ崩溃时消息不会丢失，可是它存在性能和伸缩性的问题，设置为持久化将会对消息投递和性能有着很大的影响。

app-id和user-id属性

app-id和user-id属性提供了关于消息的另外一层信息，能够携带一些信息以便消费者应用程序在处理消息以前进行验证。

app-id属性在AMQP规范中定义为“短字符串”，最多容许UTF-8字符。在生成消息时可使用app-id传递特定API和版本号。可增强使用app-id能够更容易地追踪恶意消息的来源。

user-id属性通常用于存放已经登陆的用户信息。

type属性

type属性被定义为“消息类型名称”，通常能够用于描述消息中的内容，应用程序能够根据它来肯定如何处理一个消息。

建立自描述消息时，type属性很是有用，它可用于指定记录类型或外部定义文件（使用Google的Protobuf）。

reply-to属性

使用reply-to能够构件一个用来恢复消息的私有响应队列。这个定义中有大多的不明确性，因此使用起来需谨慎。

headers属性

headers属性是key-value结构，容许用户自定义任意的key和value。

key能够是ASCII或Unicode字符串，最大长度为255个字符。value能够是任何有效的AMQP值类型。

与其余属性不一样，header属性容许你添加任何想要添加的数据到消息头表中。而且，RabbitMQ能够根据headers表中填充的值来路由消息，而不须要依赖路由键。

priority属性

截至3.5.0版本，RabbitMQ已经按照AMQP规范实现了priority字段，它的值被定义为0~9之间。用于指定队列中消息的优先级。

priority字段实现为无符号字节，因此优先级能够是0~255，但优先级应该被限制在0~9之间。

不能使用的属性：cluster-id/reserved

cluster-id属性在AMQP0-8中定义的，但随后被删除。

AMQP0-9-1将其重命名为reserved，并声明它必须为空，虽然RabbitMQ目前没有根据规范要求它是空的，但你最好彻底规避它。