AMQP 0-9-1 Model Explained

Overview

This guide provides an overview of the AMQP 0-9-1 protocol, one of the protocols supported by RabbitMQ.

High-level Overview of AMQP 0-9-1 and the AMQP Model

What is AMQP 0-9-1?

AMQP 0-9-1 (Advanced Message Queuing Protocol) is a messaging protocol that enables conforming client applications to communicate with conforming messaging middleware brokers.

Brokers and Their Role

Messaging brokers receive messages from publishers (applications that publish them, also known as producers) and route them to consumers (applications that process them).

Since it is a network protocol, the publishers, consumers and the broker can all reside on different machines.

AMQP 0-9-1 Model in Brief

The AMQP 0-9-1 Model has the following view of the world: messages are published to exchanges, which are often compared to post offices or mailboxes. Exchanges then distribute message copies to queues using rules called bindings. Then the broker either deliver messages to consumers subscribed to queues, or consumers fetch/pull messages from queues on demand.

When publishing a message, publishers may specify various message attributes (message meta-data). Some of this meta-data may be used by the broker, however, the rest of it is completely opaque to the broker and is only used by applications that receive the message.

Networks are unreliable and applications may fail to process messages therefore the AMQP 0-9-1 model has a notion of message acknowledgements: when a message is delivered to a consumer the consumer notifies the broker, either automatically or as soon as the application developer chooses to do so. When message acknowledgements are in use, a broker will only completely remove a message from a queue when it receives a notification for that message (or group of messages).

In certain situations, for example, when a message cannot be routed, messages may be returned to publishers, dropped, or, if the broker implements an extension, placed into a so-called 'dead letter queue'. Publishers choose how to handle situations like this by publishing messages using certain parameters.

Queues, exchanges and bindings are collectively referred to as AMQP entities.

AMQP 0-9-1 is a Programmable 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.

This gives application developers a lot of freedom but also requires them to be aware of potential definition conflicts. In practice, definition conflicts are rare and often indicate a misconfiguration.

Applications declare the AMQP 0-9-1 entities that they need, define necessary routing schemes and may choose to delete AMQP 0-9-1 entities when they are no longer used.

Exchanges and Exchange Types

Exchanges are AMQP 0-9-1 entities where messages are sent. Exchanges take a message and route it into zero or more queues. The routing algorithm used depends on the exchange type and rules called bindings. AMQP 0-9-1 brokers provide four 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)

Besides the exchange type, exchanges are declared with a number of attributes, the most important of which are:

• 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)

Exchanges can be durable or transient. Durable exchanges survive broker restart whereas transient exchanges do not (they have to be redeclared when broker comes back online). Not all scenarios and use cases require exchanges to be durable.

Default Exchange

The default exchange is a direct exchange with no name (empty string) pre-declared by the broker. It has one special property that makes it very useful for simple applications: every queue that is created is automatically bound to it with a routing key which is the same as the queue name.

For example, when you declare a queue with the name of 'search-indexing-online', the AMQP 0-9-1 broker will bind it to the default exchange using 'search-indexing-online' as the routing key (in this context sometimes referred to as the binding key). Therefore, a message published to the default exchange with the routing key 'search-indexing-online' will be routed to the queue 'search-indexing-online'.

剩余内容已隐藏，支付完成后下载完整资料

---

AMQP 0-9-1模型解释

概述

本指南概述了AMQP 0-9-1协议，它是被RabbitMQ支持的协议之一。

AMQP 0-9-1协议和AMQP模型的高层概述

什么是AMQP 0-9-1?

AMQP 0-9-1（高级消息排队协议）是一个消息协议，它允许一致的客户端应用和一致的消息中间件进行通信。

中间件及其作用

消息中间件接受来自发布者（发布消息的应用，也称作生产者）的消息并且发送给消费者（处理消息的应用）。

由于它是一个网络协议，因此发布者、消费者和中间件能全部部署在不同的机器上。

AMQP 0-9-1模型简介

AMQP 0-9-1模型具有以下观点：消息被发布到交换器，它也常被比作邮局或者邮箱。交换器然后使用被称为绑定的规则将消息副本分配到队列。然后，中间件传递消息给订阅了队列的消费者，或者消费者按需从队列中取/拉消息。

当发布消息时，发布者可能会指定各种消息属性（消息元数据）。一些元数据可能被中间件使用。但是其余消息对中间件来说是完全不透明的，且仅被接受消息的应用程序所使用。

由于网络不可靠和应用程序可能无法成功处理消息，因此AMQP 0-9-1模型有一个消息确认的机制：当消息被传递给消费者，消费者会自动或者在应用程序开发者选择这样做之后通知中间件。当消息确认机制使用时，中间件仅在收到一条消息（或成组的消息）的通知时，才会从队列中完全删除这条消息。

在某些情况下，例如当消息无法被路由，消息可能会被返还给发布者、被丢弃或者（如果中间件实现了扩展）被放入所谓的“死信队列”。发布者通过在发布消息的时候设置某些参数来选择如何这种情况。

队列、交换器和绑定统称AMQP实体。

AMQP 0-9-1是一种可编程协议

AMQP 0-9-1实体和路由方式主要由应用程序自身而非中间件管理员来定义，就这种意义而言，AMQP 0-9-1是一种可编程协议。相应地，声明交换器和队列、定义它们之前的绑定、订阅队列等为协议操作做了准备。

这给了应用开发者许多自由，但是也要求他们注意潜在的定义冲突。事实上，定义冲突很少发生，而且如果发生通常表明配置错误。

应用程序声明它们需要的AMQP 0-9-1实体，定义必要的路由方案并且当AMQP 0-9-1实体不再使用时可能会选择删除它们。

交换器和交换类型

交换器是接收消息的AMQP 0-9-1实体。交换器接收一条消息并将它路由到零个或多个队列中。使用的路由算法取决于交换类型和绑定。AMQP 0-9-1中间件提供了四种交换类型：

交换类型	默认预设名称
直接交换	（空字符串）和amq.direct
扇出交换	amq.fanout
主题交换	amq.topic
首部交换	amq.match （和RabbitMQ 中的amq.headers）

除了交换类型，交换器还声明了许多属性，其中最重要的属性包括：

• 名称
• 持久性（中间件重启，交换器保留）
• 自动删除（当最后一个队列与交换器解绑后，交换器被删除）
• 参数（可选，被插件和中间件特定的特性所使用）

交换器可以是持久的或暂时的。持久交换器能在中间件重启后保留，而暂时交换器不能（它们必须在中间件重新上线之后重新声明）。

默认交换

默认交换器是被中间件预声明的没有名称（空字符串）的直接交换器。它有一个对简单应用非常有用的特殊属性：每个新创建的队列会自动用一个与队列名相同的路由键和默认交换器绑定。

例如，当你声明一个名称为“search-indexing-online”的队列，AMQP 0-9-1中间件会用“search-indexing-online”作为路由键（在此情况下有时也指绑定关键字），将其绑定到默认交换器。因此，发送给使用路由键“search-indexing-online”的默认交换器的消息，将会被路由到队列“search-indexing-online”。换句话说，默认交换器使得消息被直接传递到队列，即使技术上这没有发生。

直接交换

直接交换器根据消息的路由键来传递消息。直接交换是消息单播路由的理想选择（尽管它也可以用于多播路由）。下面是它的工作原理：

• 一个队列用路由键K绑定到交换器。
• 当一个带有路由键R的新消息到达直接交换器，如果K=R，则交换器会将其路由到对应的队列。

直接交换经常用于以轮询方式在多个工作者（相同应用的实例）之间分配任务。当这样做时，重点需要理解的是，在AMQP 0-9-1中，消息不是在队列中而是在消费者中进行负载均衡。

直接交换可以用图形表示：

扇出交换

扇出交换器路由消息给所有和它绑定的队列，并且路由键会被忽略。如果有N个队列被绑定到一个扇出交换器，当一个新的消息被发布到这个交换器，这条消息的副本将会被传递到所有的N个队列。扇出交换是消息广播路由的理想选择。

由于扇出交换器会将消息副本传递到每个与其绑定的队列中，它用例非常相似：

• 大型多人在线（Massively multi-player online, MMO）游戏可以将其用于排行榜更新或其他全局事件
• 体育新闻网站可以使用扇出交换来几乎实时地向移动客户端分发比分更新
• 分布式系统可以广播各种状态和配置更新
• 群组聊天可以使用扇出交换在参与者之间分发消息（尽管AMQP没有内置的在线状态概念，因此XMPP可能是更好的选择）

扇出交换可以用以下图形表示：

主题交换

根据消息路由键和用于将队列绑定到交换器的模式之间的匹配，主题交换器将消息路由到一个或多个队列。主题交换类型通常用于实现各种发布/订阅模式变体。主题交换通常用于消息的多播路由。

主题交换有一个非常庞大的用例集。每当问题涉及多个消费者/应用程序，并且它们有选择地选择它们想要接收的消息类型时，应考虑使用主题交换。

用例：

bull; 分发与特定地理位置有关的数据，例如销售点

bull; 由多个工作者执行的后台任务处理，每个工作者可以处理特定的任务集

bull; 股票价格更新（以及其他种类的金融数据的更新）

bull; 需要分类或标记的新闻更新（例如，仅针对一项特定运动或一支队伍）

bull; 云中各种服务的编排

bull; 特定于体系架构/操作系统的分布式软件的构建或打包，其中每个构建器只能处理一个体系架构或OS

首部交换

首部交换旨在用于在多个属性上进行路由。相比于路由键，这些属性更容易表示为消息首部。首部交换忽略路由键属性。作为替代，用于路由的属性取自首部属性。如果一个首部的值等于绑定时指定的值，则认为消息匹配。

可以使用多个用于匹配的首部将队列绑定到首部交换器。在这种情况下，中间件需要从应用程序开发者手中获得一条额外的信息，也就是，它认为消息应该与任意一个首部进行匹配还是与所有首部进行匹配？这就是绑定参数“x-match”的作用。当参数“x-match”设置为“any”时，仅一个首部值匹配就够了。而将“ x-match”设置为“all”，则要求所有值必须完全匹配。

首部交换可以看作是“加强版的直接交换”。由于首部交换根据标头值进行路由，因此可以用作直接交换，而路由键不必是字符串。例如，它可以是整数或散列（字典）。

请注意，以字符串x-开头的首部将不会用于进行匹配。

队列

AMQP 0-9-1模型中的队列非常类似于其他消息排队和任务排队系统中的队列：它们存储由应用程序消费的消息。队列与交换器的一些属性相同，但也具有一些额外属性：

• 名称
• 持久性（中间件重启，队列会保留）
• 独占性（仅被一个连接使用，并且当连接关闭时队列会被删除）
• 自动删除（当最后一个消费者退订时，原本拥有至少一个消费者的队列被删除）
• 参数（可选；被插件和中间件特定的特性所使用，例如消息TTL，队列长度限制等）

在使用队列之前，必须先声明它。如果一个队列尚不存在，那么声明它将会导致它被创建。如果队列已经存在并且其属性与声明中的相同，则该声明无效。当现有队列属性与声明中的属性不同时，将引发异常代码为406（PRECONDITION_FAILED）的通道级异常。

队列名称

应用程序可以选择队列名称，也可以要求中间件为其创建一个名称。队列名称最多可以包含255个字节的UTF-8字符。AMQP 0-9-1中间件可以为应用程序生成唯一的队列名称。要使用此特性，传递一个空字符串作为队列名称参数。生成的名称将与队列声明响应一起返回给客户端。

以“amq.”开头的队列名称，保留给中间件内部使用。试图使用违反该规则的名称来声明一个队列，将会引发异常代码为403（ACCESS_REFUSED）的通道级异常。

队列持久性

持久队列固化到磁盘，因此在中间件重新启动后仍然存在。非持久队列暂时的。并非所有场景和用例都要求队列是持久的。

队列的持久性不会使路由到该队列的消息持久化。如果关闭中间件然后将其打开，则在中间件启动期间持久队列将会被重新声明，但是只有持久消息将被恢复。

绑定

绑定是被交换器使用（除了其它规则）来将消息路由到队列的规则。为了指示交换器E将消息路由到队列Q，Q必须和E绑定。绑定可能具有被某些交换类型使用的可选路由键属性。路由键的目的是选择发布到交换器的某些消息，并将其路由到绑定的队列。换句话说，路由键充当一个过滤器。

打个比方：

• 队列就像你在纽约的目的地
• 交换器就像JFK机场（纽约肯尼迪国际机场）
• 绑定就是从JFK到你的目的地的路径。可以有零或多种方式到达目的地。

有了这一间接层，就可以通过直接发布到队列实现不可能或很难实现的路由场景，并且还消除了应用程序开发者必须要做的一定数量的重复工作。

如果消息无法被路由到任何队列（例如，由于该消息发布到的交换器没有绑定），则该消息将被丢弃或返回给发布者，这取决于发布者设置的消息属性。

消费者

除非应用程序可以消费它们，否则将消息存储在队列中是无用的。在AMQP 0-9-1模型中，应用程序可以通过两种方式来消费消息：

• 被动获得传递给它们的消息（“推送API”）
• 主动按需拉取消息（“拉取API”）

使用“推送API”，应用程序必须表明对消费来自特定队列的消息感兴趣。当它们这样做时，称应用程序注册成一个消费者，或者简单地说，订阅了一个队列。每个队列可能有一个以上的消费者，或者注册一个排他消费者（在它正在消费队列时，将其他所有消费者从队列中排除）。

每个消费者（订阅）都有一个称为消费者标签的标识符。它可以用于退订消息。消费者标签只能是字符串。

消息确认

消费者应用程序（即接收和处理消息的应用程序）有时可能无法处理个别消息，有时甚至会崩溃。网络问题也有可能引起故障。这就提出了一个疑问：中间件应该什么时候从队列中删除消息？AMQP 0-9-1规范使消费者可以对此进行控制。有两种确认模式：

• 在中间件向应用程序发送消息之后删除消息（使用basic.deliver或者basic.get-ok方法）
• 在应用程序发送回确认之后删除（使用basic.ack方法）

前者称为自动确认模型，而后者称为显式确认模型。使用显式确认模型，由应用程序来选择何时发送确认。可能是在刚刚收到消息时，或者在将消息持久化到数据存储之后（在处理之前），或者完全处理消息之后（例如，成功获取网页，将其处理并将其存储到某个持久数据存储中）。

如果消费者在没有发送确认的情况下消亡，则中间件会将其重新传递给另一位消费者，或者如果此时没有可用的消费者，则中间

剩余内容已隐藏，支付完成后下载完整资料

---

资料编号：[234248]，资料为PDF文档或Word文档，PDF文档可免费转换为Word