wikipedia上的AMQP介绍

关注

翻译最新推荐文章于 2026-01-11 18:49:16 发布 2.4k 阅读 AI 写同款· GEO 优化 ›

openstack中的rpc通信 RPC即Remote Procedure Call(远程方法调用)，是Openstack中一种用来实现跨进程(或者跨机器)的通信机制。Openstack中同项目内(如nova, neutron, cinder...)各服务(service)及通过RPC实现彼此间通信。 RCP只定义了一个通信接口，其底层的实现可以各不相同。目前Openstack中的主要采用AMQP来实现。AMQP(Advance 阅读详情

原文：

http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol

Advanced Message Queuing Protocol

AMQP是针对面向消息中间件的开放式标准的应用层协议，它的特点是面向消息，存储队列，支持点对点及pub-sub的路由，可靠性和安全性。

AMQP允许来自不同供应商的消息生产者和消费者实现真正的互操作扩展，就如同SMTP、HTTP、FTP等协议采用的方式一样。而此前对于消息中间件的标准化努力则集中在API层面上(比如JMS)，且没有提供互操作性的途径。不同于JMS的仅仅定义API，AMQP是一个线路级的协议——它描述了通过网络传输的字节流的数据格式。因此，遵从这个协议的任何语言编写的工具均可以操作AMQP消息。

概述

AMQP从开始就被设计为供应商中立(跨厂商的互操作性)的管理企业商务系统中消息流的协议。

AMQP提供一个系统中后端消息(如数据存储、各种服务等)和前端消息(如用户应用程序等)的会合点。第一款应用程序出现在金融业如交易，市场和订单的消息流都是实时的。AMQP原生就被用于企业之间，因此可以很容易的处理各个组织之间的不同消息。

AMQP使得系统架构师能够以简单的模型来架构通用的消息模式应用程序。典型的消息模式有：request-response，消息被发送或者回应到特定的接收者；publish-and-subscribe，根据不同的接收条件，消息被分发到一系列回应者处；round-robin，任务被完全的分发到一系列的接收者处。现实中的应用程序可能会组合应用这些模式，如通过round-robin模式来实现分布式处理并组合request-response模式来发送对请求的响应。

AMQP协议规范定义了应用在client和server(又被称为broker)之间的二进制线路层协议。另外，规范还提出了供应商来实现的消息队列模型和一系列服务。

AMQP的队列模型提供了广泛适用的消息用例，使得client和broker的功能都比较精炼。broker的功能可分为两类：交换和消息队列。消息队列用来存储消息，不同的实现可以达成不同的QoS。例如，一个慢速但是能抵御消息风暴的队列可以用来在多点体系中提供冗余，而一个快速但是脆弱的消息队列则可以将每个消息保存在一个处理器的内存中。为了帮助提升互操作性，AMQP协议对于消息队列有一些规范定义，比如，可以请求broker创建一个新的消息队列等。

标准的AMQP交换机制没有对消息排序功能。通过交换，消息被送往存储并维护接收者的队列。交换机制实现一系列消息路由技术：one-to-one，就像单个email那样通知一个接收者；one-to-N，如同邮件列表；one-to-one-of-N，像是一个带开放检查点的队列，等等。所有的交换器都可接收多个发送者，AMQP也就允许所有的one-to-any路由变为N-to-any路由。配置一个交换的规则称为绑定，可以简单地只是将任何消息传递至队列，也可以复杂到对消息的内容进行检查。AMQP通过定制交换(可以是队列，发生器，消费者，路由消息等，取决于具体实现)允许任意条件的交换。

消息由两部分组成：用来路由的，由属性组成的"信封"，及应用程序产生的任意长度的消息内容。AMQP消息内容是不透明的二进制对象。消息在broker和client之间通过协议命令Basic.Publish及Basic.Deliver来传递。这两个命令都是异步的，所以当发生异常时，回应的消息会带有原来请求的命令。AMQP也提供了同步的消息传递命令Basic.Get/Get-Ok。

包含有因无路由而不能交换或者队列拒绝接收(队列已满)的错误信息发生时，broker可以被配置为通过不同的方式来处理异常。例如，将相关消息送往某个专用队列，或者仅仅粗暴的停止broker，等等。

开发

AMQP由JPMorgan自2004年中期至2006年中期独自开发。IMatix公司也开发了C/C++和java的实现。两家公司将这个协议文档化并且规范了互操作性，发起成立专门的工作组，成员有Red Hat, Cisco Systems, TWIST, IONA, iMatix等。及至2009年11月，工作组成员有：Bank of America, Barclays, Cisco Systems, Credit Suisse, Deutsche B?rse Systems, Envoy Technologies, Inc., Goldman Sachs, Progress Software, iMatix Corporation, JPMorgan Chase Bank Inc. N.A, Microsoft Corporation, Novell, Rabbit Technologies Ltd., Red Hat, Inc., Solace Systems, Tervela Inc., TWIST Process Innovations ltd, WS02 ，29West Inc.

AMQP的首要设计目标是为企业组织内部及其相互之间提供一个可以与既有的其他开放标准商业事务消息规范如FpML等通用协议进行互通，可作为SOAP可靠传输层的开放式标准的协议栈。

AMQP初始只是面向金融服务领域，但已经扩展为广泛通用的消息中间件应用。

AMQP模型

AMQP定义了一些实体。从连接的视角来看，强制实现的如下：

消息broker：AMQ客户端连接的服务器。可以集群方式运行，但这个由具体实现自行决定，并未涵盖在规范中。

用户：用户也是一个实体，可提供密码等认证机制来接入到broker，也可不经认证直接接入。

连接：物理的连接，如使用TCP/IP，SCTP等。连接是与用户绑定的。

通道：绑定到物理连接的逻辑信道。因此，经由通道的通信是有状态的。客户端在一个连接上提供并发操作应该为每一类分别提供单独的通道。例如，采用线程并发模型的客户端，可以声明thread-local变量来封装一个通道。

用来实际发送或者接收消息的实体都在同一个通道上声明，此声明确通知客户端该实体存在(或者之前已被其他客户端声明)。任何试图用不同的属性声明已声明的具名实体都将引发错误。为了改变此类实体的属性则必须先进行删除。

一些实体是具名的。他们的名字必须在整个他所在的broker中具有唯一性。因为客户端通常无法获取所有具名实体的列表(AMQP并未定义此类操作)，所以如何确保实体的名字唯一就是客户端的问题了。

实体名字以UTF-8编码，长度必须介于1至255个字符且以数字、字母或者下划线开始。

交换器

交换器是消息送达的实体。他是具名的，其类型也就是属性可以是：

passive：交换器不在事先被声明，如果其不存在将抛出错误。

durable：该交换器将在broker重启后生效。

auto-delete：该交换器将在没有消息队列绑定时自动删除。一个从未绑定任何队列的交换器不会自动删除。

注意：AMQP 1.0规范将定义可移除的交换器。

队列

队列是接收消息的实体，具有名字和属性，但没有类型。客户端可以订阅队列以便使broker递送某消息队列的内容到该客户端。另，客户端也可自动到队列取他所感兴趣的消息。

消息确保以它被送往队列时的顺序分发。但在进行某些重新路由的操作如失效处理时，其顺序则不能保证。

队列的属性有：

alternate-exchange：当消息被订阅者拒绝或者由于队列被删除而孤立时则被送往此交换器，同时队列中的该消息被删除。

passive：当队列不存在时会抛出一个错误信息，仍然不会被声明。

durable：队列将在broker重启时启动。

exclusive：队列仅服务于一个客户端。

auto-delete：队列在没有活跃订阅者的时候将自动删除。这个类似于具有auto-delete属性的交换器：如果队列上从未有活动的订阅者则不会自动删除。当客户端终结时，exclusive类型的队列则一定会自动删除。

注意：AMQP 1.0中，队列将替代交换器。

消息

消息是不具名的。它被发布到交换器。它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成：

routing-key：该域的使用取决于交换器的类型。

immediate：如果至少一个队列可以接收，但却没有订阅者，则该消息将被当作无路由进行处理。

delivery-mode：指出该消息可能需要持久性存储。broker仅对此类消息在被消费前进行最大能力的防丢失措施。如果不能确定broker终结时消息是否投递成功则可能会发生消息被多次投递的情况。不具有这个属性的消息则不会如此。

priority：相对于其他消息的优先权，范围0至9.

expiration：消息在被broker当作不可路由处理前的存续时间，以毫秒为单位。

绑定

绑定是队列和交换器之间的关系，规定消息如何由交换器到队列。绑定的属性被交换器用来与路由算法匹配。绑定和交换器算法可组合形成各种情形：

Unconditional：绑定无任何属性，交换器请求所有的消息。

Conditional on a fixed string：绑定有一个属性routingkey，请求所有与此标识相符的消息。

Conditional on a pattern match：绑定有一个属性routingkey，请求所有与此标识的模式匹配的消息。可以使用通配符。AMQP实现了主题匹配模式。

Conditional on multiple fixed strings：绑定有一个属性表，请求所有与各个表项匹配的消息。各表项的条件可以是与、或。

Conditional on multiple patterns：绑定有一个属性表，请求所有与各个表项的模式匹配的消息。

Conditional on algorithmic comparison：绑定有一个算术表达式(类似SQL的SELECT WHERE语句)，请求所有头部匹配此表达式的消息。

Conditional on content inspection：绑定指定通配符，请求所有消息实际内容与此条件相符的消息。

注意：这些并非全部是标准，取决于具体实现。

交换类型及对绑定的影响

以上4个实体形成了AMQP的基本模型。理解消息如何传递到队列的关键在于交换器的类型与路由关键字之间的关系。

当一个消息的路由关键字与绑定中的模式匹配时，交换器会把该消息的拷贝送达队列。如何进行匹配仅依赖于交换器的类型：

direct型：消息的路由关键字与绑定相同。

fanout型：总是匹配，即使绑定无关键字。

topic型：匹配路由关键字属性，字符串的各个部分以'.'分隔。可包含两个特殊字符：'*'表示单个任意词，'#'表示0个或多个词，例如 *.stock.# 匹配usd.stock和eur.stock.db，但不匹配stock.nasdaq。

headers型：匹配各个键-值对的逻辑组合结果。

其它由供应商自定义的交换器也被允许。

命名队列到命名交换器的绑定具有强大的属性——通过绑定使得这两个实体相互独立。例如，可以将同一个队列通过多个绑定连接到同一个或者多个交换器上。或者，多个消费者可以以相同的参数绑定到同一个队列上，这样每个消费者仅能得到其他消费者没有消费的消息。或者，多个消费者可以声明各自独立的队列但共享同一个绑定，如此，每个消费者都将得到与其他消费者相同的消息。

AMQP规范修订及其未来的发展

已经发布的规范版本如下：

0-8 in June 2006

0-9 in December 2006

0-10 (documents are undated)

0-9-1 in November 2008

1.0 draft (document is undated)

AMQP 1.0规范草案改变了AMQP的模型：移除交换器和绑定的概念，代之以队列和链接。这变将导致2个问题：

1. 发布者需要知道接收者的拓扑，即何种交换器及其类型；

2. 生产者的流控：如果一个交换器对两个不同的队列进行路由，其中一个空闲而另一个近乎满载，那么如何流控进行呢？

其他改变还包括类似Email和XMPP的队列地址模式。这将使得地址类型成为一等实体，允许发布者使用DNS来定位服务器。

实现