分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow
也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!
第1章 概述
1.1. 本文档的目标
这份文档定义了高级消息队列协议,这个协议使得遵从该协议的客户端应用和消息中间件服务器之间能够互相通信。为了完全实现互操作性,我们还定义了消息中间件服务的标准行为。
我们面对这个领域有经验的技术读者,同时还提供了足够的规范和指南,一个合适的技术工程师可以根据这些文档在任何硬件平台上用各种编程语言来构建遵从该协议的解决方案。
1.2. 专利
AMQP的设计目标之一是它的概念都来自于现有的、无产权阻碍的、广泛推行的标准——比如由互联网工程任务组和万维网颁布的标准。
因此,我们相信仅用众所周知的一些技术就能够实现AMQP服务,比如现有的开源网络程序和电子邮件路由软件或者那些技术专家们所熟悉的技术。
1.3. 摘要
1.3.1. 什么是AMQP
高级消息队列协议使得遵从该规范的客户端应用和消息中间件服务器的全功能互操作成为可能。
1.3.2. 为什么要用AMQP
我们的目标是实现一种在全行业广泛使用的标准消息中间件技术,以便降低企业和系统集成的开销,并且向大众提供工业级的集成服务。
我们的宗旨是通过AMQP,让消息中间件的能力最终被网络本身所具有,并且通过消息中间件的广泛使用发展出一系列有用的应用程序。
1.3.3. AMQP的范围
为了完全实现消息中间件的互操作性,需要充分定义网络协议和消息代理服务的功能语义。
因此,AMQP定义网络协议和代理服务如下:
- 一套确定的消息交换功能,也就是“高级消息交换协议模型”。AMQP模型包括一套用于路由和存储消息的功能模块,以及一套在这些模块之间交换消息的规则。
- 一个网络线级协议(数据传输格式),客户端应用可以通过这个协议与消息代理和它实现的AMQP模型进行交互通信。
可以只实现AMQP协议规范中的的部分语义,但是我们相信明确的描述这些语义有助于理解这个协议。
1.3.4. 高级消息交换协议
1.3.4.1. AMQP模型
我们需要明确的定义服务器的语义,因为所有服务器实现都应该保持这些语义的一致性,否则就无法进行互操作。
因此AMQP模型描述了一套模块化的组件以及这些组件之间进行连接的标准规则。
在服务器中,三个主要功能模块连接成一个处理链完成预期的功能:
- “exchange”接收发布应用程序发送的消息,并根据一定的规则将这些消息路由到“消息队列”。
- “message queue”存储消息,直到这些消息被消费者安全处理完为止。
- “binding”定义了exchange和message queue之间的关联,提供路由规则。
使用这个模型我们可以很容易的模拟出存储转发队列和主题订阅这些典型的消息中间件概念。
一个AMQP服务器类似于邮件服务器,exchage类似于消息传输代理(email里的概念),message queue类似于邮箱。Binding定义了每一个传输代理中的消息路由表,发布者将消息发给特定的传输代理,然后传输代理将这些消息路由到邮箱中,消费者从这些邮箱中取出消息。
在以前的中间件系统的应用场景中,发布者直接将消息发送给邮箱或者邮件列表。
区别就在于用户可以控制message queue与exchage的连接规则,这可以做很多有趣的事情,比如定义一条规则:“将所有包含这样这样的消息头的消息都复制一份再发送到消息队列中”。
AMQP模型有以下目标:
- 支持金融服务领域的语义要求。
- 支持金融服务领域所要求的性能要求。
- 能够很方便的扩展新的消息路由和队列。
- 通过AMQP协议(AMQP和AMQP Protocol的是整体和部分的关系),服务器应用可以通过编程的方式来实现具体的功能语义。
- 简单而灵活。
1.3.4.2. AMQP协议
AMQP协议是一个二进制协议,拥有一些现代特点:多信道、协商式、异步、安全、跨平台、中立、高效。
AMQP通常被划分为三层:
模型层定义了一套命令(按功能分类),客户端应用可以利用这些命令来实现它的业务功能。
会话层负责将命令从客户端应用传递给服务器,再将服务器的应答传递给客户端应用,会话层为这个传递过程提供可靠性、同步机制和错误处理。
传输层提供帧处理、信道复用、错误检测和数据表示。
实现者可以将传输层替换成任意传输协议,只要不改变AMQP协议中与客户端应用程序相关的功能。实现者还可以使用其他高层协议中的会话层。
AMQP模型的设计由以下几个需求所驱动:
- 保证遵从AMQP规范的服务器实现之间能够进行互操作。
- 为服务质量提供显示控制。
- 支持所有消息中间件的功能:消息交换、文件传输、流传输、远程进程调用等。
- 兼容已有的消息API规范(比如Sun公司的JMS规范)。
- 形成一致和明确的命名。
- 通过AMQP协议可以完整的配置服务器线路(TODO:server wiring是啥意思?)。
- 使用命令符号可以很容易的映射成应用级别的API。
- 明确定义每一个操作只做一件事情。
AMQP传输层的设计由以下几个主要的需求所驱动,这些需求不分先后次序:
- 使用能够快速打包解包的二进制编码来保证数据的紧凑性。
- 能够处理任意大小的消息。
- 允许零拷贝数据传输(比如远程DMA)。
- 一个连接支持多个会话。
- 保证会话能够从网络错误、服务器失效中恢复。
- 为了长期存在,没有隐含的内置限制(TODO:To be long-lived,with no significant in-built limitations)。
- 异步传输消息。
- 能够很容易的处理新的和变化的需求。
- 高版本的AMQP规范能够兼容低版本的规范。
- 使用强断言模型来保证应用程序的可修复性。
- 保持编程语言的中立性。
- 适宜使用代码生成工具生成协议处理模块。
1.3.5. 功能范围
我们支持各种消息交换的体系结构:
- 存储转发(多个消息发送者,单个消息接收者)。
- 分布式事务(多个消息发送者,多个消息接收者)。
- 发布订阅(多个消息发送者,多个消息接收者)。
- 基于内容的路由(多个消息发送者,多个消息接收者)。
- 文件传输队列(多个消息发送者,多个消息接收者)。
- 点对点连接(单个消息发送者,单个消息接收者)。
1.4. 本文档的结构
本文档分成两个部分:
- “概念”部分将对AMQP的概念做一个简单的介绍,描述AMQP怎么工作,以及AMQP的用途。
- “标准”部分将对AMQP的模型层、会话层的每个组成部分做精确的定义,还将定义AMQP在网络上传输的二进制消息结构。
- 我们用IETF RFC2119中的术语定义:必须、不必、应该、不应该和可以(详见http://www.ietf.org/rfc/rfc2119.txt)。
- 当我们讨论遵从AMQP规范的服务器的具体行为时,我们使用术语“服务器”来表示这些服务器。
- 当我们讨论遵从AMQP规范的客户端应用的具体行为时,我们使用术语“客户端”来表示这些客户端应用。
- 我们使用“端点”来表示“服务器或者客户端”。
- 除非另有说明,所有数字都是十进制的。
- 协议中的常量都用大写字母的名字来表示。AMQP的实现如果需要在代码或者文档中定义和使用这些常量,必须用这些名字来表示。
- 属性名、命令或者控制参数,以及帧字段都用小写字母的名字来表示。AMQP的实现必须在代码或者文档中与之保持一致。
1.5. 约定
1.5.1. 定义
1.5.2. 版本号
AMQP版本用两个版本号表示——主版本号和次版本号。我们约定版本由主版本号后面加小数点再加上次版本号组成(比如1-3表示主版本号为1,次版本号为3)。
- 主版本号和次版本号可以用0到255之内的所有值。
- 主版本号保持不变,次版本号递增。当AMQP工作组提升主版本号时,次版本号将被设置为0。因此,有可能出现这样的版本序列:1-2,1-3,1-4,2-0,2-1……
- 一旦本协议发布之后(主版本号大于1),应尽量防止次版本号递增到9。不过在发布之前(版本0-x),由于会对本协议进行频繁的修订,可以不遵守这条约定。
- 一旦本协议发布之后(主版本号大于1),同一个主版本不同次版本的实现必须向后兼容。而在发布之前,这些次版本的实现不需要兼容。
- 大于或者等于99的主版本号用于测试和开发目的。
1.5.3. 技术术语
- AMQP模型(AMQP Model):一个由关键实体和语义表示的逻辑框架,遵从AMQP规范的服务器必须提供这些实体和语义。为了实现本规范中定义的语义,客户端可以发送命令来控制AMQP服务器。