Значения RabbitMQ AMQP.BasicProperties.Builder

Ответ 1

Обычно я использую очень простой подход к запоминанию. Я приведу все подробности ниже, но вот простая картина поля и значений BasicProperties. Я также попытался правильно выделить контекст очереди/сервера и приложения.

Если вы хотите, чтобы я немного его улучшил - просто напишите небольшой комментарий. Я действительно хочу предоставить некоторый визуальный ключ и упростить понимание.

Описание высокого уровня (источник 1, источник 2):

Обратите внимание, что идентификатор Clust устарел, поэтому я исключу его.

• Идентификатор приложения. Идентификатор приложения, создавшего сообщение.
  • Контекст: использование приложения
  • Значение: может быть любая строка.
• Кодировка содержимого - кодировка содержимого сообщения
  • Контекст: использование приложения
  • Значение: кодирование содержимого MIME (например, application/json)
• Тип содержимого. Тип содержимого сообщения.
  • Контекст: использование приложения
  • Значение: тип содержимого MIME (например, gzip)
• Идентификатор корреляции. Сообщение коррелирует с этим, например. на что запрос это сообщение является ответом. Приложению рекомендуется использовать этот атрибут вместо того, чтобы помещать эту информацию в полезную нагрузку сообщения.
  • Контекст: использование приложения
  • Значение: любое значение
• Режим доставки. Должно ли сообщение сохраняться на диске?
  • Контекст: использование очереди в очереди
  • Значение: непостоянное (1) или постоянное (2)
• Истечение срока действия. - Время истечения срока действия, после которого сообщение будет удалено. Значение поля expiration описывает период TTL в миллисекундах. Подробнее см. Ниже.
  • Контекст: использование очереди в очереди
• Заголовки - произвольные заголовки сообщений приложений.
  • Контекст: использование приложения
• Идентификатор сообщения. Идентификатор сообщения в виде строки. Если приложениям необходимо идентифицировать сообщения, рекомендуется использовать этот атрибут вместо того, чтобы помещать его в полезную нагрузку сообщения.
  • Контекст: использование приложения
  • Значение: любое значение
• Приоритет. Приоритет сообщений.
  • Контекст: использование очереди в очереди
  • Значения: от 0 до 9
• ReplyTo - имя очереди другим приложениям следует отправить ответ. Обычно используется для обозначения очереди ответа (или любого другого идентификатора, который помогает потребительскому приложению направлять ответ). Приложению рекомендуется использовать этот атрибут вместо того, чтобы помещать эту информацию в полезную нагрузку сообщения.
  • Контекст: использование приложения
  • Значение: любое значение
• Отметка времени. Временная метка момента отправки сообщения.
  • Контекст: использование приложения
  • Значение: секунды с эпохи.
• Тип. Тип сообщения, например. какой тип события или команда это сообщение представляет. Рекомендуется использовать приложения вместо того, чтобы включать эту информацию в полезную нагрузку сообщения.
  • Контекст: использование приложения
  • Значение: может быть любая строка.
• Идентификатор пользователя. Дополнительный идентификатор пользователя. Проверено 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 app">>,
                headers          = [{<<"str">>, longstr, <<"foo">>},
                                    {<<"int">>, longstr, <<"123">>}]

Хорошо знать, что кто-то хочет знать все подробности. Потому что гораздо лучше использовать известные атрибуты сообщений, когда это возможно, вместо размещения информации в теле сообщения. Кстати, базовые свойства сообщений далеки от ясности и полезности. Я бы сказал, что лучше использовать пользовательский.

Хороший пример (источник)

Обновление - срок действия

Важное примечание: срок действия относится к контексту очереди. Таким образом, сообщения могут быть удалены серверами.

README говорит следующее:

expiration является shortstr; так как RabbitMQ ожидает, что это будет закодированную строку, мы переводим ttl в строковое представление его целочисленного значения.

Источники:

• Дополнительный источник 1
• Дополнительный источник 2

Ответ 2

На момент написания:

• Последний стандарт AMQP AMQP 1.0 OASIS Standard.
• Последняя версия RabbitMQ - это 3.1.5 (сервер и клиент), которая утверждает, что поддерживает AMQP 0.9.1 (pdf и XML-схемы заархивировано).
• RabbitMQ предоставляет свое собственное описание протокола как XML-схема, включающая расширения (то есть нестандартные), плюс XML-схема без расширений (которая идентична схеме, связанной через (2)) и pdf doc.

В этом ответе:

• ссылки в (3) являются основным источником детализации
• (2) pdf doc используется как вторичная деталь, если (3) неадекватно
• Исходный код (java-клиент, сервер erlang) используется в качестве третичной детали, если (2) неадекватен.
• (1) обычно не используется - протокол и схема были (справедливо) значительно развиты для /OASIS и должны применяться к будущим версиям RabbitMQ, но теперь не применяются. Два исключения, в которых (1) использовались, были для текстовых описаний contentType и contentEncoding - это безопасно, потому что это стандартные поля с хорошими описаниями в AMQP 1.0.

Следующий текст перефразируется мной из этих источников, чтобы сделать немного более кратким или понятным.

• content-type (AMQP XML type = "shortstr" ; java type = "String" ): Необязательно. Тип MIME RFC-2046 для раздела (тела) приложения-данных сообщений. Может содержать параметр charset, определяющий используемую кодировку символов: например, text/plain; кодировка = "UTF-8". Если тип содержимого неизвестен, тип содержимого НЕ ДОЛЖЕН быть установлен, позволяя получателю определять фактический тип. Если известно, что раздел является действительно непрозрачным двоичным данным, тип содержимого ДОЛЖЕН быть установлен в приложение/октет-поток.
• кодирование содержимого (AMQP XML type = "shortstr" ; java type = "String" ): Необязательно. В случае присутствия описываются дополнительные кодировки контента, применяемые к данным приложения, и, следовательно, какие механизмы декодирования необходимо применять для получения медиа-типа, на который ссылается поле заголовка содержимого. В основном используется для сжатия документа без потери его основного типа контента. Модификатор для типа содержимого, интерпретируемый в соответствии с разделом 3.5 RFC 2616. Действительные кодировки контента регистрируются в IANA. Реализации НЕ ДОЛЖНЫ использовать кодировку сжатия, за исключением того, что она остается совместимой с сообщениями, первоначально отправленными с другими протоколами, например. HTTP или SMTP. Реализации НЕ ДОЛЖНЫ указывать несколько значений кодирования контента, за исключением того, что они совместимы с сообщениями, первоначально отправленными с другими протоколами, например. HTTP или SMTP.
• заголовки (AMQP XML type = "table"; java type = "Map" ): Необязательно. Указанный список параметров заголовка и их значений. Они могут быть настроены для использования только для приложений. Кроме того, можно создавать очереди с "Тип заголовка Exchange" - когда очередь создается, ей присваивается серия имен свойств заголовка, каждая из которых имеет необязательные значения для сопоставления, так что маршрутизация в эту очередь происходит через заголовок Сопоставления.
• deliveryMode (RabbitMQ XML type = "октет" ; java type = "Integer" ): 1 (непостоянный) или 2 (стойкие). Работает только для очередей, которые реализуют постоянство. Постоянное сообщение надежно хранится на диске и гарантировано будет доставлено даже при серьезном сбое сети, сбое сервера, переполнении и т.д.
• приоритет (AMQP XML type = "октет" ; java type = "Integer" ): относительный приоритет сообщения (от 0 до 9). Сообщение с высоким приоритетом [МОЖЕТ БЫТЬ? - GB] отправлен перед сообщениями с более низким приоритетом, ожидающими в той же очереди сообщений. Когда сообщения должны быть отброшены, чтобы поддерживать определенный уровень качества обслуживания, сервер сначала отменит сообщения с низким приоритетом. Работает только для очередей, которые реализуют приоритеты.
• идентификатор корреляции (AMQP XML type = "октет" ; java type = "String" ): необязательно. Для использования приложения не существует формального поведения (RabbitMQ). Идентификатор клиента, который может использоваться для отметки или идентификации сообщений между клиентами.
• REPLYTO(AMQP XML type = "shortstr" ; java type = "String" ): Необязательно. Для использования приложения не существует формального поведения (RabbitMQ), но может содержать имя частной очереди ответа при использовании в сообщениях запроса. Адрес node для отправки ответов.
• expiration (AMQP XML type = "shortstr" ; java type = "String" ): Необязательно. RabbitMQ AMQP 0.9.1 схема из (3) состояния "Для использования в реализации, никакого формального поведения". В схеме AMQP 0.9.1 pdf из (2) указано абсолютное время, когда это сообщение считается истекшим. Однако оба эти описания должны быть проигнорированы, потому что эта ссылка TTL и код клиент/сервер указывают, что следующее верно. От клиента истечение будет заполнено только с помощью пользовательской инициализации приложения BasicProperties. На сервере это используется для определения TTL с точки, когда сообщение получено на сервере, до очередности. Сервер выбирает TTL как минимум (1) сообщение TTL (клиент истечение срока действия BasicProperties как относительное время в миллисекундах) и (2) очередь TTL (настроено x-message-ttl в миллисекундах). Формат: строковое цитированное целое число, представляющее количество миллисекунд; время истечения срока действия сообщения, полученного на сервере.
• message-id (AMQP XML type = "shortstr" ; java type = "String" ): Необязательно. Для использования приложения не существует формального поведения (RabbitMQ). Если установлено, производитель сообщений должен установить его в глобально уникальное значение. В будущем (AMQP 1.0) брокер МОЖЕТ отбросить сообщение как дубликат, если значение идентификатора сообщения совпадает с значением ранее полученного сообщения, отправленного на тот же node.
• timestamp (AMQP XML type = "timestamp"; java type = "java.util.Date" ): Необязательно. Для использования приложения не существует формального поведения (RabbitMQ). Абсолютное время создания этого сообщения.
• тип (AMQP XML type = "shortstr" ; java type = "String" ): необязательно. Для использования приложения не существует формального поведения (RabbitMQ). [Описывает сообщение как принадлежащее к конкретному приложению "type" или "form" или "business transaction" - GB]
• userId (AMQP XML type = "shortstr" ; java type = "String" ): Необязательно. В XML-схеме говорится: "Для использования приложения не существует формального поведения (RabbitMQ)", но я считаю, что это изменилось в последней версии (читайте дальше). Если установлено, клиент устанавливает это значение как личность пользователя, ответственного за создание сообщения. Из RabbitMQ: если это свойство задано издателем, его значение должно быть равно имени пользователя, используемого для открытия соединения ( т.е. выполняется проверка, чтобы убедиться, что это подключенный/аутентифицированный пользователь). Если свойство user-id не установлено, идентификатор издателя остается закрытым.
• appId (RabbitMQ XML type = "shortstr" ; java type = "String" ): Необязательно. Для использования приложения не существует формального поведения (RabbitMQ). Создание идентификатора приложения. Может быть заселен производителями и читается потребителями. (Рассматривая код сервера R-MQ, этот сервер вообще не используется сервером, хотя плагин "webmachine-wrapper" предоставляет script и соответствующие шаблоны для создания веб-машины - где администратор может предоставить appId для script).
• идентификатор кластера (RabbitMQ XML type = "N/A"; java type = "String" ): Устаревший в AMQP 0.9.1 - то есть не используется. В предыдущие версии, был идентификатором маршрутизации внутри кластера, для использования кластерными приложениями, которые не должны использоваться клиентскими приложениями (т.е. не заполнены). Однако это устарело и удалено из текущей схемы и не используется кодом сервера R-MQ.

Как вы можете видеть выше, подавляющее большинство этих свойств не имеют перечисленных/ограниченных/рекомендуемых значений, потому что они "используются только для использования" и не используются RabbitMQ. Поэтому у вас есть легкая работа. Вы можете писать/читать значения, полезные для вашего приложения, если они соответствуют типу данных и компилируются:). contentType и contentEncoding соответствуют стандарту использования HTTP. DeliveryMode и priority - это ограниченные числа.

Примечание. Полезные, но простые константы для AMQP.BasicProperties доступны в классе MessageProperties.

Приветствия:)

ОБНОВЛЕНИЕ К POST:

С большим благодарностью Renat (см. комментарии) просмотрели код сервера erlang в rabbit_amqqueue_process.erl и документацию на RabbitMQ TTL Extensions для 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/expiration находится в миллисекундах, поэтому в каждом случае 60 секунд. Обновлено выше определения истечения срока действия, чтобы отразить это.

Ответ 3

Спецификация AMQP определяет общую расширяемую модель свойств.

Свойства AMQP несколько схожи в концепции с заголовками HTTP, поскольку они представляют метаданные о рассматриваемых сообщениях. Как и в HTTP, они обрамлены отдельно в полезную нагрузку сообщения. Но они в основном представляют собой карту ключевых/значений.

Некоторые брокеры, такие как RabbitMQ, будут интерпретировать определенные свойства сообщений, такие как expiration, чтобы добавить дополнительное значение для конкретного поставщика (в этом случае принудительное использование TTL).

Но в конце концов, свойства AMQP - это просто большая группа пар ключ/значение, которые безопасно отправляются вместе с каждым сообщением, если вы решите это сделать. Ваша документация брокера AMQP сообщит вам, какие из них они интерпретируют специально и как отправлять свои собственные.

Все, что сказано, если вы задаете этот вопрос в первую очередь, вам, вероятно, вообще не нужно беспокоиться о них. Вы сможете успешно отправлять сообщения, не беспокоясь о настройке каких-либо свойств сообщений.