Chapter 4. AMQP


AMQP is an open internet protocol for reliably sending and receiving messages. It is supported by multiple software vendors and major institutions. AMQP 1.0 became an OASIS standard in 2012 and an ISO standard in 2014.

  • A framed protocol with session multiplexing
  • Supports peer-to-peer and client-server connections
  • Provides a standard type system for lossless data exchange
  • Offers flow control, heartbeating, and resource limits for increased reliability in distributed systems
  • Uses a space-efficient binary encoding and pipelining to reduce latency

4.1. AMQP delivery guarantees

The AMQP model for settlement is based on the lifecycle of a message delivery. At each end of a link, an entity representing a message transfer is created, it exists for some period of time, and finally it is "settled", meaning it can be forgotten. There are four events of interest in the combined lifecycle of a delivery.

  • The delivery is created at the sender.
  • The delivery is created at the receiver.
  • The delivery is settled at the sender.
  • The delivery is settled at the receiver.

Because the sender and receiver are operating concurrently, these events can occur in various orders, and the order of these events results in differing message delivery guarantees.

At-most-once delivery

At-most-once delivery is also known as "presettled" or "fire and forget" delivery.

  1. The delivery is created at the sender.
  2. The delivery is settled at the sender.
  3. The delivery is created at the receiver.
  4. The delivery is settled at the receiver.

In this configuration the sender settles (that is, forgets) the delivery before it reaches the receiver, and if anything happens to the delivery in flight, the sender has no basis for resending.

This mode is suited to applications where temporary message loss is acceptable, such as for periodic sensor data, or when the application itself can detect the failure and resend.

At-least-once delivery

  1. The delivery is created at the sender.
  2. The delivery is created at the receiver.
  3. The delivery is settled at the receiver.
  4. The delivery is settled at the sender.

In this configuration, the receiver settles the delivery when it has received it, and the sender settles once it sees the receiver has settled. If anything happens to the delivery in flight, the sender can resend. The receiver, however, has already forgotten the delivery, so a resend will result in a duplicate message delivery. Applications can use unique message IDs to filter out duplicates.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.