Что такое очередь сообщений ( message queue )? Это некая структура данных, которая обеспечивает хранение и передачу двоичных данных ( blobs ) между различными участниками системы. Очереди сообщений практически всегда используются в крупных системах, благодаря важным преимуществам.
- Независимость компонентов системы друг от друга. Благодаря использованию очереди, компоненты взаимодействуют через некий общий интерфейс, но ничего не знают о существовании друг друга.
- Экономия ресурсов достигается вследствие возможности разумно распределять информацию, поступающую в очередь от одних процессов, между другими процессами, осуществляющими её обработку. Кроме того, благодаря тому, что нет необходимости промежуточного хранения необработанных данных, достигается дополнительная экономия ресурсов.
- Надежность очередей достигается благодаря возможности накапливать сообщения, амортизируя недостаток вычислительных возможностей системы, а также благодаря независимости компонентов. Помимо этого очередь может аккомодировать сбои отдельных компонентов, осуществляя доставку «опоздавших» сообщений после восстановления.
- И, наконец, гарантия последовательной обработки, позволяющая точно контролировать потоки данных в системе и запускать асинхронную обработку там, где это необходимо, не беспокоясь, что одна операция выполнится раньше другой, от результата которой она зависит.
Учитывая огромную важность очередей для надёжных и гибких систем обработки данных, была даже разработана спецификация протокола — AMQP, на основе которой разрабатывается несколько приложений, выполняющих функцию очереди — так называемых «брокеров». Аналогия с биржевыми процессами будет прослеживаться и в дальнейшем. Мы рассмотрим брокер RabbitMQ, авторами которого и создан протокол AMQP.
Is this the WORLDS CUTEST Bunny 😱 | Wholesome Animal
Почему RabbitMQ?
Причин несколько, но одна из основных — реализация приложения на платформе Erlang/OTP, гарантирующая максимальную стабильность и масштабируемость очереди, как ключевого узла всей системы. Другая причина — полная открытость приложения, распространяющегося по лицензии Mozilla Public License и реализация открытого протокола AMQP, библиотеки для которого существуют во всех основных языках и платформах программирования. В том числе и для Node.js
Основные понятия
Брокер
Под брокером мы будем понимать сам сервер RabbitMQ. Брокер может быть один, брокеров может быть несколько, объединённых в общий кластер. Брокер занимается непосредственно передачей сообщений. Однако на внутреннем уровне происходит намного больше процессов, нежели просто передача байтиков по сети.
Очередь
Очередь — основной логический компонент брокера. Именно из очереди клиент ( consumer ) забирает сообщения. Другое дело, что очередь не единственный участник обмена.
Биржа
Биржа (exchange, иногда переводится как «обмен») играет важнейшую роль в направлении сообщений от отправителя ( producer ) к клиенту (consumer, он же потребитель). Дело в том, что именно благодаря бирже, поступающее от отправителя сообщение направляется в нужную очередь. Кроме того, у сообщения может присутствовать метка ( routingKey ) (ключ м
Apache Kafka урок 1. Зачем нужна, что это? RabbitMQ vs Kafka vs БД
Это наиболее важная строчка, в которой мы сообщаем брокеру, что сообщение было принято, полностью обработано и его можно безопасно удалить из очереди. Если такое подтверждение брокеру не отправить, то сообщение никогда не будет удалено из очереди и постепенно брокер заполнит всю оперативную память сервера. Будьте внимательны — это одна из самых частых ошибок при работе с очередью.
Важно: отправляйте ack только когда сообщение действительно полностью обработано и его можно удалить. Это будет гарантировать две вещи:
- Не будет потерянных сообщений
- Очередь сможет распределять нагрузку максимально честно, т.к. пока от клиента не придёт подтверждение, что обработка завершена, новое сообщение ему отправлено не будет
Важно: если сообщение обработать невозможно по техническим или каким-то другим причинам у вас есть два варианта.
- Всё равно отправить ack и навсегда потерять сообщение
- Вызывать channel.nack , отказавшись принимать и обрабатывать сообщение, тогда очередь добавит сообщение в конец и со временем оно снова будет отправлено на обработку (возможно другому клиенту)
Обратите внимание: брокер по-умолчанию сам распределяет нагрузку между клиентами, вам ничего не нужно для этого делать. Один у вас клиент, или пятьдесят — брокеру всё равно.
Publish-Subscribe (он же Broadcast)
Никто не запрещает отправлять сообщения сразу всем клиентам, а не по алгоритму round-robin. Это позволяет использовать очередь в качестве сервера pubsub. Всё, что для этого нужно сделать — определить биржу типа fanout. Делается это в вызове assertExchange :
channel.assertExchange(«incoming», «fanout»)
Как видно, тип биржи передаётся вторым параметром. Поменяйте код отправителя и клиентов (помните, что определения бирж и очередей должны совпадать), как показано выше и попробуйте запустить несколько клиентов. Посмотрите, как будут распределяться сообщения теперь.
Всего одно маленькое дополнение — и совершенно изменившийся алгоритм работы. Как видите, для того, чтобы менять поведение брокера, вовсе не нужно лезть в глубокие настройки сервера. Достаточно слегка поменять код.
Маршрутизация по шаблону
Как вы заметили, тип биржи определяет алгоритм работы брокера. Типом по-умолчанию является direct. Этот тип отправляет сообщения в чётком соответствии с routingKey , биржей и очередью. Тип fanout осуществляет доставку сообщений всем и сразу. А вот тип topic позволяет избирательно доставлять сообщения по шаблону, передаваемому всё в том же routingKey . Только формат этого параметра теперь становится особенным.
Метка должна содержать несколько слов, разделённых точкой. Например: «a.b» или «animals.feline.tiger». Должна присутствовать по крайней мере одна точка. Максимальный размер метки — 255 байт. Обратите внимание: не символов, байт.
Если вы используете символы Unicode, то имейте это ввиду.
Существует два особых знака, которые используются в routingKey при привязке очереди к бирже по метке (и только тогда, но не при отправке!):
- «*», обозначающая ровно одно слово (например: «animals.feline.*» — подойдёт к «animals.feline.tiger», но не к «animals.feline.leopard.panther»)
- «#», обозначающий ноль или более слов (например: «animals.#» — подойдёт и к «animals.feline» и к «animals.canine.wolf»)
channel.bindQueue(«messages», «incoming», «animals.feline.*»)
Позволит нам принимать все сообщения о животных из семейства кошачьих, не имеющих подвидов.
Ну а следующее сообщение будет получено клиентом, который добавил вышестоящую привязку:
channel.publish(«incoming», «animals.feline.tiger», new Buffer(«Rroarrrr!»))
Зато такое сообщение им принято не будет:
channel.publish(«incoming», «animals.feline.cat.domestic», new Buffer(«Meow!»))
Remote Procedure Call
Иногда возникает потребность передать сообщение обработчику И дождаться ответа. Этот сценарий описывает систему «удалённого вызова процедур». Такая система тоже вполне может быть построена с помощью RabbitMQ.
Посмотрим, как это сделать.
Клиент
На клиенте всё очень просто: в вызов publish добавляется специальная опция replyTo, значением которой является имя очереди, в которой клиент будет ожидать ответ. Обратите внимание, что в данном случае клиент обращается к серверу именно через publish, поскольку он хочет вызвать удалённую процедуру, находящуюся на сервере. В данном сценарии отправителем будет являться клиент, а потребителем — сервер. Затем их роли поменяются местами, когда сервер отправит клиенту ответ.
channel.publish(«api», «calculate», new Buffer(«2 + 3»), {replyTo: «api-reply», correlationId: «calculate-1»})
Подразумевается, что очередь “api-reply” существует. Однако здесь следует заметить вот что: поскольку клиент ожидает ответ на конкретный вызов, то очередь, в которую придёт ответ должна быть уникальна. Для этой ситуации предусмотрена опция exclusive: true в вызове assertQueue — она гарантирует, что данная очередь будет доступна исключительно вызывавшему assertQueue клиенту и видна только в пределах канала связи. Мы могли бы создавать такую эксклюзивную очередь для каждого отдельного вызова RPC. Но это было бы крайне неэффективно (зато очень просто в реализации). Более выгодным вариантом является создание одной очереди на клиента
маршрутизации), которая дополнительно повлияет на решение брокера о том, в какую очередь сообщение будет отправлено.
Обратите внимание: очередь вторична по отношению к бирже. Именно биржа определяет, куда пойдёт сообщение, в какую очередь. Клиенты же могут принимать сообщения только из очереди, поэтому если вы не хотите разбираться с кучей проблем и передать всю маршрутизацию сообщений брокеру — имейте следующее в виду: если вы хотите отделить одни сообщения от других, их нужно разместить в разных очередях.
Другими словами, сообщения в одной очереди должны быть одинаковы по структуре, чтобы вы могли корректно и без усилий распределять их по системе. Рассматривайте очередь как набор элементов одинакового типа.
Варианты работы
Прямая передача
В этом варианте в самом простом случае у нас один клиент и один отправитель. Отправитель шлёт сообщение в очередь, клиент слушает очередь, достаёт из неё сообщения и обрабатывает их. Рассмотрим как это работает на следующем примере.
12345678910111213141516
var rabbit = require(«amqplib»).connect()rabbit.then(function(connection) { var ok = connection.createChannel() ok.then(function(channel) { // durable: true is set by default channel.assertQueue(«messages») channel.assertExchange(«incoming») channel.bindQueue(«messages», «incoming», «mda») for (i = 0; i < 100; i++) channel.publish(«incoming», «mda», new Buffer(«Hello » + i), {deliveryMode: true}) }) return ok}).then(null, console.log)
Для работы с RabbitMQ в Node.js лучше всего использовать библиотеку amqplib , реализующую соответствующий протокол. В этом случае вы можете использовать любой брокер, который соответствует этому протоколу.
Библиотека вносит ещё один элемент в работу с очередью: канал. Однако это не более чем просто канал связи между брокером и общающимся с ним компонентом системы. Не следует рассматривать его как часть брокера или очереди сообщений.
Связь с брокером и создание канала
Рассмотрим по порядку, что происходит после установления связи с брокером и создания канала.
channel.assertQueue(«messages»)channel.assertExchange(«incoming»)
Два этих вызова обеспечивают существование очереди и биржи. Каждая очередь и биржа создаётся лишь один раз, а вызовы никак не влияют на уже существующие объекты.
Очередь можно создать с дополнительными параметрами, важнейшим из которых является параметр durable — он влияет на то, будут ли сообщения в очереди сохранены в случае падения брокера. По-умолчанию в данной библиотеке этот параметр установлен в true . Подробнее обо всех параметрах создания очереди и биржи можно прочесть в документации к библиотеке. Отметим лишь, что в дальнейших примерах мы воспользуемся разными типами бирж.
channel.bindQueue(«messages», «incoming», «mda»)
Этот вызов осуществляет привязку очереди к бирже и сообщению с конкретным routingKey : очередь messages привязывается к бирже incoming , которая должна передавать в эту очередь сообщения с меткой mda . Теперь мы можем либо принимать сообщения из этой очереди, будучи уверенными, что наш клиент через конкретный данный канал будет получать лишь сообщения с меткой mda , переданные через биржу incoming . Либо передавать сообщения в биржу incoming с меткой mda , зная, что они попадут в очередь messages . Если мы попытаемся передать сообщение с другой меткой, оно уйдёт в /dev/null , поскольку мы привязали лишь одну конкретную метку. Если мы попытаемся передать сообщение в несуществующую биржу, оно уйдёт в /dev/null , если привязать биржу к несуществующей очереди — тоже.
channel.publish(«incoming», «mda», new Buffer(«Hello » + i), {deliveryMode: true})
Далее мы в цикле передаём сто сообщений бирже incoming с меткой mda (она же routingKey ) и опцией deliveryMode: true , означающей что сообщение будет сохранено в очереди, если брокер выйдет из строя на время. Следует заметить, что сохранение сообщения на диск — операция медленная, и брокер может упасть в её процессе. Так что абсолютной надёжности эта опция не даёт.
Сто сообщений мы передаём для демонстрации масштабирования системы исключительно средствами брокера, что очень просто и безболезненно.
Клиент для тестирования отправителя
Рассмотрим клиент, который нам нужен для тестирования отправителя. Запустим два или даже три таких клиента, после чего запустим отправителя, и убедимся, что все сообщения были распределены между клиентами максимально честно, по алгоритму round-robin.
12345678910111213141516171819
var rabbit = require(«amqplib»).connect()rabbit.then(function(connection) { var ok = connection.createChannel() ok.then(function(channel) { // durable: true is set by default channel.assertQueue(«messages») channel.assertExchange(«incoming») channel.bindQueue(«messages», «incoming», «mda») channel.consume(«messages», function(message) { console.log(message.content.toString()) channel.ack(message) }) }) return ok}).then(null, console.log)
Обратите внимание: насколько код клиента похож на код отправителя. Отличается лишь то, что вместо отправки сообщений, мы принимаем их. Как было сказано выше, принимать сообщения можно лишь из очереди (так же как отправлять — только на биржу).
channel.ack(message)
Однако в этом случае возникает вопрос: как отделить ответ на один вызов от другого? Для этой ситуации предназначен ещё один параметр вызова publish : correlationId . Он принимает строковое значение и возвращается в ответе от сервера, чтобы клиент мог на его основе определить, результат какого вызова он получил только что. Его можно генерировать случайным образом.
Если же клиенту приходит ответ с неизвестным correlationId , то его можно смело игнорировать. Такое может случиться из-за рассинхронизации сервера и брокера, например, в случае падения сервера.
Общий алгоритм работы
- При запуске клиент создаёт эксклюзивную для себя очередь
- Для каждого вызова клиент отправляет дополнительные параметры: replyTo и correlationId . Последний должен быть уникален для вызова.
- Сервер слушает очередь, в которую отправляются вызовы от клиентов (обратите внимание, это не replyTo , а ещё одна отдельная очередь, общая для всех клиентов и сервера)
- При поступлении запроса, сервер обрабатывает его и отправляет ответ в очередь replyTo вместе с correlationId , полученными от клиента в запросе
- Клиент слушает очередь replyTo , при поступлении туда сообщения, он соотносит correlationId с имеющейся у него таблицей вызовов и обрабатывает результат
Замечание: если отправить сообщение через publish с пустым значением имени «биржи», а в качестве routingKey указать значение replyTo , то сообщение уйдёт по назначению:
channel.publish(«», request.properties.replyTo, new Buffer(«5»), {correlationId: request.properties.correlationId})
Аналогично можно отправлять сообщения и с клиента в очередь rpc :
channel.publish(«», «rpc», new Buffer(«2 + 3»), {replyTo: «rpc-reply-1», correlationId: «calculate-1»})
Читайте так же статьи по теме:
Источник: makeomatic.ru
Что такое RabbitMQ, зачем он нужен и как его использовать
Около полугода назад на одном проекте мы с напарником столкнулись с проблемой масштабирования, которая в тот момент внезапно ударила по серверу и весело его уронила. Количество задач, которые ставили пользователи, превысило барьеры вычислительных мощностей. Факторов, которые к этому привели, было несколько:
- Во-первых, мы паршиво построили архитектуру: вся работа сервиса была заточена только на 1 сервер и каких-либо заделов к масштабированию на 2 или 3, как ты понимаешь, не было.
- Во-вторых, мы — не профессионалы, а самоучки, которые пилили проект на скорость, так как «готово должно быть вчера».
- Не идёт речи о грамотном распределение ресурсов — вся многопоточность строилась на инструментах, с которыми умел работать PHP, а PHP, как можно догадаться, работает с ними не особо хорошо.
Проблема была решена — был арендован второй сервер, куда были перенесены соответствующие скрипты и с помощью небольшого API делегирована часть задач. Но в момент, когда мы искали решение и думали, что же лучше: по запросу передавать JSON-массив или что-то другое, нашли много интересной информации.
В частности google выдавал что-то про «брокеры сообщений», «очереди», какого-то кролика… Причём тут кролик я тогда не понял, чтиво про брокеры — бросил, подумав, что это слишком сложно. Но через некоторое время появилась задача делегировать уже другие данные на ещё один сервер, и тут, на одном из форумов, мне уже явно посоветовали покурить в сторону злополучного кролика — RabbitMQ. К слову, задачу я решил, RabbitMQ оказался не таким и сложным (вернее — его конфигурация), а решение моей конкретной задачи заняло весьма немного кода. Так что же такое RabbitMQ?
RabbitMQ — это платформа позволяющая обмениваться сообщениями. Что может быть в сообщении — решать только тебе. Обмениваться можно как на одном сервере, так и с одного на другой.
Это отличный способ масштабирования, так как с хорошо настроенным RabbitMQ мы можем просто подключать новые сервера, настроив на них нужное ПО и прописав конфигурацию, а RabbitMQ будет сам делегировать работу между всеми серверами. На официальном сайте есть мануалы по основным способам использования кролика — ознакомься. Я не буду описывать основные сущности, которые есть в RabbitMQ и на основе который строится протокол AMQP — это можно легко найти в сети.
Я сегодня рассмотрю, как интегрировать RabbitMQ в Symfony 4.1 на примере двух серверов — один будет отправлять сообщения, а другой получать. Какая актуальность данной статьи, если подобные маны уже есть? Ну по-первых, она на русском. Во-вторых, есть несколько ошибок, которые крайне сложно загуглить и решаются они методом научного тыка — вот их-то я и опишу.
У нас есть 2 сервера (хотя все примеры можно проделать и на одном, честно говоря) — один собирает задачи, другой их выполняет. Задачи могут быть любые — на твой вкус и цвет: от отправки email-сообщений, до обработки изображений. Можешь просто выводить данные на экран. Итак, на одном сервере у тебя идёт постановка задач, а на другом — обработка этих задач.
Сначала я показываю все действия на сервере, который собирает задачи.
Для начала — нужно установить бандл, который является обёрткой над библиотекой, реализующей протокол AMQP:
composer require php-amqplib/rabbitmq-bundle
Ошибок быть не должно, а если и будут — внимательно читай вывод и ставь библиотеки, которые будут указаны после слов, похожих на слово require. Или пиши в комментариях — я с радостью помогу.
Дальше нужно установить rabbitmq-server. Да, у кролика есть свой полноценный сервер, который разворачивается на одном из серверов, если мы рассматриваем обмен между двумя серверами. Тут нужно подумать, что у тебя будет сервером, а что клиентом. Так как обрабатывает задачи (а значит и выбрасывает их в очередь) сервер, с которым мы сейчас работаем — будет логично установить rabbitmq-server на него Если я тут не прав — пиши в комментариях. Ставим:
sudo apt-get install rabbitmq-server
И тут у тебя может появится первая проблема, об которую ты не слабо разобьёшь лоб:
rabbitmq/bin/rabbitmq-server-wait (code=exited, status=70)
Спустя почти час гугления я пришёл к выводу, что rabbitmq-server не запускается, собака такая, если в файле /etc/hostname у тебя прописано имя с точками. А мне поставили сервер, где в этом имени были точки… Точки эта штука распознавать не умеет.
Теперь добавляем пользователя и выдаём ему права, с помощью rabbitmqcli:
rabbitmqctl add_user username password rabbitmqctl set_user_tags username administrator rabbitmqctl set_permissions -p / username «.*» «.*» «.*»
Первая строка — добавляем пользователя и устанавливаем ему пароль. Главное, измени username и password на свои данные. Далее ставим пользователю категорию «администратор». Затем, выдаём доступ к просмотру всего и вся. Я записал эти параметры в файл config/services.yaml:
parameters: locale: ‘en’ rabbitmq_user: ‘username’ rabbitmq_password: ‘password’
Теперь нужно добавить сущность, с которой будет общаться rabbitmq-server — виртуальный хост, через который будет настраиваться конкретный обмен между конкретным постановщиком задач — producer (пишет в очередь) и потребителем задач — consumer (читает из очереди). Я не знаю почему, но в мануалах по интеграции Symfony и RabbitMQ этот пункт пропускают, а искать его самому и думать в чём ошибка — это дополнительное время. Добавляем:
rabbitmqctl add_vhost my_project rabbitmqctl set_permissions -p my_project username «.*» «.*» «.*»
username — это тот самый пользователь, созданный выше. my_project — имя хоста. Добавляем в параметры:
parameters: locale: ‘en’ rabbitmq_user: ‘username’ rabbitmq_password: ‘password’ rabbitmq_statuslayer_vhost: ‘my_project’
Идём дальше. А дальше нам нужно настроить конфиги. У тебя должен был появиться файл config/packages/old_sound_rabbit_mq.yaml — открывай его и добавляй:
old_sound_rabbit_mq: connections: default: host: localhost port: 5672 user: ‘%rabbitmq_user%’ password: ‘%rabbitmq_password%’ vhost: ‘%rabbitmq_statuslayer_vhost%’ producers: my_task: connection: default exchange_options: name: my_task_exchange type: direct
Давай разберёмся. Я надеюсь, что ты ознакомился с примерами на официальном сайте и знаешь, что producer — публикует сообщения, exchange — определяет, в какую (если их несколько) очередь сообщение выбросить. port у rabbitmq по-умолчанию 5672 — таким и оставляем. Теперь нам нужно создать exchange, делаем это с помощью команды:
php bin/console rabbitmq:setup-fabric
Всё успешно? Отлично, мы настроили rabbitmq на сервере, который будет писать в очередь. У кролика есть крутой интерфейс — зайди на ip сервера через порт 15672, увидишь нечто следующее:
Входи под данными, которые были созданы чуть выше и увидишь графики, метрики и прочую интересную штуку.
Теперь переходим на сервер, который будет читать сообщения. Тут всё гораздо проще. Сначала ставь бандл, затем открывай файл конфига и пиши:
old_sound_rabbit_mq: connections: default: host: ip_main_server port: 5672 user: ‘%rabbitmq_user%’ password: ‘%rabbitmq_password%’ vhost: ‘%rabbitmq_statuslayer_vhost%’ consumers: cons_name: connection: default exchange_options: name: ‘my_project’, type: direct> queue_options: name: ‘my_task_queue’> callback: callback_service
Ты уже понял, что параметры нужно определить в config/services.yaml в секции параметры. Имя пользователя и пароль указывай те, который были созданы выше. ip_main_server — это ip сервера, с которым мы работали выше.
Далее настраивается consumer. Параметр exchange_options имеет значение, которые мы создавали выше.
Параметр queue_options — это имя очереди. Можешь задать любое, она будет создана автоматически.
callback — это имя сервиса, который будет вызывать класс, обрабатывающий каждое новое сообщение из очереди. Давай его определим. Иди в файл config/services.yaml и добавляй:
callback_service: class: AppRabbitMQCallbackService
Как ты догадался, нужно создать этот класс. Создаётся он по определённому шаблону — его нужно унаследовать от класса Command, который нам любезно предоставляет RabbitMQ Bundle.
namespace AppRabbitMQ; use OldSoundRabbitMqBundleRabbitMqConsumerInterface; use PhpAmqpLibMessageAMQPMessage; class CheckInstagramAccount implements ConsumerInterface < public function execute(AMQPMessage $msg) < print_r($msg->body); > >
Просто выводим тело письма, которое пришло. Я тестировал на массивах, поэтому — print_r. Теперь запускаем consumer в режим ожидания сообщений:
php bin/console rabbitmq:consumer cons_name
И теперь с сервера, где мы устанавливали producer, отправим первое сообщение. Создаём простой контроллер:
Переходи на /check_data_test и наслаждайся — ты отправил и получил первое сообщение
Post Views: 35 959
Легаси код — зло вселенского масштаба! Я в своей жизни ещё ни разу не встречал проекта, где бы всё было сделано по правилам проектирования архитектуры, с…
Как использовать команду watch с пайпами Периодически при работе с консолью Linux нужно пронаблюдать за изменением вывода какой-либо команды с промежутком в несколько секунд. Для этого…
Как регламентировать перекуры в течение рабочего дня? Можно ли разрешать опаздывать к началу рабочего дня? Можно ли чатится во время…
1 Comment
andre · 2021-06-21 at 16:00
привет, а есть в раббите какойто журнал (лог) , где можно посмотреть какие сообщения пришли, какие отправлены, какие были ошибки?
Источник: evilinside.ru
Когда и зачем нужен RabbitMQ
В сложных системах, системах с вычислительными задачами, а также требующих гарантированной доставки важно организовать распределённую архитектуру и наладить коммуникацию между компонентами. Для решения задач с подобными вводными требованиями выбирают RabbitMQ — брокер сообщений с открытым исходным кодом. В статье рассмотрим основные сценарии его использования и разберём, когда и зачем нужен RabbitMQ.
Брокер сообщений как показатель зрелости системы
Если вы возьмёте любой сервис, почти наверняка в нём будет брокер сообщений. Это не обязательное условие, но оно считается одним из показателей зрелости системы. По мере развития сервиса и усложнения бизнес-функционала потребность в брокере сообщения только возрастает. Поэтому чем раньше вы начнёте его использовать, тем меньше костылей и технического долга появится в вашем проекте.
Какие проблемы решает брокер сообщения? Представим, что в ваш сервис пришёл новый пользователь и хочет зарегистрироваться. При регистрации он указывает адрес электронной почты, и для его валидации вам нужно послать уведомление с кодом. Чтобы реализовать отправку сообщения, нужно интегрироваться с внешней системой.
Но вы не хотите, чтобы пользователь ждал ответа удалённой системы. Вместо этого вы хотите, чтобы его сразу перенаправили на следующую страницу, где будет запрашиваться ввод кода с надписью «Подтвердить электронную почту». Брокер сообщений позволяет выполнять описанные операции асинхронно.
Асинхронный подход решает множество задач. Вместо того, чтобы планировать архитектуру, где каждый компонент посылает запросы к другим компонентам и ожидает от них ответа, вы просто отправляете сообщение в брокер. А один или несколько сервисов получают это сообщение и обрабатывают его в удобное время, что позволяет не блокировать программы. Если же у вас одни сервисы синхронно ждут другие, вы очень быстро упираетесь в ограничение по ресурсам, когда скорость всей системы равна скорости её самого медленного компонента.
Также использование брокера сообщений позволяет вашим сервисам ничего не знать о том, кто их обрабатывает. За счёт этого разные компоненты могут оставаться полностью изолированными и самостоятельными — достаточно только подписаться на нужную очередь.
Брокеры сообщений — посредники между сервисами. Они находятся в центре архитектуры и управляют потоками информации. Благодаря этому каждый сервис может послать сообщение другому сервису или целой группе сервисов. Такой подход стал популярен с развитием микросервисов и заставил пересмотреть отношение к отказоустойчивости.
Зачем использовать брокеры сообщений
Если сломается брокер, в худшем случае вы потеряете часть сообщений, но ядро сервиса всё ещё будет работать, так как берет информацию из базы данных. Сообщения будут накапливаться, и когда сервер вернётся, то быстро прочитает и обработает образовавшийся долг. Но иногда возникает частичная деградация: какая-то информация может оказаться не самой актуальной, хотя пользователи, скорее всего, этого даже не заметят. Пример — новостная лента в соцсетях. Если она не будет обновляться некоторое время, вы все равно сможете посмотреть опубликованные посты.
Бывает, что сервисы, спроектированные и написанные в краткие сроки, не имеют брокера сообщений. Потребность реализовать этот функционал осознаётся значительно позже. И здесь есть два варианта. Первый — сэкономить и в качестве брокера сообщений использовать базу данных. Это не очень хорошо, потому что решает проблему только на раннем этапе.
Второй вариант — настроить брокер сообщений. Так вы сможете обеспечить своему приложению технологический запас для будущего развития. Одним из наиболее популярных брокеров сообщений остаётся RabbitMQ.
Что такое RabbitMQ
RabbitMQ — распределённый и горизонтально масштабируемый брокер сообщений. Упрощённо его устройство можно описать так:
- паблишер, который отправляет сообщения;
- очередь, где хранятся сообщения;
- подписчики, которые выступают получателями сообщений.
RabbitMQ передаёт сообщения между поставщиками и подписчиками через очереди. Сообщения могут содержать любую информацию, например, о событии, произошедшем на сайте.
RabbitMQ отлично подходит для интеграции разных компонентов, создания микросервисов, потоковой передачи данных в режиме реального времени или при передаче работы удалённым работникам. Его используют крупные компании, в числе которых Bloomberg, Reddit, WeWork, NASA и др.
Почему выбирают RabbitMQ:
- RabbitMQ поддерживает несколько протоколов: AMQP, MQTT, STOMP и др., что позволяет использовать его в разных сценариях.
- RabbitMQ хранит сообщение до тех пор, пока принимающее приложение не подключится и не получит его из очереди. Клиент может подтвердить получение сообщения сразу или после того, как полностью обработает его. Как только такое подтверждение получено, сообщение удаляется из очереди. Для сравнения в Kafka очередь сообщений является постоянной — данные хранятся, пока не истечёт указанный период или не будет достигнуто ограничение по размеру. Поэтому важно убедиться, что событие, которое должно произойти один раз, не воспроизводится многократно.
- Основное преимущество RabbitMQ — гибкая маршрутизация. Сообщения маршрутизируются через exchange (обменник) перед попаданием в очереди. RabbitMQ предлагает несколько встроенных типов обмена для типичной логики маршрутизации.
- RabbitMQ поддерживает приоритезацию в очередях и позволяет настроить диапазон приоритетов. Приоритет каждого сообщения устанавливается при его публикации.
- RabbitMQ предлагает простой пользовательский интерфейс управления. Он позволяет контролировать каждый аспект брокера сообщений. .
Сценарии использования RabbitMQ
Обычно отмечают два варианта, когда стоит использовать RabbitMQ: для фоновой обработки данных и для интеграции внутри приложений и между ними, т.е. в качестве брокера сообщений между микросервисами. Рассмотрим оба сценария.
Фоновая обработка данных
Фоновая обработка данных — оптимальный сценарий использования RabbitMQ. Вы можете поместить сообщение в очередь без его немедленной обработки.
Пример: вы хотите загрузить отчёт из приложения. Приложение обрабатывает информацию и генерирует PDF-файл в течение 15-20 минут. Затем отправляет его вам по электронной почте. Очередь сообщений позволяет выполнить все задачи асинхронно.
Очереди RabbitMQ служат шинами событий и позволяют веб-серверам быстро реагировать на запросы вместо того, чтобы выполнять трудоемкие задачи на месте.
Посредник в микросервисной архитектуре
Также RabbitMQ часто используется для микросервисной архитектуры, где он выступает средством связи между приложениями и помогает избегать узких мест при передаче сообщений.
Ещё пара слов о RabbitMQ напоследок
Когда приложение ломается, другие приложения уже не могут обмениваться с ним сообщениями, поэтому работа останавливается. RabbitMQ же кладёт сообщение в очередь, дожидается, пока сломанное приложение починят, и отдаёт ему сообщение из очереди. Да, есть некоторая задержка на время устранения причины поломки, но глобально ничего не падает.
Также RabbitMQ выполняет распределённые нагрузки. Несколько копий одного приложения могут быть запущены на разных компьютерах. RabbitMQ распределит нагрузку относительно производительности и выберет, кому отправить сообщение.
RabbitMQ — больше, чем просто брокер сообщений. Он основан на ERLANG и платформе Open Telecom, обеспечивающей высокую производительность при использовании минимальных ресурсов. Его выбирают, когда требуется надёжная доставка сообщений и гибкая маршрутизация.
Для тех, хочет разобраться в RabbitMQ и получить скидку 10% на обучение
28 сентября у нас стартует курс по Rabbit MQ. На нём инфраструктурный инженер Алексей Барабанов расскажет, как не искать сложных решений там, где достаточно целевого хорошо настроенного инструмента. А ещё поделится кейсами и примерами из своего опыта.
Курс будет полезен тем, кто ещё не знаком с RabbitMQ, и тем, кто давно работает с ним только в базовом исполнении и хочет узнать о новых способах применения, нюансах отказоустойчивости и мониторинга.
Здесь можно ознакомиться с подробной программой и занять место: https://slurm.club/3AFKlyr
А промокод «READER» даст скидку 10% при покупке курса.
Источник: habr.com