RabbitMQ - это зрелый и стабильный сервер обмена сообщениями, который использует протокол AMQP для обмена сообщениями между производителями и потребителями.

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

Здесь я объясню некоторые (возможно, все…) конфигурации и параметры для моего наиболее распространенного варианта использования: Гарантированная доставка сообщений для очередей рабочих заданий.

Это означает, что если RabbitMQ принимает сообщение, оно будет использовано и будет удалено из очереди только после подтверждения.

Это касается настройки обмена, очереди, потребителя и производителя. И не будет охватывать надежность сервера RabbitMQ и кластеризацию. Я также не забочусь о заказе, так как большую часть времени я использую несколько потребителей.

Краткое резюме RabbitMQ

Чтобы использовать rabbitmq, вы открываете соединение с сервером. В этом соединении вы можете открыть один или несколько каналов, которые вы используете для публикации и использования сообщений.

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

Чтобы «поместить сообщение на rabbitmq», вы публикуете его на бирже. Обмен получает сообщение и направляет его в очередь.

Чтобы получать сообщения от rabbitmq, вы потребляете их из очереди. Чтобы удалить сообщения, вы подтверждаете или отклоняете их. Вы также можете отложить и поставить в очередь, чтобы сообщение оставалось в очереди.

Объявление - это акт создания обмена и очереди. Связывание - это то, что подключает обмен к очереди.

Не теряйте биржи и очереди

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

Для обмена это означает, что при его объявлении в качестве аргументов должны быть установлены параметры «Durable = true», «auto-delete = false» и «internal = false».

Для очереди это означает, что при ее объявлении в качестве аргументов должны быть установлены «Durable = true», «auto-delete = false» и «exclusive = false». Но в нескольких абзацах ниже есть больше аргументов в пользу очереди.

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

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

Не терять отклоненные сообщения

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

Очередь недоставленных писем, сопровождаемая обменом недоставленными письмами, позволяет вам перехватить отклоненные сообщения из очереди.

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

При объявлении очереди вы устанавливаете в качестве аргументов `x-dead-letter-exchange = exchange-name.dlx` и` x-dead-letter-routing-key = `.

Сводка обмена и декларация об очередях

Вы заявляете в порядке:

  • Надежный обмен
  • Надежный обмен неудачными сообщениями (dlx)
  • Устойчивая очередь для неудачных сообщений (dlq)
  • Привязать dlx к dlq
  • Устойчивая очередь с недоставленными аргументами
  • Привязать первый обмен к последней очереди

Конечно, это в случае одного обмена с одной очередью, если вы хотите направить ко многим очередям, вам нужно повторить шаги dlq и queue.

Безопасное использование сообщений

На самом деле в AMPQ есть больше, чем просто потреблять сообщения, но наиболее распространенным и рекомендуемым методом является использование метода потребления.

Вы должны установить для параметра `auto-ack` значение false и подтверждать только сообщения, когда их можно удалить.

Если вам не удалось обработать сообщение, вы должны отклонить его, чтобы они отправились в DLQ.

Если вы не подтвердите или отклоните сообщение, оно в конечном итоге вернется в очередь.

Это гарантирует, что сообщения покидают очередь только после того, как вы закончите с ними, и что они попадут в dlq в случае сбоя.

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

Публикация безопасно

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

Чтобы убедиться, что сообщение будет перенаправлено в очередь, вы установите для него значение «обязательный = истина». Это означает, что публикация вернет успех только в том случае, если сообщение окажется в очереди, и вы получите сообщение об ошибке, если сообщение не маршрутизируемое (например, отсутствие привязки при обмене или неправильное правило ключа маршрутизации).

Чтобы убедиться, что сообщение отправляется на диск, вы устанавливаете persistent = true. Это гарантирует, что rabbitmq запишет его на диск в очереди.

И напоследок. следует дождаться подтверждения того, что сообщение написано.

Существуют и другие методы, такие как транзакции, но более быстрый и рекомендуемый способ - использовать ожидание подтверждения.

Вы вызываете confirm или wait_for_confirms на открытом канале, чтобы дождаться, пока rabbitmq подтвердит, что сообщения, отправленные по этим каналам, были записаны туда, где они должны.

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

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

Заключение

Это все меры, которые я знаю, чтобы убедиться, что ваши сообщения rabbitmq безопасны. Не считая кластера, но это уже другая история.

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

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

Итак, я что-то пропустил? Есть еще советы?