簡介

當使用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目前沒有根據規范要求它是空的，但你最好完全規避它。