在RabbitMQ隊列的屬性中，我們介紹了RabbitMQ中隊列的一些屬性配置，這裏我們再來看看RabbitMQ中消息的控制，如下：
| 參數 | 說明 |
|---|---|
| content-type | 消息體的MIME類型，如application/json |
| content-encoding | 消息的編碼類型，如是否壓縮 |
| message-id | 消息的唯一性標識，由應用進行設置 |
| correlation-id | 一般用做關聯消息的message-id，常用於消息的響應 |
| timestamp | 消息的創建時刻，整形，精確到秒 |
| expiration | 消息的過期時刻， 字符串，但是呈現格式爲整型，精確到秒 |
| delivery-mode | 消息的持久化類型，1爲非持久化，2爲持久化，性能影響巨大 |
| app-id | 應用程序的類型和版本號 |
| user-id | 標識已登錄用戶，極少使用 |
| type | 消息類型名稱，完全由應用決定如何使用該字段 |
| reply-to | 構建回覆消息的私有響應隊列 |
| headers | 鍵/值對錶，用戶自定義任意的鍵和值 |
| priority | 指定隊列中消息的優先級 |
首先前兩個參數content-type、content-encoding就不過多介紹了，這兩個參數我們在http協議中就經常見到，這裏其用於表示的含義也是一樣的。
這裏我們主要來看看message-id和correlation-id，這兩個參數一般都是由應用進行設置的，再結合reply-to屬性，我們就可以使用一個類似ActiveMQ的Request-Response模式，如下：
消息生產者發佈消息然後等待消費者進行響應，那麼我們肯定在生產者端也是需要隊列及消費者的，用來接收響應消息，並且我們在發佈消息時需要告訴消費者響應消息應該發往那個隊列（即我們生產者消費者響應消息的隊列）。另外爲了生產者可能把消息和響應消息一一對應，這裏我們還需設置messageId
消費者端當然在接受完消息後，需要再次發佈一條響應消息，如下：
timestamp表示消息的創建時刻，該參數精確到秒，表現爲整形。
expiration表示消息的過期時刻，這裏也是精確到秒，但是這裏需要注意的是，其表現形式不是整形，而是一個字符串。
這裏看過RabbitMQ隊列的屬性應該還記得，在隊列的屬性中，我們是可以通過x-expires進行配置其過期時間的，其表示該隊列中所有的消息的過期時間，那麼如果我們兩者都進行配置了，那麼該消息的過期時間則會以先過期的時間爲準。
這裏我們額外提一點，就是在ActiveMQ的延遲和定時投遞中，我們ActiveMQ是可以進行延時投遞消息的，那麼RabbitMQ也可以實現延時發佈消息麼，這裏我們就可以利用該過期時間來實現消息的延時發佈，其主要思路就是利用消息的過期機制和RabbitMQ死信交換器
delivery-mode表示消息的持久化，這裏一般在進行消息的持久化的時候，我們都必須將其交換器及隊列也進行持久化處理。如下：
然後我們在發送消息時，將消息也進行持久化即可，其設置方式和上述Request-Response模式類似，如下：
不過在MQ中消息的持久化，在日常工作中比較常用的，所以RabbitMQ中也提供了較爲簡單的方式，如下：
其實就是其內部幫我們設置好了，和上述本質上是一致的
app-id主要用來標識應用程序的類型和版本號，比如消息的生產者進行升級了，但是消費者可能還沒有進行升級，這時我們就可以在生產者發送消息時攜帶一個app-id，這樣就可以用於來區別不同的消費者來消費者，比較類似於Dubbo中的version
user-id用於標識已登錄用戶，一般也很少使用，另外type表示消息類型名稱，完全由我們的應用需求來決定如何使用該字段，如果需求沒有相應的參數來設置的話，我們可以用headers來處理，用戶可以自定義任意的鍵和值。
最後priority表示消息的優先級，這裏我們在RabbitMQ隊列的屬性中也介紹了隊列的優先級，這裏一般結合進行使用，如下：
我們依次發送error、warn、info三條消息，前兩條優先級設置爲50，最優一條設置爲100，如下：
這裏我們需要注意的是，我們肯定是需要先啓動生產者在再啓動消費者消費，讓消息先堆積在隊列中，其設置的優先級纔會起作用。