Большинству веб-приложений требуется выполнять некоторую работу, напрямую не связанную с ответом на запросы пользователей, асинхронно, в фоновом режиме. Например, Google должен сканировать и индексировать весь интернет, чтобы возвращать релевантные результаты поиска. Он не делает это при каждом запросе, а сканирует сеть асинхронно, обновляя поисковые индексы «по пути».
Выполнять асинхронную работу позволяют разные архитектуры, но наиболее распространённой является архитектура «очередь задач». Она состоит из двух компонентов: очереди «заданий», которые необходимо выполнить, и одного или нескольких рабочих серверов (часто называемых «работниками»), которые обрабатывают задания из очереди.
В очередях задач хранятся списки заданий, которые нужно выполнить асинхронно. Всякий раз, когда приложению нужно выполнить какую-то задачу, которая должна выполняться по расписанию или в соответствии с действием пользователя, оно добавляет её в очередь. Проще всего организованы очереди FIFO — «первым пришёл — первым ушёл», но большинство приложений в конечном итоге нуждаются в какой-то системе балансировки очередей.
Например, в Storyblocks очередь заданий используется для выполнения многих скрытых работ, необходимых для поддержания проекта: кодирование видео и фотографий, обработка CSV-файлов для тегов метаданных, агрегирование статистики пользователей, отправка писем с паролями для сброса и т. д. Со временем проект отказался от простой очереди FIFO в пользу приоритетной очереди, чтобы операции с фиксированным временем выполнения, такие как отправка писем о сбросе пароля, были завершены как можно скорее.
Сервера заданий выполняют задания из очереди. Они запрашивают её, чтобы определить, есть ли работа, и если есть, — приступают к выполнению.
RabbitMQ ориентирован на оптимизацию рабочей нагрузки или отправку данных, которые сервер может обрабатывать, путем передачи аналогичных задач независимым и сторонним источникам. Чтобы по-настоящему понять этот инструмент, давайте начнем с первого компонента этого процесса.
На изображении, показанном выше, RabbitMQ состоит из четырех компонентов, начиная с производителя. Производитель - это любое клиентское приложение, которое создает задачу, которая должна быть отправлена, обработана и ожидает отправки данных в соответствии с их запросом.
Далее у нас есть обмен. Основная цель обмена - получать и отправлять сообщения в соответствующую очередь в зависимости от типа обмена. На изображении выше у нас только одна очередь, поэтому все задачи будут помещены в очередь. На изображении выше у нас только одна очередь, поэтому все задачи будут помещены в очередь. Когда в уравнение входит несколько очередей, биржи играют более важную роль.
В-третьих, в процессе есть очереди. Очереди используются для группировки похожих задач в порядке FIFO (First In First Out). Реальный пример этого - когда вы стоите в очереди в магазине смузи. Первый человек, который входит в очередь, является первым, кто решит или, в данном случае, купит свой смузи и уйдет. Очереди в RabbitMQ можно рассматривать точно так же, они используются для хранения сообщений или задач, ожидающих решения, в том порядке, в котором они пришли.
Наконец, у нас есть потребители. Потребитель - это любое приложение, которое решает задачу или сообщение в очереди. После того, как задача помещена в очередь, потребитель удалит это сообщение из очереди, чтобы его можно было выполнить. Преимущества RabbitMQ в том, что у потребителя и производителя нет необходимости иметь отношения за пределами их ссылки RabbitMQ. Причина в том, что единственная задача потребителя - выполнить задачу, выходящую из очереди, поэтому, поскольку задача может быть выполнена на любом языке, связь между приложениями практически отсутствует.
RabbitMQ не стал бы частью того инструмента, которым он является сейчас, если бы предлагал только эти услуги. Поэтому на следующем рисунке показано, когда у вас есть несколько очередей, которые могут группировать похожие задачи для выполнения.
Преимущества использования нескольких очередей заключаются в том, что вы можете выполнять разные группы задач во внешних процессах. Эта методология выделяет и оптимизирует для разделения проблем при группировании выполнения ваших задач. При добавлении нескольких очередей в этот процесс рабочая нагрузка биржи становится все более логистической, поскольку она должна помещать задачу в правильную очередь. Это сопоставление задач с конкретной очередью зависит от типа реализованного обмена.
Когда производитель создает задачу, к задаче прикрепляется ключ маршрутизации. В дополнение к этому, соединения между обменом и очередью называются привязками. Каждая ссылка привязки имеет ключ привязки. Именно через тип обмена определяется способ сравнения ключа маршрутизации и ключа привязки.