AMQP10：通用消息队列协议标准

5星 · 超过95%的资源需积分: 10 37 浏览量更新于2024-07-24 1 收藏 1.59MB PDF 举报

"AMQP10标准是Advanced Message Queuing Protocol（高级消息队列协议）的一个版本，它定义了一个网络协议，允许符合标准的客户端应用程序与符合标准的消息中间件服务进行通信。此协议的目标是实现客户端和中间件服务之间的互操作性，并规定了消息中间件服务的规范行为。AMQP是一个通用的中间件标准，由多个公司和机构共同拥有版权，并提供许可，允许复制、显示、分发和实施AMQP规范，以实现该协议的实现。" AMQP（Advanced Message Queuing Protocol）是一种开放标准，用于在分布式系统中可靠地交换消息。这个协议设计的核心目标是提供一个跨平台的、可移植的、高效的解决方案，使得不同的应用和系统可以相互通信，而无需关心它们的实现细节或编程语言。AMQP10是AMQP协议的特定版本，它带来了若干改进和增强，以适应不断变化的IT环境。 AMQP10标准中的主要概念包括： 1. **消息模型**：AMQP基于发布/订阅和队列模型，其中生产者发布消息到交换机，交换机根据预定义的规则将消息路由到一个或多个队列，然后消费者从队列中接收消息。这种模型允许异步处理，提高了系统的可扩展性和容错性。 2. **帧结构**：AMQP使用帧作为基本的传输单元，每个帧包含类型、通道标识符、长度信息和实际数据。帧化的结构确保了网络传输的可靠性，即使在网络状况不佳时也能正确解析。 3. **连接与会话**：AMQP10引入了连接（Connection）和会话（Session）的概念。连接是两个AMQP实体之间的物理链路，而会话则是在连接上建立的逻辑双向通道，用于管理事务和同步。 4. **地址与绑定**：AMQP10中的地址用于指定消息的发送和接收位置，这包括交换机和队列的名称。绑定（Binding）定义了交换机如何根据路由键将消息路由到队列。 5. **事务与确认**：AMQP10支持事务和非事务消息传递，允许用户控制消息的原子性提交或回滚。同时，它还提供了确认机制，确保消息被正确处理或重传。 6. **安全性**：AMQP10通过SSL/TLS提供安全连接，确保数据在传输过程中的保密性和完整性。 7. **性能优化**：AMQP10设计时考虑了低延迟和高吞吐量，例如，通过批量发送和预取机制来减少网络交互次数，提高性能。 8. **可扩展性**：AMQP10允许添加新的特性或扩展，而不会破坏现有的协议兼容性，这使得AMQP能够适应未来的技术发展。 AMQP10标准的实施通常涉及到消息代理软件，如RabbitMQ、Apache Qpid等，这些代理软件实现了AMQP10规范，使得各种应用程序可以通过AMQP接口进行通信。这种标准化的通信方式在金融、物联网、云计算等多个领域有着广泛的应用，因为它能够有效地解决异构系统间的数据交换问题，提供高可用性和弹性。

Overview

One can partially imply the semantics of the server from the AMQP protocol specifications but we believe that an

explicit description of these semantics helps the understanding of the protocol.

1.3.4. The Advanced Message Queuing Protocol

1.3.4.1. The AMQP Model

We define the server's semantics explicitly, since interoperability demands that these semantics be the same in any

given server implementation.

The AMQP Model thus specifies a modular set of components and standard rules for connecting these.

There are three main types of component, which are connected into processing chains in the server to create the desired

functionality:

1. The "exchange" receives messages from publisher applications and routes these to "message queues", based on

arbitrary criteria, usually message properties or content.

2. The "message queue" stores messages until they can be safely processed by a consuming client application (or

multiple applications).

3. The "binding" defines the relationship between a message queue and an exchange and provides the message routing

criteria.

Using this model we can emulate the classic middleware concepts of store-and-forward queues and topic subscriptions

trivially.

In very gross terms, an AMQP server is analogous to an email server, with each exchange acting as a message transfer

agent, and each message queue as a mailbox. The bindings define the routing tables in each transfer agent. Publishers

send messages to individual transfer agents, which then route the messages into mailboxes. Consumers take messages

from mailboxes.

In many pre-AMQP middleware systems, by contrast, publishers send messages directly to individual mailboxes (in

the case of store-and-forward queues), or to mailing lists (in the case of topic subscriptions).

The difference is that when the rules connecting message queues to exchanges are under control of the architect (rather

than embedded in code), it becomes possible to do interesting things, such as define a rule that says, "place a copy of

all messages containing such-and-such a header into this message queue".

The AMQP model was conceived with the following goals:

1. To support the semantics required by the financial services industry.

2. To provide the levels of performance required by the financial services industry.

3. To be easily extended for new kinds of message routing and queuing.

4. To permit the server's specific semantics to be programmed by the application, via the protocol.

5. To be flexible yet simple.

1.3.4.2. The AMQP Protocol

The AMQP protocol is a binary protocol with modern features: it is multi-channel, negotiated, asynchronous, secure,

portable, neutral, and efficient.

AMQP is usefully split into three layers:

Overview

+------------------------Model-------------------------+

| |

| Messages Queues Exchanges |

| |

| Access Control Transactions |

| |

| Data Types |

| |

+------------------------------------------------------+

+-----------------------Session------------------------+

| |

| Commands Controls Exceptions |

| |

| Confirmation Completion |

| |

| Replay Synchronization |

| |

+------------------------------------------------------+

+----------------------Transport-----------------------+

| |

| Data Encoding Framing Failure Detection |

| |

| Multiplexing |

| |

+------------------------------------------------------+

The model layer defines a set of commands (grouped into logical classes of functionality) that do useful work on

behalf of the application.

The session layer provides reliable transport of commands from application to server and back with replay,

synchronization, and error handling.

The transport layer provides framing, channel multiplexing, failure detection, and data representation.

One could replace the transport layer with arbitrary transports without changing the application-visible functionality

of the protocol. One could also use the same session layer for different high-level protocols.

The design of the AMQP Model was driven by these requirements:

1. To guarantee interoperability between conforming implementations.

2. To provide explicit control over the quality of service.

3. To support any middleware domain: messaging, file transfer, streaming, RPC, etc.

4. To accommodate existing open messaging API standards (for example, Sun's JMS).

5. To be consistent and explicit in naming.

6. To allow complete configuration of server wiring via the protocol.

7. To use a command notation that maps easily into application-level API's.

8. To be clear, so each operation does exactly one thing.

The design of the AMQP transport layer was driven by these main requirements, in no particular order:

1. To be compact, using a binary encoding that packs and unpacks rapidly.

2. To handle messages of any size without significant limit.

Overview

4. We use the term "the peer" to mean "the server or the client".

5. All numeric values are decimal unless otherwise indicated.

6. Protocol constants are shown as upper-case names. AMQP implementations SHOULD use these names when

defining and using constants in source code and documentation.

7. Property names, command or control arguments, and frame fields are shown as lower-case names. AMQP

implementations SHOULD use these names consistently in source code and documentation.

1.5.2. Version Numbering

The AMQP version is expressed using two numbers – the major number and the minor number. By convention, the

version is expressed as the major number followed by a dash, followed by the minor number. (For example, 1-3 is

major = 1, minor = 3.)

1. Major and minor numbers may take any value between 0 and 255 inclusive.

2. Minor numbers are incremented with the major version remaining unchanged. When the AMQP working group

decides that a major version is appropriate, the major number is incremented, and the minor number is reset to 0.

Thus, a possible sequence could be 1-2, 1-3, 1-4, 2-0, 2-1...

3. Once the protocol reaches production (major >= 1), minor numbers greater than 9 would be strongly discouraged.

However, prior to production (versions 0-x), this may occur owing to the rapid and frequent revisions of the

protocol.

4. Once the protocol reaches production (major >=1), backwards compatibility between minor versions of the same

major version must be guaranteed by implementers. Conversely, backwards compatibility between minor versions

prior to production is neither guaranteed nor expected.

5. Major version numbers of 99 and above are reserved for internal testing and development purposes.

1.5.3. Technical Terminology

The following terms have special significance within the context of this document:

1. AMQP Model: A logical framework representing the key entities and semantics which must be made available

by an AMQP compliant server implementation, such that the server can be meaningfully manipulated by AMQP

Commands sent from a client in order to achieve the semantics defined in this specification.

2. Connection: A network connection, e.g. a TCP/IP socket connection.

3. Session: A named dialog between peers. Within the context of a Session, exactly-once delivery is guaranteed.

4. Channel: An independent bidirectional stream within a multiplexed connection. The physical transport for a

connected session.

5. Client: The initiator of an AMQP connection or session. AMQP is not symmetrical. Clients produce and consume

messages whereas servers queue and route messages.

6. Server: The process that accepts client connections and implements the AMQP message queuing and routing

functions. Also known as "broker"

7. Peer: Either party in an AMQP dialog. An AMQP connection involves exactly two peers (one is the client, one

is the server)

Overview

8. Partner: The term Partner is used as a convenient shorthand for describing the "other" Peer when describing an

interaction between two Peers. For example if we have defined Peer A and Peer B as opposite ends of a given

interaction, then Peer B is Peer A's Partner and Peer A is Peer B's partner.

9. Assembly: An ordered collection of Segments that form a logical unit of work.

10. Segment: An ordered collection of Frames that together form a complete syntactic sub-unit of an Assembly.

11. Frame: The atomic unit of transmission in AMQP. A Frame is an arbitrary fragment of a Segment.

12. Control: A formally defined one-way instruction assumed to be unreliably transported.

13. Command: A formally defined and identified instruction requiring acknowledgement. AMQP attempts to reliably

transport Commands.

14. Exception: A formally defined error condition that may occur during execution of one or more commands.

15. Class: A collection of AMQP commands or controls that deal with a specific type of functionality.

16. Header: A specific type of Segment that describes properties of message data.

17. Body: A specific type of Segment that contains application data. Body segments are entirely opaque - the server

does not examine or modify these in any way.

18. Content: The message data contained within a body segment.

19. Exchange: An entity within the server which receives messages from producer applications and routes these to

message queues within the server.

20. Exchange Type: The classification of an exchange based on routing semantics.

21. Message Queue: A named entity that holds messages until they can be sent to consumer applications.

22. Binding: A relationship that defines routing between a Message Queue and an Exchange.

23. Binding Key: A name for a binding. Some exchange types may use this as a pattern that defines the routing behavior

for the Binding.

24. Routing Key: A message header that an Exchange may use to decide how to route a specific message.

25. Durable: A server resource that survives a server restart.

26. Transient: A server resource that is wiped or reset after a server restart.

27. Persistent: A message that the server holds on reliable disk storage and MUST NOT lose after a server restart.

28. Non-Persistent: A message that the server holds in memory and MAY lose after a server restart.

29. Consumer: A client application that requests messages from a message queue.

30. Producer: A client application that publishes messages to an exchange.

31. 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.

These terms have no special significance within the context of AMQP:

1. Topic: Usually a means of distributing messages; AMQP implements topics using one or more types of exchange.

剩余290页未读，继续阅读

jzhx38745383

粉丝: 1
资源: 1

AMQP10：通用消息队列协议标准

AMQP中文规范

amqp0-10_AMQP_Called_

什么是AMQP？什么是SpringAMQP？

amqp-client api

什么是spring-amqp

AMQP通道跟MQI通道的区别

windows php8.1 安转 amqp

amqp如何防止消息丢失

宝塔 php7.3安装amqp

spring-boot-starter-amqp

最新资源