兼容性与一致性
RabbitMQ 核心代理实现了 AMQP 1.0 规范和 AMQP 0-9-1 规范，并包含一些 AMQP 0-9-1 扩展。
AMQP 1.0 是与 AMQP 0-9-1 完全不同的协议，两者使用不同的客户端库。RabbitMQ 将无限期地继续支持 AMQP 0-9-1，同时并行开展 AMQP 1.0 实现的工作。
为方便起见，下文列出了 0-9-1（含扩展及不含扩展）规范的链接。如需了解更多关于 AMQP 0-9-1 的信息，请参阅 AMQP 0-9-1 概述指南、AMQP 0-9-1 规范 PDF、AMQP 0-9-1 参考 PDF 以及其他文档。
来自 AMQP 0-9-1 版本规范的类
下表描述了各种 AMQP 协议消息类的当前实现状态。
| 当前状态 | 类 | 备注 |
|---|---|---|
| ok | connection | |
| ok | channel | |
| ok | exchange | |
| ok | queue | |
| ok | basic | |
| partial | tx | 请参阅 tx 支持说明 |
来自 AMQP 0-9-1 版本规范的方法
下表描述了每个类中各种 AMQP 协议方法的当前实现状态。
| 当前状态 | 方法 | 备注 |
|---|---|---|
| ok | connection.start | |
| ok | connection.start-ok | |
| ok | connection.secure | |
| ok | connection.secure-ok | |
| ok | connection.tune | |
| ok | connection.tune-ok | |
| ok | connection.open | |
| ok | connection.open-ok | |
| ok | connection.close | |
| ok | connection.close-ok | |
| ok | channel.open | |
| ok | channel.open-ok | |
| partial | channel.flow | 服务器不支持 active=false。通过 basic.qos 限制预取（prefetch）可提供更好的控制。 |
| ok | channel.flow-ok | |
| ok | channel.close | |
| ok | channel.close-ok | |
| ok | exchange.declare | |
| ok | exchange.declare-ok | |
| partial | exchange.delete | 我们将 exchange.delete 设置为一种幂等断言，要求交换机不得存在，这与 exchange.declare 要求交换机必须存在的方式相同。 |
| ok | exchange.delete-ok | |
| ok | queue.declare | |
| ok | queue.declare-ok | consumer-count 参数是所有消费者的计数，而不是规范所要求的仅活动消费者的计数。前者对应用程序更有用。 |
| ok | queue.bind | |
| ok | queue.bind-ok | |
| partial | queue.unbind | 我们将 queue.unbind 设置为一种幂等断言，要求绑定不得存在，这与 queue.bind 要求绑定必须存在的方式相同。 |
| ok | queue.unbind-ok | |
| ok | queue.purge | |
| ok | queue.purge-ok | |
| partial | queue.delete | 我们将 queue.delete 设置为一种幂等断言，要求队列不得存在，这与 queue.declare 要求队列必须存在的方式相同。 |
| ok | queue.delete-ok | |
| partial | basic.qos | 服务器支持每个消费者和每个通道的限制。global 标志的语义与规范中的不同。有关详细信息，请参阅 消费者预取。未实现预取大小限制。 |
| ok | basic.qos-ok | |
| partial | basic.consume | 未实现 no-local 参数。该参数的值被忽略，不会尝试阻止消费者接收在同一连接上发布的消息。 |
| ok | basic.consume-ok | |
| ok | basic.cancel | |
| ok | basic.cancel-ok | |
| ok | basic.publish | |
| ok | basic.return | |
| ok | basic.deliver | |
| ok | basic.get | |
| ok | basic.get-ok | |
| ok | basic.get-empty | |
| ok | basic.ack | |
| partial | basic.reject | 当 requeue=false 时，服务器丢弃消息；当 requeue=true 时，服务器将消息重新入队。不会尝试阻止向同一客户端重新投递。服务器不会中断被拒绝消息的消息内容发送，即消息始终完整地传递给客户端。 |
| partial | basic.recover | 不支持 requeue=false 的恢复。 |
| ok | tx.select | |
| ok | tx.select-ok | |
| ok | tx.commit | |
| ok | tx.commit-ok | |
| ok | tx.rollback | |
| ok | tx.rollback-ok |
来自 AMQP 0-9-1 版本规范的规则
参考列包含类或域、方法、字段以及规则名称（如果存在）。
| 当前状态 | 类型 | 角色 | 参考 | 文本 |
|---|---|---|---|---|
| ok | 不得 (MUST NOT) | delivery-tag / channel-local | 投递标签（delivery tag）仅在接收消息的通道内有效。即，客户端不得在一个通道上接收消息，然后在另一个通道上对其进行确认。 | |
| ok | 不得 (MUST NOT) | delivery-tag / non-zero | 服务器不得为投递标签使用零值。零保留供客户端使用，意为“迄今为止接收到的所有消息”。 | |
| 执行 | 应该 (SHOULD) | redelivered / implementation | 如果可能，服务器应该尝试在重新投递消息时发出信号。当重新投递未成功确认的消息时，服务器应该尽可能将其投递给原始客户端。 | |
| 计划 | 不得 (MUST NOT) | redelivered / hinting | 客户端不得依赖 redelivered 字段，但应将其视为一条暗示，表明消息可能已经被处理过。一个稳健的客户端必须能够追踪非事务通道和本地事务通道上重复接收的消息。 说明： 客户端已经符合此要求，因为它不依赖 redelivered 字段，我们计划在未来的版本中添加重复追踪功能。 | |
| ok | 必须 (MUST) | 客户端 | connection / start / protocol-name | 如果服务器不支持协议头中指定的协议，则必须响应一个有效的协议头，然后关闭套接字连接。 |
| ok | 必须 (MUST) | 客户端 | connection / start / server-support | 服务器必须提供一个小于或等于客户端在协议头中请求的协议版本。 |
| ok | 必须 (MUST) | 客户端 | connection / start / client-support | 如果客户端无法处理服务器建议的协议版本，则必须关闭套接字连接，而不发送任何进一步的数据。 |
| 执行 | 应该 (SHOULD) | 客户端 | connection / start / server-properties / required-fields | 属性应该至少包含以下字段：“host”（指定服务器主机名或地址）、“product”（服务器产品名称）、“version”（服务器版本）、“platform”（操作系统名称）、“copyright”（如适用）以及“information”（其他通用信息）。 |
| ok | 必须 (MUST) | 客户端 | connection / start / locales / required-support | 服务器必须至少支持 en_US 区域设置。 |
| 执行 | 应该 (SHOULD) | 服务器 | connection / start-ok / client-properties / required-fields | 属性应该至少包含以下字段：“product”（客户端产品名称）、“version”（客户端版本）、“platform”（操作系统名称）、“copyright”（如适用）以及“information”（其他通用信息）。 |
| ok | 应该 (SHOULD) | 服务器 | connection / start-ok / mechanism / security | 客户端应该使用服务器提供列表中它能处理的最高级别安全配置进行身份验证。 |
| ok | 必须 (MUST) | 服务器 | connection / start-ok / mechanism / validity | 如果 mechanism 字段不包含服务器在 Start 方法中提议的安全机制之一，服务器必须关闭连接，而不发送任何进一步的数据。 |
| ok | 必须 (MUST) | 客户端 | connection / tune / frame-max / minimum | 在协商 frame-max 之前，双方必须接受最大为 frame-min-size 八位字节的帧，且 frame-max 的最小协商值也是 frame-min-size。 |
| 计划 | 必须 (MUST) | 服务器 | connection / tune-ok / channel-max / upper-limit | 如果客户端指定的通道最大值高于服务器提供的值，服务器必须关闭连接，而不尝试进行协商关闭。服务器可以通过某种方式报告该错误以辅助实现者。 |
| ok | 必须 (MUST) | 服务器 | connection / tune-ok / frame-max / minimum | 在协商 frame-max 之前，双方必须接受最大为 frame-min-size 八位字节的帧，且 frame-max 的最小协商值也是 frame-min-size。 说明： frame-min-size 为 4Kb。 |
| ok | 必须 (MUST) | 服务器 | connection / tune-ok / frame-max / upper-limit | 如果客户端指定的帧最大值高于服务器提供的值，服务器必须关闭连接，而不尝试进行协商关闭。服务器可以通过某种方式报告该错误以辅助实现者。 |
| ok | 必须 (MUST) | 服务器 | connection / open / virtual-host / separation | 如果服务器支持多个虚拟主机，它必须强制执行每个虚拟主机内交换机、队列及所有关联实体的完全隔离。连接到特定虚拟主机的应用程序不得访问另一个虚拟主机的资源。 |
| 执行 | 应该 (SHOULD) | 服务器 | connection / open / virtual-host / security | 服务器应该验证客户端是否有权访问指定的虚拟主机。 |
| ok | 必须 (MUST) | 客户端 | connection / close / stability | 在发送此方法后，除 Close 和 Close-OK 之外收到的任何方法都必须被丢弃。在发送 Close 后收到 Close 的响应必须是发送 Close-Ok。 |
| 执行 | 应该 (SHOULD) | 客户端 | connection / close-ok / reporting | 检测到套接字关闭而未收到 Close-Ok 握手方法的对等方应该记录该错误。 说明： 只有服务器维护错误日志。 |
| ok | 不得 (MUST NOT) | 服务器 | channel / open / state | 客户端不得在已打开的通道上使用此方法。 |
| 不执行 | 可以 (MAY) | 服务器 | channel / flow / initial-state | 当打开一个新通道时，它是处于活动状态（流量开启）的。一些应用程序假定通道在启动前处于非活动状态。为了模拟这种行为，客户端可以打开通道，然后将其暂停。 |
| 不执行 | 应该 (SHOULD) | 服务器 | channel / flow / bidirectional | 发送内容帧时，对等方应该监控通道上的传入方法，并尽可能快地响应 Channel.Flow。 说明： 服务器不支持使用 active=true 阻塞流量。通过 basic.qos 限制预取可提供更好的控制。 |
| ok | 可以 (MAY) | 服务器 | channel / flow / throttling | 对等方可以使用 Channel.Flow 方法因内部原因限制传入的内容数据，例如在较慢的连接上交换数据时。 说明： 服务器和客户端都不会自动发出 Channel.Flow。 |
| 不执行 | 可以 (MAY) | 服务器 | channel / flow / expected-behaviour | 请求 Channel.Flow 方法的对等方可以断开和/或禁止不遵守该请求的对等方。这是为了防止行为不端的客户端压垮服务器。 |
| ok | 必须 (MUST) | 客户端 | channel / close / stability | 在发送此方法后，除 Close 和 Close-OK 之外收到的任何方法都必须被丢弃。在发送 Close 后收到 Close 的响应必须是发送 Close-Ok。 |
| 执行 | 应该 (SHOULD) | 客户端 | channel / close-ok / reporting | 检测到套接字关闭而未收到 Channel.Close-Ok 握手方法的对等方应该记录该错误。 说明： 只有服务器维护错误日志。 |
| ok | 必须 (MUST) | exchange / required-types | 服务器必须实现这些标准交换机类型：fanout、direct。 | |
| 执行 | 应该 (SHOULD) | exchange / recommended-types | 服务器应该实现这些标准交换机类型：topic、headers。 | |
| ok | 必须 (MUST) | exchange / required-instances | 服务器必须在每个虚拟主机中预先声明其实现的每种标准交换机类型的一个实例，如果已定义，交换机实例的名称应为 "amq." 后跟交换机类型名称。 | |
| ok | 必须 (MUST) | exchange / default-exchange | 服务器必须预先声明一个没有公开名称的直接交换机（direct exchange），作为内容 Publish 方法和默认队列绑定的默认交换机。 | |
| ok | 不得 (MUST NOT) | exchange / default-access | 服务器不得允许客户端访问默认交换机，除非在 Queue.Bind 和内容 Publish 方法中指定空交换机名称。 | |
| 执行 | 可以 (MAY) | exchange / extensions | 服务器可以根据需要实现其他交换机类型。 | |
| 执行 | 应该 (SHOULD) | 服务器 | exchange / declare / minimum | 服务器应该支持每个虚拟主机至少 16 个交换机，理想情况下，除了可用资源定义的限制外，不施加任何限制。 |
| ok | 必须 (MUST), 可以 (MAY) | 服务器 | exchange / declare / exchange / reserved | 以 "amq." 开头的交换机名称保留给预先声明和标准化的交换机。如果设置了被动（passive）选项或交换机已经存在，客户端可以声明以 "amq." 开头的交换机。 说明： 服务器不会阻止声明以 "amq." 开头的交换机名称。客户端可以在未设置 passive 位的情况下声明以 "amq." 开头的交换机。 |
| ok | 必须 (MUST) | 服务器 | exchange / declare / exchange / syntax | 交换机名称由非空的字符序列组成：字母、数字、连字符、下划线、句点或冒号。 说明： 服务器不对该词法进行强制限制。 |
| ok | 必须 (MUST) | 服务器 | exchange / declare / type / typed | 交换机不能使用不同的类型重新声明。客户端不得尝试使用与原始 Exchange.Declare 方法中使用的类型不同的类型来重新声明现有交换机。 |
| ok | 不得 (MUST NOT) | 服务器 | exchange / declare / type / support | 客户端不得尝试声明服务器不支持的类型的交换机。 |
| ok | 必须 (MUST) | 服务器 | exchange / declare / passive / not-found | 如果已设置，且交换机尚不存在，服务器必须引发回复代码为 404（未找到）的通道异常。 说明： (指 passive 标志) |
| ok | 必须 (MUST) | 服务器 | exchange / declare / passive / equivalent | 如果未设置且交换机存在，服务器必须检查现有交换机的类型、持久化（durable）和参数（arguments）字段值是否相同。如果请求的交换机与这些字段匹配，服务器必须响应 Declare-Ok，否则必须引发通道异常。 说明： (指 passive 标志) |
| ok | 必须 (MUST) | 服务器 | exchange / declare / durable / support | 服务器必须支持持久化和瞬态交换机。 |
| 失败 | 不得 (MUST NOT) | 服务器 | exchange / delete / exchange / exists | 客户端不得尝试删除不存在的交换机。 说明： 我们将 exchange.delete 设置为一种幂等断言，要求交换机不得存在，这与 exchange.declare 要求交换机必须存在的方式相同。 |
| ok | 不得 (MUST NOT) | 服务器 | exchange / delete / if-unused / in-use | 如果 if-unused 字段为真，服务器不得删除已绑定在此交换机上的交换机。 |
| ok | 必须 (MUST) | 服务器 | queue / declare / default-binding | 服务器必须为新声明的队列创建到默认交换机的默认绑定，该交换机类型为 'direct'，并使用队列名称作为路由键。 |
| 执行 | 应该 (SHOULD) | 服务器 | queue / declare / minimum-queues | 服务器应该支持每个虚拟主机至少 256 个队列，理想情况下，除了可用资源定义的限制外，不施加任何限制。 |
| 执行 | 可以 (MAY), 必须 (MUST) | 服务器 | queue / declare / queue / default-name | 队列名称可以为空，在这种情况下，服务器必须创建一个具有唯一生成名称的新队列，并在 Declare-Ok 方法中将其返回给客户端。 |
| ok | 必须 (MUST) | 服务器 | queue / declare / queue / reserved | 以 "amq." 开头的队列名称保留给预先声明和标准化的队列。如果设置了被动（passive）选项或队列已经存在，客户端可以声明以 "amq." 开头的队列。 说明： 服务器不会阻止声明以 "amq." 开头的队列名称。客户端可以在未设置 passive 位的情况下声明以 "amq." 开头的队列。 |
| 执行 | 可以 (MAY) | 服务器 | queue / declare / queue / syntax | 队列名称可以为空，或者是以下字符的序列：字母、数字、连字符、下划线、句点或冒号。 说明： 服务器不对该词法进行强制限制。 |
| 执行 | 可以 (MAY) | 服务器 | queue / declare / passive / passive | 客户端可以要求服务器断言队列存在，如果不存在则不创建队列。如果队列不存在，服务器将其视为失败。 |
| ok | 必须 (MUST) | 服务器 | queue / declare / passive / equivalent | 如果未设置且队列存在，服务器必须检查现有队列的持久化（durable）、排他（exclusive）、自动删除（auto-delete）和参数（arguments）字段值是否相同。如果请求的队列与这些字段匹配，服务器必须响应 Declare-Ok，否则必须引发通道异常。 说明： (指 passive 标志) |
| ok | 必须 (MUST) | 服务器 | queue / declare / durable / persistence | 服务器必须在重启后重新创建持久化队列。 |
| ok | 必须 (MUST) | 服务器 | queue / declare / durable / types | 服务器必须支持持久化和瞬态队列。 |
| ok | 必须 (MUST) | 服务器 | queue / declare / exclusive / types | 服务器必须支持排他（私有）和非排他（共享）队列。 |
| 不执行 | 不可以 (MAY NOT) | 服务器 | queue / declare / exclusive / exclusive | 客户端不可以尝试使用由另一个仍处于开启状态的连接声明为排他的队列。 |
| ok | 必须 (MUST) | 服务器 | queue / declare / auto-delete / pre-existence | 如果队列已经存在，服务器必须忽略 auto-delete 字段。 |
| ok | 必须 (MUST) | 服务器 | queue / bind / duplicates | 服务器必须允许忽略重复绑定，即针对特定队列具有相同参数的两个或多个 bind 方法，而不将其视为错误。 |
| ok | 不得 (MUST NOT) | 服务器 | queue / bind / unique | 服务器不得向队列投递同一消息多次，即使队列具有多个匹配该消息的绑定。 |
| ok | 必须 (MUST) | 服务器 | queue / bind / transient-exchange | 服务器必须允许持久化队列绑定到瞬态交换机。 |
| ok | 必须 (MUST) | 服务器 | queue / bind / durable-exchange | 持久化队列到持久化交换机的绑定自动具有持久性，服务器必须在服务器重启后恢复此类绑定。 |
| 执行 | 应该 (SHOULD) | 服务器 | queue / bind / binding-count | 服务器应该支持每个队列至少 4 个绑定，理想情况下，除了可用资源定义的限制外，不施加任何限制。 |
| ok | 必须 (MUST) | 服务器 | queue / bind / queue / queue-known | 客户端必须指定队列名称，或者之前已在同一通道上声明了队列。 |
| ok | 不得 (MUST NOT) | 服务器 | queue / bind / queue / must-exist | 客户端不得尝试绑定不存在的队列。 |
| ok | 不得 (MUST NOT) | 服务器 | queue / bind / exchange / exchange-existence | 不得允许客户端将队列绑定到不存在的交换机。 |
| 不执行 | 必须 (MUST) | 服务器 | queue / bind / exchange / default-exchange | 服务器必须接受空白交换机名称以表示默认交换机。 |
| ok | 必须 (MUST) | 服务器 | queue / bind / routing-key / direct-exchange-key-matching | 如果消息队列使用路由键 K 绑定到直接交换机（direct exchange），且发布者向该交换机发送了路由键为 R 的消息，那么如果 K = R，消息必须被发送到该消息队列。 |
| ok | 必须 (MUST) | 服务器 | queue / unbind / 01 | 如果解绑失败，服务器必须引发连接异常。 |
| ok | 必须 (MUST) | 服务器 | queue / unbind / queue / queue-known | 客户端必须指定队列名称，或者之前已在同一通道上声明了队列。 |
| 失败 | 不得 (MUST NOT) | 服务器 | queue / unbind / queue / must-exist | 客户端不得尝试解绑不存在的队列。 说明： 我们将 queue.unbind 设置为一种幂等断言，要求绑定不得存在，这与 queue.bind 要求绑定必须存在的方式相同。 |
| 失败 | 不得 (MUST NOT) | 服务器 | queue / unbind / exchange / must-exist | 客户端不得尝试将队列从不存在的交换机解绑。 说明： 我们将 queue.unbind 设置为一种幂等断言，要求绑定不得存在，这与 queue.bind 要求绑定必须存在的方式相同。 |
| 不执行 | 必须 (MUST) | 服务器 | queue / unbind / exchange / default-exchange | 服务器必须接受空白交换机名称以表示默认交换机。 |
| ok | 不得 (MUST NOT) | 服务器 | queue / purge / 02 | 服务器不得清除已发送给客户端但尚未确认的消息。 |
| 不执行 | 可以 (MAY) | 服务器 | queue / purge / 03 | 服务器可以实现清除队列或日志，允许系统管理员恢复被意外清除的消息。服务器不应将清除的消息保存在与存活消息相同的存储空间中，因为清除消息的量可能会非常大。 |
| ok | 必须 (MUST) | 服务器 | queue / purge / queue / queue-known | 客户端必须指定队列名称，或者之前已在同一通道上声明了队列。 |
| ok | 不得 (MUST NOT) | 服务器 | queue / purge / queue / must-exist | 客户端不得尝试清除不存在的队列。 |
| 不执行 | 应该 (SHOULD) | 服务器 | queue / delete / 01 | 服务器应该使用死信队列来保存已删除队列上挂起的消息，并可以提供设施供系统管理员将这些消息移回活动队列。 |
| ok | 必须 (MUST) | 服务器 | queue / delete / queue / queue-known | 客户端必须指定队列名称，或者之前已在同一通道上声明了队列。 |
| 失败 | 不得 (MUST NOT) | 服务器 | queue / delete / queue / must-exist | 客户端不得尝试删除不存在的队列。 说明： 我们将 queue.delete 设置为一种幂等断言，要求队列不得存在，这与 queue.declare 要求队列必须存在的方式相同。 |
| ok | 不得 (MUST NOT) | 服务器 | queue / delete / if-unused / in-use | 如果 if-unused 字段为真，服务器不得删除已有消费者的队列。 |
| ok | 不得 (MUST NOT) | 服务器 | queue / delete / if-empty / not-empty | 如果 if-empty 字段为真，服务器不得删除仍有消息的队列。 |
| 执行 | 应该 (SHOULD) | basic / 01 | 服务器应该尊重基本消息的持久属性，并应尽最大努力将持久化基本消息保存在可靠的存储机制上。 | |
| ok | 不得 (MUST NOT) | basic / 02 | 在队列溢出的情况下，服务器不得丢弃持久化基本消息。 | |
| 不执行 | 可以 (MAY) | basic / 03 | 服务器可以在必要时使用 Channel.Flow 方法减慢或停止基本消息发布者。 | |
| 执行 | 可以 (MAY) | basic / 04 | 服务器可以将非持久化基本消息溢出到持久存储中。 | |
| 不执行 | 可以 (MAY) | basic / 05 | 如果队列大小超过某些配置的限制，服务器可以基于优先级丢弃或将非持久化基本消息转入死信队列。 | |
| 计划 | 必须 (MUST) | basic / 06 | 服务器必须为基本消息实现至少 2 个优先级级别，其中 0-4 和 5-9 的优先级被视为两个不同的级别。 | |
| 不执行 | 可以 (MAY) | basic / 07 | 服务器可以实现最多 10 个优先级级别。 | |
| ok | 必须 (MUST) | basic / 08 | 服务器必须按顺序投递相同优先级的消息，无论它们各自的持久性如何。 | |
| ok | 必须 (MUST) | basic / 09 | 服务器必须支持基本内容的未经确认的投递，即 no-ack 字段设置为 TRUE 的消费者。 | |
| ok | 必须 (MUST) | basic / 10 | 服务器必须支持基本内容的明确确认投递，即 no-ack 字段设置为 FALSE 的消费者。 | |
| ok | 必须 (MUST) | 服务器 | basic / qos / prefetch-size / 01 | 当客户端未处理任何消息时，服务器必须忽略此设置——即预取大小不会限制将单条消息传输给客户端，而仅限制在客户端仍有一条或多条未确认消息时提前发送更多消息。 说明： (指 prefetch-size) |
| ok | 不得 (MUST NOT) | 服务器 | basic / qos / prefetch-count / 01 | 服务器发送的数据量可以少于客户端指定的预取窗口允许的数据量，但不得超过该量。 |
| 执行 | 应该 (SHOULD) | 服务器 | basic / consume / 01 | 服务器应该支持每个队列至少 16 个消费者，理想情况下，除了可用资源定义的限制外，不施加任何限制。 |
| ok | 不得 (MUST NOT) | 服务器 | basic / consume / consumer-tag / 01 | 客户端不得指定指向现有消费者的标签。 |
| ok | 必须 (MUST) | 服务器 | basic / consume / consumer-tag / 02 | 消费者标签仅在创建该消费者的通道内有效。即，客户端不得在一个通道中创建消费者，然后在另一个通道中使用它。 |
| 不执行 | 不可以 (MAY NOT) | 服务器 | basic / consume / exclusive / 01 | 客户端不可以对已有活跃消费者的队列获得排他访问权限。 |
| ok | 必须 (MUST) | 服务器 | basic / cancel / 01 | 如果队列不存在，只要该消费者标签对该通道有效，服务器就必须忽略 cancel 方法。 |
| ok | 不得 (MUST NOT) | 服务器 | basic / publish / exchange / must-exist | 客户端不得尝试将内容发布到不存在的交换机。 |
| ok | 必须 (MUST) | 服务器 | basic / publish / exchange / default-exchange | 服务器必须接受空白交换机名称以表示默认交换机。 |
| ok | 必须 (MUST) | 服务器 | basic / publish / exchange / 02 | 如果交换机被声明为内部交换机，服务器必须引发回复代码为 403（访问被拒绝）的通道异常。 |
| 不执行 | 可以 (MAY) | 服务器 | basic / publish / exchange / 03 | 交换机可以拒绝基本内容，在这种情况下，它必须引发回复代码为 540（未实现）的通道异常。 |
| 执行 | 应该 (SHOULD) | 服务器 | basic / publish / mandatory / 01 | 服务器应该实现 mandatory 标志。 |
| 不执行 | 应该 (SHOULD) | 服务器 | basic / publish / immediate / 01 | 服务器应该实现 immediate 标志。 说明： 服务器不支持 immediate 标志。消息 TTL 为 0 提供了替代方案。 |
| 计划 | 应该 (SHOULD) | 客户端 | basic / deliver / 01 | 服务器应该追踪消息向客户端投递的次数。当消息在未被确认的情况下被重新投递一定次数（例如 5 次）时，服务器应该认为该消息不可处理（可能导致客户端应用程序中止），并将其移至死信队列。 |
| ok | 必须 (MUST) | 服务器 | basic / ack / multiple / exists | 服务器必须验证非零的投递标签（delivery-tag）是否指向已投递的消息，如果不是，则引发通道异常。在事务通道上，此检查必须立即完成，不得延迟到 Tx.Commit。具体来说，客户端不得确认同一消息多次。 |
| 计划 | 应该 (SHOULD) | 服务器 | basic / reject / 01 | 服务器应该能够在发送 Deliver 或 Get-Ok 方法内容的同时接受并处理 Reject 方法。即，服务器应在发送输出帧时读取并处理传入的方法。要取消部分发送的内容，服务器会发送大小为 1 的内容体帧（即除了帧结束八位字节外没有数据）。 |
| ok | 应该 (SHOULD) | 服务器 | basic / reject / 02 | 服务器应该将此方法解释为客户端当前无法处理该消息。 |
| ok | 不得 (MUST NOT) | 服务器 | basic / reject / 03 | 客户端不得将此方法用作选择处理哪些消息的手段。 |
| 计划 | 不得 (MUST NOT) | 服务器 | basic / reject / requeue / 01 | 服务器不得在当前通道上下文中将消息投递给同一客户端。建议的策略是尝试将消息投递给备用消费者，如果不可能，则将消息移至死信队列。服务器可以使用更复杂的追踪方式将消息保留在队列中，并在稍后阶段将其重新投递给同一客户端。 |
| ok | 必须 (MUST) | 服务器 | basic / recover-async / 01 | 服务器必须在所有重新发送的消息上设置 redelivered 标志。 |
| ok | 必须 (MUST) | 服务器 | basic / recover / 01 | 服务器必须在所有重新发送的消息上设置 redelivered 标志。 |
| ok | 不得 (MUST NOT) | tx / not multiple queues | 应用程序不得依赖影响多个队列的事务的原子性。 | |
| ok | 不得 (MUST NOT) | tx / not immediate | 应用程序不得依赖包含以 immediate 选项发布的消息的事务行为。 | |
| ok | 不得 (MUST NOT) | tx / not mandatory | 应用程序不得依赖包含以 mandatory 选项发布的消息的事务行为。 | |
| ok | 不得 (MUST NOT) | 服务器 | tx / commit / transacted | 客户端不得在非事务通道上使用 Commit 方法。 |
| ok | 不得 (MUST NOT) | 服务器 | tx / rollback / transacted | 客户端不得在非事务通道上使用 Rollback 方法。 |
来自 AMQP 0-9-1 版本规范的规则 (PDF)
下文列出的规则来自 0-9-1 规范的 PDF 版本，凡文中出现“必须 (MUST)”、“应该 (SHOULD)”或“可以 (MAY)”的地方。
| 当前状态 | 类型 | 角色 | 参考 | 文本 |
|---|---|---|---|---|
| 执行，不执行 | 应该 (SHOULD), 应该 (SHOULD) | 1.4.1 | 协议常量显示为大写名称。AMQP 实现应该在源代码和文档中定义和使用常量时使用这些名称。属性名称、方法参数和帧字段显示为小写名称。AMQP 实现应该在源代码和文档中一致地使用这些名称。 说明： 在某些上下文中，属性名称、方法参数和帧字段会以驼峰式显示，这是合法的。 | |
| ok | 必须 (MUST) | 2.2.4 | 对于未完全开启的连接，没有关于错误的握手。在成功协商协议头后，[...] 以及在发送或接收 Open 或 Open-Ok 之前，检测到错误的对等方必须关闭套接字，而不发送任何进一步的数据。 | |
| 执行 | 可以 (MAY) | 2.3.3 | 服务器可以在同一端口上托管多个协议。 说明： 服务器在同一端口上支持 0-8、0-9 和 0-9-1。 | |
| 不执行 | 可以 (MAY) | 2.3.3 | 商定的限制可以使双方预先分配关键缓冲区，避免死锁。 | |
| ok | 必须 (MUST) | 2.3.3 | 每个传入帧要么遵守商定的限制（即“安全”），要么超过限制，在这种情况下，另一方即为故障，必须被断开连接。 | |
| ok | 必须 (MUST) | 2.3.3 | 服务器必须告知客户端其提议的限制。 | |
| 不执行 | 可以 (MAY) | 2.3.3 | 客户端进行响应，并且可以为该连接降低这些限制。 | |
| 执行 | 可以 (MAY) | 2.3.5.2 | 数据 [对于内容帧] 可以是任何大小，并且可以分解成多个（或许多）块，每个块形成一个“内容体帧”。 | |
| ok | 必须 (MUST), 必须 (MUST) | 2.3.7 | 连接或通道对于客户端来说，在发送 Open 时被视为“开启”；对于服务器来说，在发送 Open-Ok 时被视为“开启”。从这一点开始，希望关闭通道或连接的对等方必须使用握手协议 [...] 来执行此操作。当对等方决定关闭通道或连接时，它会发送一个 Close 方法。接收方的对等方必须以 Close-Ok 响应 Close，然后双方都可以关闭它们的通道或连接。 | |
| 执行 | 不得 (MUST NOT), 不得 (MUST NOT) | 3.1.1 | 服务器不得修改其接收并传递给消费者应用程序的消息内容体。[...] [服务器] 不得删除或修改现有信息。 说明： 路由后，“BCC”头会从属性中删除。 | |
| 不执行 | 可以 (MAY) | 3.1.1 | 服务器可以将信息添加到内容头中 [...] | |
| ok | 必须 (MUST) | 3.1.2 | 每个连接必须与单个虚拟主机相关联。 | |
| 不执行 | 可以 (MAY) | 3.1.2 | [所]使用的授权方案可能对每个虚拟主机都是唯一的。 | |
| ok | 必须 (MUST), 必须 (MUST) | 3.1.3.1 | 服务器必须实现直接交换机类型，并且必须在每个虚拟主机内预先声明至少两个直接交换机：一个命名为 amq.direct，另一个没有公开名称，作为 Publish 方法的默认交换机。[...] [所有]消息队列必须自动绑定到该无名交换机，使用消息队列的名称作为路由键。 | |
| ok | 必须 (MUST) | 3.1.3.3 | 主题交换机（topic exchange）使用的路由键必须由零个或多个以点分隔的单词组成。 | |
| 执行，ok | 应该 (SHOULD), 必须 (MUST) | 3.1.3.3 | 服务器应该实现主题交换机类型，在这种情况下，服务器必须在每个虚拟主机内预先声明至少一个名为 amq.topic 的主题交换机。 | |
| 执行，ok | 应该 (SHOULD), 必须 (MUST) | 3.1.3.4 | 服务器应该实现头部交换机类型（headers exchange），在这种情况下，服务器必须在每个虚拟主机内预先声明至少一个名为 amq.match 的头部交换机。 | |
| ok | 必须 (MUST) | 3.1.3.4 | 所有非规范交换机类型必须以 "x-" 开头命名。 | |
| 执行 | 不可以 (MAY NOT) | 3.1.4 | 请注意，在存在从队列进行多读取者、客户端事务、使用优先级字段、使用消息选择器或特定于实现的投递优化的情况下，队列可能不表现出真正的 FIFO 特性。 说明： FIFO 特性在第 4.7 节指定的条件下得到保证。 | |
| ok | 必须 (MUST) | 3.1.10 | 服务器和客户端必须遵守 [指定的命名] 约定 | |
| 执行 | 应该 (SHOULD) | 3.2.1 | 出于互操作性原因，AMQP 方法可能定义特定的最小值（例如每个消息队列的消费者数量）。这些最小值在每个类的描述中定义。符合要求的 AMQP 实现应该为这些字段实现相当宽松的值，这些最小值仅旨在用于性能最差的平台。 | |
| 执行，不执行 | 应该 (SHOULD), 可以 (MAY) | 3.2.1 | 发送方应该等待 [发送同步请求后] 的特定回复方法，但可以异步实现此操作 | |
| ok | 必须 (MUST) | 4.2.2 | 客户端必须通过发送协议头来启动新连接。 | |
| 不执行 | 可以 (MAY) | 4.2.2 | 服务器可以接受非 AMQP 协议（如 HTTP）。 说明： 核心代理仅接受 AMQP。存在用于其他协议的插件。 | |
| ok | 必须 (MUST) | 4.2.2 | 如果服务器无法识别套接字上的前 5 个八位字节数据，或不支持客户端请求的特定协议版本，则必须向套接字写入有效的协议头，然后刷新套接字（以确保客户端应用程序将收到数据），然后关闭套接字连接。 | |
| 执行 | 可以 (MAY) | 4.2.2 | 服务器可以在 [协议协商失败期间] 打印诊断消息以辅助调试。 说明： 相关信息将写入服务器日志。 | |
| 不执行 | 可以 (MAY) | 4.2.2 | 客户端可以通过尝试用其支持的最高版本连接，并在从服务器收回此类信息时改用较低版本重新连接来检测服务器协议版本。 | |
| ok | 必须 (MUST) | 4.2.3 | 帧结束八位字节必须始终为十六进制值 %xCE。 | |
| ok | 必须 (MUST), 必须 (MUST), 必须 (MUST) | 4.2.3 | 如果对等方接收到的帧类型不是这些定义的类型之一，则必须将其视为致命协议错误，并关闭连接，而不发送任何进一步的数据。当对等方读取帧时，必须在尝试解码该帧之前检查帧结束符是否有效。如果帧结束符无效，则必须将其视为致命协议错误，并关闭连接，而不发送任何进一步的数据。 | |
| 执行 | 应该 (SHOULD) | 4.2.3 | 它应该记录关于 [帧解码] 问题的相关信息，因为这表明服务器或客户端的帧代码实现存在错误。 | |
| ok | 不得 (MUST NOT), 必须 (MUST), 必须 (MUST), 必须 (MUST), 必须 (MUST) | 4.2.3 | 对等方不得发送大于商定尺寸的帧。接收到超大帧的对等方必须发送回复代码为 501（帧错误）的连接异常。所有心跳帧的通道编号必须为零，对于引用 Connection 类的帧（方法、头和体帧）也是如此。接收到这些帧之一的非零通道编号的对等方必须发送回复代码为 503（命令无效）的连接异常。 | |
| ok | 不得 (MUST NOT) | 4.2.5.1 | 实现者不得假设帧中编码的整数在内存字边界上对齐。 | |
| ok | 必须 (MUST) | 4.2.5.5 | 字段名称必须以字母、“$”或“#”开头 [...] | |
| 不执行, 不执行 | 应该 (SHOULD), 应该 (SHOULD) | 4.2.5.5 | 服务器应该验证字段名称，在收到无效的字段名称时，应该发送回复代码为 503（语法错误）的连接异常。 | |
| 计划 | 必须 (MUST) | 4.2.6 | 接收到不完整或格式错误内容的对等方必须引发回复代码为 505（意外帧）的连接异常。 说明： 对于内容格式错误的所有可能方式，并非都会返回给定的回复代码。 | |
| ok | 必须 (MUST), 必须 (MUST) | 4.2.6.1 | 内容头的 class-id 必须与方法帧的 class-id 匹配。对等方必须通过引发回复代码为 501（帧错误）的连接异常来响应无效的 class-id。 | |
| ok | 不得 (MUST NOT), 必须 (MUST) | 4.2.6.1 | 内容帧中的通道编号不得为零。接收到内容帧中零通道编号的对等方必须发送回复代码为 504（通道错误）的连接异常。 | |
| ok | 必须 (MUST) | 4.2.6.2 | 对等方必须通过将这些帧存储为单个集合来处理拆分为多个帧的内容体，并将其按原样重新传输、拆分为更小的帧，或连接成单个块以传递给应用程序。 | |
| ok | 必须 (MUST) | 4.2.6.2 | 心跳帧必须具有零的通道编号。 | |
| ok | 必须 (MUST) | 4.2.7 | 如果对等方不支持心跳，则必须丢弃心跳帧，而不发送任何错误或故障。 说明： 代理和受支持的客户端确实支持心跳帧。 | |
| 执行，不执行 | 可以 (MAY), 可以 (MAY) | 4.3 | AMQP 对等方可以支持多个通道。最大通道数在连接协商时定义，对等方可以将此数值协商低至 1。 | |
| 执行，不执行 | 应该 (SHOULD), 不应该 (SHOULD NOT) | 4.3 | 每个对等方应该以公平的方式平衡所有开放通道上的流量。这种平衡可以在每个帧的基础上完成，也可以基于每个通道的流量量来完成。对等方不应该允许一个非常繁忙的通道使较不繁忙的通道的进展受到挤压。 | |
| ok | 不得 (MUST NOT), 必须 (MUST) | 4.6 | 请求-响应的效果在响应方法之前不得在通道上可见，在此之后必须可见。 | |
| ok | 必须 (MUST) | 4.7 | 服务器必须保留流经单个内容处理路径的内容顺序，除非在 Basic.Deliver 或 Basic.Get-Ok 方法上设置了 redelivered 字段，并根据管理该字段设置条件的规则。 说明： 代理做出了更强的保证。 | |
| 执行 | 应该 (SHOULD) | 4.10.2 | 服务器应该记录 [连接协商阶段的所有异常]，并标记或阻止导致多次失败的客户端。 |
已弃用的类
以下类在 0-9-1 版本中已弃用。RabbitMQ 完全没有实现这些类，即使在代理连接到 0-8 客户端或 .NET 客户端配置为使用 0-8 时也是如此。
- access
- dtx
- file
- stream
- test
- tunnel
另请参阅下方的详细规范兼容性表格。
获取帮助和提供反馈
如果您对本指南的内容或与 RabbitMQ 相关的任何其他主题有疑问，请随时通过 GitHub Discussions 或我们的社区 Discord 服务器 提问。