AMQP-核心概念-5

avatar
作者
猴君
阅读量:0

本文参考以下链接摘录翻译:

https://www.rabbitmq.com/tutorials/amqp-concepts

消息确认(Message Acknowledgements)

消费者应用,就是接收和处理消息的应用。它们偶尔会处理个别消息失败,断开与服务器之间的连接或许多其他失败。

也可能有网络问题导致的问题。这些情况提出了一个问题:消息代理应该在何时删除消息?AMQP 0-9-1让消费者来控制消息的删除时机。有2中确认模式:

  • 在消息代理将一条消息发送给一个应用后删除这条消息(使用basic.deliver 或 basic.get-ok 方法)【自动确认模式】
  • 在消费者应用发送回确认后删除(使用basic.ack方法)【显式确认模式】

使用显式确认时,应用选择何时发送确认。可以在收到消息后马上发送,可以在将消息保存到数据库尚未处理前发送,或者在完全处理完一条消息后发送(例如,成功获取了一个网络页面,处理完并存储到某个持久化数据库)。

如果一个消费者挂掉了,没用发回确认,消息代理会将消息重新发送给另一个消费者,如果正好没有可接收消息的消费者,消息代理会等到至少有一个消费者订阅这个队列,然后尝试重新发送消息给这个消费者。

拒绝消息(Rejecting Messages)

当一个消费者应用收到一条消息,消息处理可能成功或失败。一个应用可以通过拒绝一条消息来告知消息代理:消息处理失败了(或者当前不能完成消息处理)。当拒绝一条消息,应用可以叫消息代理删除消息或将消息重新放入队列。当一个队列只有一个消费者时,确保不要因为同一个消费者拒绝和重新入队一条消息,而产生无限的消息发送循环

反向确认(Negative Acknowlegements)

拒绝消息使用basic.reject方法。basic.reject有一个限制:无法一次拒绝多条消息,但ack可以一次确认多条消息。尽管如此,如果你使用RabbitMQ,可以用RabbitMQ的反向确认【negative acknowlegements 或 nacks】来实现。

预取消息(Prefetching Messages)

对于多个消费者共享一个队列的情形,在发送下一次确认之前,指定每次发送多少条消息给一个消费者是有用的。这可以实现简单的负载均衡,或者增加吞吐量,如果想批量发送消息的话。例如,一个生产者应用每分钟发送消息,由于它工作的特质。

消息属性和负载(Message Attributes and Payload)

AMQP 0-9-1模型中的消息有属性。有些属性很常见,应用开发者不必关心它们的名字。下面是一些属性名:

  • Content Type
  • Content encoding
  • Routing key 路由键
  • Delivery mode(persist or not) 发送模式,持久化或否
  • Message priority 消息优先级
  • Message publishing timestamp 消息发布时间戳
  • Publisher application id 发布者应用id

一些属性被AMQP代理使用,但绝大多数都得由接收消息的应用去解析。有些熟悉是可选得,叫做头(headers)。它们与HTTP中的X-Headers类似。消息属性在消息发布时设置。

消息也有一个负载(即消息携带的数据),在AMQP代理中,负载是一个透明的字节数组。消息代理不会审查或修改负载。消息可以只包含属性,不包含负载。为了将结构化数据设置为负载,一般用序列化格式,如JSON,Thrift, Protocol Buffers和MessagePack来序列化。经常使用content-type和content-encoding来说明数据格式,原则上是这样。

消息可以发布为持久化的,这时消息代理会把消息保存到磁盘。如果代理服务器被重启了,系统会确保收到的持久化消息不会丢失。简单地发布一条消息到一个持久化的交换机或持久化的队列,不会让这条消息被持久化。消息的持久化完全依赖消息自身的持久化模式。将消息发布为持久化会影响性能(就像数据存储,持久化带来一定的性能消耗)。

待续。。。

广告一刻

为您即时展示最新活动产品广告消息,让您随时掌握产品活动新动态!