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目前沒有根據規範要求它是空的，但你最好徹底規避它。