RabbitMQ消息的属性
在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
进行配置其过期时间的,其表示该队列中所有的消息的过期时间,那么如果我们两者都进行配置了,那么该消息的过期时间则会以先过期的时间为准。
delivery-mode
表示消息的持久化,这里一般在进行消息的持久化的时候,我们都必须将其交换器及队列也进行持久化处理。如下:
然后我们在发送消息时,将消息也进行持久化即可,其设置方式和上述Request-Response模式类似,如下:
不过在MQ中消息的持久化,在日常工作中比较常用的,所以RabbitMQ中也提供了较为简单的方式,如下:
其实就是其内部帮我们设置好了,和上述本质上是一致的
app-id
主要用来标识应用程序的类型和版本号,比如消息的生产者进行升级了,但是消费者可能还没有进行升级,这时我们就可以在生产者发送消息时携带一个app-id
,这样就可以用于来区别不同的消费者来消费者,比较类似于Dubbo中的version
user-id
用于标识已登录用户,一般也很少使用,另外type
表示消息类型名称,完全由我们的应用需求来决定如何使用该字段,如果需求没有相应的参数来设置的话,我们可以用headers
来处理,用户可以自定义任意的键和值。
最后priority
表示消息的优先级,这里我们在RabbitMQ队列的属性中也介绍了队列的优先级,这里一般结合进行使用,如下:
我们依次发送error、warn、info三条消息,前两条优先级设置为50,最优一条设置为100,如下:
这里我们需要注意的是,我们肯定是需要先启动生产者在再启动消费者消费,让消息先堆积在队列中,其设置的优先级才会起作用。