在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，如下：
这里我们需要注意的是，我们肯定是需要先启动生产者在再启动消费者消费，让消息先堆积在队列中，其设置的优先级才会起作用。