簡介
當使用RabbitMQ發佈消息時，消息又AMQP規範中的三個低層幀類型組成：
- Basic.publish方法幀；
- 內容頭幀；
- 消息體幀；
這三種幀類型按順序一起工作，以便消息傳遞時完好無損。
其中，內容頭幀中的消息屬性是一種預定義的值，這些值通過設置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目前沒有根據規範要求它是空的，但你最好完全規避它。