RabbitMQ之AMQP

发表于 更新于 分类于

RabbitMQ之AMQP

AMQP

Advanced Message Queuing Protocol

AMQP 0-9-1 is a programmable protocol in the sense that AMQP 0-9-1 entities and routing schemes are primarily defined by applications themselves, not a broker administrator. Accordingly, provision is made for protocol operations that declare queues and exchanges, define bindings between them, subscribe to queues and so on.

  • publisher： applications that publish them, also known as producers
  • consumer： applications that process them
Screen Shot 2020-07-20 at 4.29.52 PM

Networks are unreliable and applications may fail to process messages therefore the AMQP 0-9-1 model has a notion of message acknowledgements: automatically or explicitly

dead letter queue when a message cannot be routed, messages may be returned to publishers, dropped, or, if the broker implements an extension

Eg: reject without requeuing

  • Queue
  • Exchange
  • Bindings

Exchange Types

Exchange type Default pre-declared names
Direct exchange (Empty string) and amq.direct
Fanout exchange amq.fanout
Topic exchange amq.topic
Headers exchange amq.match (and amq.headers in RabbitMQ)

Exchange attributes:

  • Name
  • Durability (exchanges survive broker restart)
  • Auto-delete (exchange is deleted when last queue is unbound from it)
  • Arguments (optional, used by plugins and broker-specific features)

1. default exchange

no name(empty string); Every Queue Created will be automactically bind to it with a routing key which is the same as queuename

2. direct exchange

Deliever msg to queues base on message routing key, ideal for unicast

  • queue bind to exchange with routing key K
  • msg with routing key R arrives at exchange, exchange route it to queue if K = R

use case: distribute taks between multiple works in round robin (load balance are between consumers not queues!)

Screen Shot 2020-07-20 at 4.54.54 PM

3. Fanout Exchange

Route msg to all of the queues bound to it , ignore routing key, ideal for multicast

use case: Massively multi-player online (MMO) games, Sport news sites , Distributed systems can broadcast various state and configuration updates

Screen Shot 2020-07-20 at 4.57.40 PM

4. Topic exchange

Topic exchange route msg to one or many queues basied on matchng between routingkey and the pattern used to bind a queue to exchange.

Usage: categorization - logging

5. header exchange

A headers exchange is designed for routing on multiple attributes that are more easily expressed as message headers than a routing key. Headers exchanges ignore the routing key attribute. Instead, the attributes used for routing are taken from the headers attribute

Queue

  • Name
  • Durable (the queue will survive a broker restart)
  • Exclusive (used by only one connection and the queue will be deleted when that connection closes)
  • Auto-delete (queue that has had at least one consumer is deleted when last consumer unsubscribes)
  • Arguments (optional; used by plugins and broker-specific features such as message TTL, queue length limit, etc)

Bindings

Bindings are rules that exchanges use (among other things) to route messages to queues. To

To draw an analogy:

  • Queue is like your destination in New York city
  • Exchange is like JFK airport
  • Bindings are routes from JFK to your destination. There can be zero or many ways to reach it

Consumer

  • Subscribe to have messages delivered to them ("push API"): this is the recommended option - queue

  • Polling ("pull API"): this way is highly inefficient and should be avoided in most cases

Mesage Acknowledgements

  • [Automatic]After broker sends a message to an application (using either basic.deliver or basic.get-ok method).
  • [Explicit]After the application sends back an acknowledgement (using the basic.ack method)

Explicit Acknowledgement:

Client decide when to ack: after received or fully processed it

If not ack, borker will re-deliver , if no availabe consumers , wait util at least one consumer regiestered for the queue

Rejecting Message

basic.reject

Reject + discard or requeue

When there is onely one consumer, make sure do not create infinite msg delivery loop by rejecting/requeuing .

No support for negatively ack msg in bulk.

Negative Acknowledgements

TO reject msg in bulk,

  • client set multiple flag of basic.nackto true
  • broker reject all including up to delivery_tag
Screen Shot 2020-07-20 at 5.40.05 PM

Prefetch Count

channel-level prefetch-count,

For cases when multiple consumers share a queue, it is useful to be able to specify how many messages each consumer can be sent at once before sending the next acknowledgement.

Screen Shot 2020-07-20 at 5.49.05 PM

Message attributes and payload

Some attributes are used by AMQP brokers, but most are open to interpretation by applications that receive them

It is possible for messages to contain only attributes and no payload

Messages may be published as persistent, which makes the broker persist them to disk. - Performance Cost

Msg Ack

Since networks are unreliable and applications fail, it is often necessary to have some kind of processing acknowledgement.

  • sometimes it's only necessary to confirm msg delivery
  • sometimes msg was validated and processed by consumer

message acknowledgements

if ack for msg was expected but not recevied by AMQP broker, the msg is re-queued

AMQP 0-9-1 Methods

https://www.rabbitmq.com/amqp-0-9-1-reference.html

Common:

  • exchange.declare
  • exchange.declare-ok
  • exchange.delete
  • exchange.delete-ok
  • queue.declare
  • queue.declare-ok

Connections

MQP 0-9-1 connections are multiplexed with channels that can be thought of as "lightweight connections that share a single TCP connection".

Every protocol operation performed by a client happens on a channel.

channel only exists in the context of a connection and never on its own.For applications that use multiple threads/processes for processing, it is very common to open a new channel per thread/process and not share channels between them.