AMQP
(updated: )
Technical Terminology
- Connection: A network connection, e.g. a TCP/IP socket connection
- Channel: A bi-directional stream of communications between two AMQP peers. Channels are multiplexed so that a single network connection can carry multiple channels
- Client: The initiator of an AMQP connection or channel. AMQP is not symmetrical. Clients produce and consume messages while servers queue and route messages
- Server: The process that accepts client connections and implements the AMQP message queueing and routing functions. Also known as “broker”
- Peer: Either party in an AMQP connection. An AMQP connection involves exactly two peers (one is the client, one is the server)
- Frame: A formally-defined package of connection data. Contiguously - as a single unit - on the connection
- Protocol Class: A collection of AMQP commands (also known as Methods) that deal with a specific type of functionality
- Method: A specific type of AMQP command frame that passes instructions from one peer to the other
- Content: Application data passed from client to server and from server to client. AMQP content can be structured into multiple parts. The term is synonymous with “message”
- Content Header: A specific type of frame that describes a content’s properties
- Content Body: A specific type of frame that contains raw application data. Content body frames are entirely opaque - the server does not examine or modify these in any way
- Message: Synonymous with “content”
- Exchange: The entity within the server which receives messages from producer applications and optionally routes these to message queues within the server
- Exchange Type: The algorithm and implementation of a particular model of exchange. In contrast to the “exchange instance”, which is the entity that receives and routes messages within the server
- Message queue: A named entity that holds messages and forwards them to consumer applications.
- Binding: An entity that creates a relationship between a message queue and an exchange
- Routing key: A virtual address that an exchange may use to decide how to route a specific message
- Durable: A server resource that survives a server restart
- Transient: A server resource that is wiped or reset after a server restart
- Persistent: A message that the server holds on reliable disk storage and MUST NOT lose after a server restart
- Non-persistent: A message that the server holds in memory and MAY lose after a server restart
- Consumer: A client application that requests messages from a message queue
- Producer: A client application that publishes messages to an exchange
- Virtual host: A collection of exchanges, message queues and associated objects. Virtual hosts are independent server domains that share a common authentication and encryption environment. The client application chooses a virtual host after logging in to the server
- Realm: A set of server resources (exchanges and message queues) covered by a single security policy and access control. Applications ask for access rights for specific realms, rather than for specific resources
- Ticket: A token that a server provides to a client, for access to a specific realm
- Streaming: The process by which the server will send messages to the client at a pre-arranged rate
- Staging: The process by which a peer will transfer a large message to a temporary holding area before formally handing it over to the recipient. This is how AMQP implements re-startable file transfers
- Out-of-band transport: The technique by which data is carried outside the network connection. For example, one might send data across TCP/IP and then switch to using shared memory if one is talking to a peer on the same system
- Zero copy: The technique of transferring data without copying it to or from intermediate buffers. Zero copy requires that the protocol allows the out-of-band transfer of data as opaque blocks, as AMQP does
- Assertion: A condition that must be true for processing to continue
- Exception: A failed assertion, handled by closing either the Channel or the Connection
- Topic: Usually a means of distributing messages; AMQP implements topics using one or more types of exchange
- Subscription: Usually a request to receive data from topics; AMQP implements subscriptions as message queues and bindings
- Service: Usually synonymous with server. The AMQP standard uses “server” to conform with IETF standard nomenclature and to clarify the roles of each party in the protocol (both sides may be AMQP services)
- Broker: synonymous with server. The AMQP standard uses the terms “client” and “server” to conform with IETF standard nomenclature.
- Router: Sometimes used to describe the actions of an exchange. However exchanges can do more than message routing (they can also act as message end-points), and the term “router” has special significance in the network domain, so AMQP avoids using it.
RabbitMQ
AMQP Model
Channels
Channels are something like sessions.
Exchange
Where messages been put by producers.
Receives mesages from publishers and routes them to “message queue”, based on arbitrary criteria, usually message properties or content.
Exchange Types
Direct
Only one bound queue will see a given message. (Pool of workers)
Fanout
Every bound queues will see the same messages. (Pub/Sub)
Topic
Fanout + routing keys support (filtering)
Message Queue
Where messages been read by receviers.
Stores messages until they can be safely processed by consumer(s).
Binding
How the messages been routed from Exchanges to Queues.
Defines the relationship between a message queue and an exchange, and provides the message routing criteeria.
NPM libs
| Lib | Exchanges, Queues | Channels | Bindings |
|---|---|---|---|
| node-amqp | |||
| amqplib | |||
| rabbit.js |
Logstash
Output (logstash -> mq)
exchange: “was”
exchange_type: “fanout” # one of [“fanout”, “direct”, “topic”]
key: “logstash”
Input (mq -> logstash)
arguments: {}
auto_delete: false
exchange: “was”
exclusive: false
key: “logstash”
passive: false
queue: “”