RabbitMQ AMQP.基本属性。生成器值

通常我用非常简单的方法来记忆一些东西。我将在下面提供所有详细信息，但这里是BasicProperties字段和值的简单图片。我还尝试正确突出显示队列/服务器和应用程序上下文。

如果你想让我增强一点 - 只需删除一个小评论。我真正想要的是提供一些视觉键并简化理解。

高级描述（源 1、源 2）：

请注意，Clust ID 已被弃用，因此我将将其排除在外。

• 应用程序 ID - 生成消息的应用程序的标识符。
  • 上下文：应用程序使用
  • 值：可以是任何字符串。
• 内容编码 - 消息内容编码
  • 上下文：应用程序使用
  • 值：MIME 内容编码（例如 gzip）
• 内容类型 - 消息内容类型
  • 上下文：应用程序使用
  • 值：MIME 内容类型（例如 application/json）
• 相关 ID - 与此消息相关的消息，例如，此消息是对哪个请求的回复。鼓励应用程序使用此属性，而不是将此信息放入消息负载中。
  • 上下文：应用程序使用
  • 值：任何值
• 传递模式 - 是否应将邮件保存到磁盘？
  • 上下文：队列实现使用
  • 值：非持久性 （1） 或持久性 （2）
• 过期 - 过期时间，在此时间之后将删除邮件。过期字段的值描述 TTL 周期（以毫秒为单位）。请参阅以下详细信息。
  • 上下文：队列实现使用
• 标头 - 任意特定于应用程序的消息标头。
  • 上下文：应用程序使用
• 消息 ID - 字符串形式的消息标识符。如果应用程序需要标识消息，则建议它们使用此属性，而不是将其放入消息负载中。
  • 上下文：应用程序使用
  • 值：任何值
• 优先级 - 消息优先级。
  • 上下文：队列实现使用
  • 值：0 到 9
• 回复到 - 其他应用应将响应发送到的队列名称。通常用于命名应答队列（或帮助使用者应用程序定向其响应的任何其他标识符）。鼓励应用程序使用此属性，而不是将此信息放入消息负载中。
  • 上下文：应用程序使用
  • 值：任何值
• 时间戳 - 发送消息时刻的时间戳。
  • 上下文：应用程序使用
  • 值：自纪元以来的秒数。
• 类型 - 消息类型，例如，此消息表示的事件或命令的类型。建议由应用程序使用，而不是将此信息包含在消息负载中。
  • 上下文：应用程序使用
  • 值：可以是任何字符串。
• 用户 ID - 可选用户 ID。由 RabbitMQ 根据实际连接用户名进行验证。
  • 上下文：队列实现使用
  • 值：应为经过身份验证的用户。

顺便说一句，我终于设法回顾了最新的服务器代码（rabbitmq-server-3.1.5），rabbit_stomp_test_util.erl中有一个例子：

                content_type     = <<"text/plain">>,
                content_encoding = <<"UTF-8">>,
                delivery_mode    = 2,
                priority         = 1,
                correlation_id   = <<"123">>,
                reply_to         = <<"something">>,
                expiration       = <<"my-expiration">>,
                message_id       = <<"M123">>,
                timestamp        = 123456,
                type             = <<"freshly-squeezed">>,
                user_id          = <<"joe">>,
                app_id           = <<"joe's app">>,
                headers          = [{<<"str">>, longstr, <<"foo">>},
                                    {<<"int">>, longstr, <<"123">>}]

很高兴知道有人想知道所有的细节。因为最好尽可能使用已知的消息属性，而不是将信息放在消息正文中。顺便说一句，基本消息属性远非清晰和有用。我会说最好使用自定义的。

好的例子（源)

更新 - 过期字段

重要提示：过期属于队列上下文。因此，服务器可能会丢弃邮件。

自述文件是这样说的：

expiration是一个短字符串;由于 RabbitMQ 期望这是一个编码的字符串，因此我们将 a 转换为其整数值的字符串表示形式。ttl

来源：

• 其他来源 1
• 其他来源 2

在撰写本文时：

1. 最新的AMQP标准是AMQP 1.0 OASIS标准。
2. RabbitMQ的最新版本是3.1.5（服务器和客户端），它声称支持AMQP 0.9.1（pdf和XML架构压缩）。
3. RabbitMQ以XML模式的形式提供自己的协议描述，包括扩展（即非标准），以及没有扩展的XML模式（与通过（2）链接的模式相同）和pdf文档。

在这个答案中：

• （3）中的链接是详细信息的主要来源
• （2） 如果 （3） 不充分，则将 pdf 文档用作次要详细信息
• 如果（2）不充分，源代码（java客户端，erlang服务器）将用作第三级详细信息。
• （1）通常不使用 - 协议和模式已经（公平地）为OASIS/由OASIS显着发展，应该适用于RabbitMQ的未来版本，但现在不适用。使用（1）的两个例外是用于和的文本描述 - 这是安全的，因为这些是AMQP 1.0中具有良好描述的标准字段。contentTypecontentEncoding

以下文本由我从这些来源转述，以使其更加简洁或清晰。

• content-type （AMQP XML type=“shortstr”; java type=“String”）： 可选。邮件的应用程序数据部分（正文）的 RFC-2046 MIME 类型。可以包含定义所用字符编码的字符集参数：例如，'text/plain;charset=“utf-8”'.如果内容类型未知，则不应设置内容类型，从而允许收件人确定实际类型。如果已知该部分是真正不透明的二进制数据，则内容类型应设置为应用程序/八位字节流。
• content-encoding （AMQP XML type=“shortstr”; java type=“String”）： 可选。如果存在，则描述应用于应用程序数据的附加内容编码，以及因此需要应用哪些解码机制才能获得内容类型标头字段引用的媒体类型。主要用于允许在不丢失其基础内容类型标识的情况下压缩文档。内容类型的修饰符，根据 RFC 2616 的第 3.5 节进行解释。有效的内容编码在 IANA 注册。实现不应使用压缩编码，除非与最初使用其他协议（例如HTTP或SMTP）发送的消息保持兼容。实现不应指定多个内容编码值，除非与最初使用其他协议（例如 HTTP 或 SMTP）发送的消息兼容。
• headers （AMQP XML type=“table”; java type=“Map”）： 可选。应用程序指定的标头参数及其值的列表。这些设置可能仅用于应用程序。此外，还可以创建具有“标头交换类型”的队列 - 当创建队列时，会为其指定一系列要匹配的标头属性名称，每个名称都具有要匹配的可选值，以便通过标头匹配路由到此队列。
• deliveryMode （RabbitMQ XML type=“octet”; java type=“Integer”）： 1 （non-persistent） or 2 （persistent）.仅适用于实现持久性的队列。持久消息安全地保存在磁盘上，即使出现严重的网络故障，服务器崩溃，溢出等，也保证传递。
• 优先级（AMQP XML type=“octet”; java type=“Integer”）：相对消息优先级（0 到 9）。高优先级消息是 [MAY BE?? - GB] 在同一消息队列中等待的低优先级消息之前发送。当必须丢弃消息以保持特定的服务质量级别时，服务器将首先丢弃低优先级消息。仅适用于实现优先级的队列。
• correlation-id （AMQP XML type=“octet”; java type=“String”）： 可选。对于应用程序使用，没有正式的（RabbitMQ）行为。客户端特定的 ID，可用于标记或标识客户端之间的消息。
• replyTo （AMQP XML type=“shortstr”; java type=“String”）： 可选。对于应用程序使用，没有正式的 （RabbitMQ） 行为，但在请求消息中使用时，可以保存私有响应队列的名称。要向其发送答复的节点的地址。
• 过期 （AMQP XML type=“shortstr”; java type=“String”）： 可选。RabbitMQ AMQP 0.9.1 模式来自 （3） 声明“对于实现使用，没有正式的行为”。来自 （2） 的 AMQP 0.9.1 架构 pdf 声明了此消息被视为已过期的绝对时间。但是，必须忽略这两个说明，因为此 TTL 链接和客户端/服务器代码指示以下内容为真。从客户端，只能通过基本属性的自定义应用程序初始化来填充过期时间。在服务器上，这用于在排队之前从服务器接收消息的位置确定 TTL。服务器选择 TTL 作为 （1） 条消息 TTL（客户端基本属性过期作为相对时间（以毫秒为单位）和 （2） 队列 TTL（以毫秒为单位配置的 x-message-ttl）的最小值。格式：字符串引号整数表示毫秒数;从服务器接收到的消息到期的时间。
• message-id （AMQP XML type=“shortstr”; java type=“String”）： 可选。对于应用程序使用，没有正式的（RabbitMQ）行为。如果设置，消息创建器应将其设置为全局唯一值。将来 （AMQP 1.0），如果 message-id 的值与以前接收到发送到同一节点的消息的值匹配，则代理可能会将消息作为副本丢弃。
• timestamp （AMQP XML type=“timestamp”; java type=“java.util.Date”）： 可选。对于应用程序使用，没有正式的（RabbitMQ）行为。创建此消息的绝对时间。
• type （AMQP XML type=“shortstr”; java type=“String”）： 可选。对于应用程序使用，没有正式的（RabbitMQ）行为。[将消息描述为属于/属于特定于应用程序的“类型”或“窗体”或“业务事务” - GB]
• userId （AMQP XML type=“shortstr”; java type=“String”）： 可选。XML Schema声明“对于应用程序使用，没有正式的（RabbitMQ）行为” - 但我相信这在最新版本中已经改变（继续阅读）。如果设置，客户端将此值设置为负责生成消息的用户的标识。来自 RabbitMQ：如果此属性由发布者设置，则其值必须等于用于打开连接的用户的名称（即进行验证以确保它是已连接/经过身份验证的用户）。如果未设置 user-id 属性，则发布者的标识将保持私有。
• appId （RabbitMQ XML type=“shortstr”; java type=“String”）： Optional.对于应用程序使用，没有正式的（RabbitMQ）行为。创建应用程序 ID。可以由生产者填充，也可以由消费者读取。（看看R-MQ服务器代码，服务器根本不使用它，尽管“webmachine-wrapper”插件提供了一个脚本和匹配的模板来创建Webmachine - 管理员可以为脚本提供一个appId。
• cluster Id （RabbitMQ XML type=“N/A”; java type=“String”）： 在 AMQP 0.9.1 中已弃用 - 即未使用。在以前的版本中，是群集内路由标识符，供群集应用程序使用，客户端应用程序不应使用（即不填充）。但是，这已被弃用并从当前模式中删除，并且不由 R-MQ 服务器代码使用。

如上所示，这些属性中的绝大多数没有枚举/约束/推荐值，因为它们是“仅应用程序使用”并且不被 RabbitMQ 使用。所以你有一份轻松的工作。您可以自由写入/读取对应用程序有用的值 - 只要它们与数据类型匹配并编译:)。 并按照标准的HTTP使用。 并且是受约束的数字。ContentTypecontentEncodingDeliveryModepriority

注意：AMQP 的常用但简单的常量。基本属性在“消息属性”类中可用。

干杯:)

更新到帖子：

非常感谢 Renat（参见注释），查看了 rabbit_amqqueue_process.erl 中的 erlang 服务器代码和 RabbitMQ TTL 扩展到 AMQP 的文档。可以指定消息过期时间（生存时间）

• 每个队列通过以下方式：

  Map<String, Object> args = new HashMap<String, Object>();
  args.put("x-message-ttl", 60000);
  channel.queueDeclare("myqueue", false, false, false, args);
  

• 或每条消息通过以下方式：

  byte[] messageBodyBytes = "Hello, world!".getBytes();
  AMQP.BasicProperties properties = new AMQP.BasicProperties();
  properties.setExpiration("60000");
  channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);
  

在这里，ttl/过期时间以毫秒为单位，因此每种情况下为60秒。更新了上述过期定义以反映这一点。