6 лучших систем очередей для бэкэнд-разработчиков

Вы ищете систему очередей? Или, может быть, вы ищете лучший? Вот вся необходимая информация!

Системы очередей — самый сокровенный секрет разработки бэкенда.

Не пытаясь сочинить поэму в честь систем очередей, скажу, что младший бэкенд-разработчик становится бэкенд-разработчиком среднего уровня после того, как научится интегрировать очереди в систему. Очереди улучшают качество обслуживания клиентов (мы увидим, как), снижают сложность и повышают надежность системы.

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

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

Что такое система очереди?

Начнем с понимания того, что такое очередь.

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

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

Зачем нужны системы массового обслуживания?

Не вдаваясь в очень длинное описание, я бы сказал, что основная потребность в системах очередей связана с фоновой обработкой, параллельным выполнением и восстановлением после сбоя. Давайте рассмотрим их с помощью примеров:

Фоновая обработка

Предположим, вы проводите маркетинговую кампанию в области электронной коммерции, где время имеет решающее значение, и ваше приложение построено таким образом, что оно отправляет электронное письмо с подтверждением прямо перед тем, как клиент завершит платеж и ему будет показана страница «спасибо». Если почтовый сервер, к которому вы подключаетесь, не работает, веб-страница просто исчезнет, ​​что нарушит работу пользователя.

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

Параллельное исполнение

Многие разработчики, особенно те, кто в основном пишет более простые приложения с низким трафиком, имеют привычку использовать задания cron для фоновой обработки. Это нормально, пока размер ввода не станет настолько большим, что его нельзя будет очистить. Например, предположим, что у вас есть задание cron, которое компилирует аналитические отчеты и отправляет их пользователям по электронной почте, и что ваша система может обрабатывать 100 отчетов в минуту.

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

В системе очередей этой ситуации можно избежать, настроив несколько рабочих, каждый из которых может выбрать задание (каждый из которых должен выполнить 100 отчетов) и работать параллельно, чтобы завершить задачу намного быстрее.

Восстановление после сбоя

Обычно мы, веб-разработчики, не думаем о неудачах. Мы считаем само собой разумеющимся, что наши серверы и API, которые мы используем, всегда будут онлайн. Но в действительности все обстоит иначе — перебои в работе сети слишком распространены, а превосходные API, на которые вы полагаетесь, могут быть недоступны из-за проблем с инфраструктурой (прежде чем вы скажете «не я!», не забудьте о массовом отключении Amazon S3). Итак, возвращаясь к примеру с отчетами, если часть вашего отчета требует подключения к API платежей, и это соединение не работает в течение 2 минут, что произойдет с 200 отчетами, которые не удалось выполнить?

Однако системы массового обслуживания связаны со значительными накладными расходами. Кривая обучения довольно крутая, поскольку вы вступаете в совершенно новую область, сложность вашего приложения и развертывания возрастает, а задания в очереди не всегда могут контролироваться со 100% точностью. Тем не менее, бывают ситуации, когда создание приложения без очередей просто невозможно.

С этим покончено, давайте взглянем на некоторые из распространенных вариантов сегодняшних бэкендов/систем очередей.

Редис

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

Преимущества Redis:

• Полностью в памяти база данных, что приводит к более быстрому чтению/записи.
• Высокая эффективность: может легко поддерживать более 100 000 операций чтения/записи в секунду.
• Очень гибкая схема сохраняемости. Вы можете либо добиться максимальной производительности за счет возможной потери данных в случае сбоев, либо настроить полностью консервативный режим, чтобы пожертвовать производительностью ради согласованности.
• Кластеры поддерживаются из коробки

Обратите внимание, что в Redis нет абстракций обмена сообщениями/очередей/восстановления, поэтому вам нужно либо использовать пакет, либо самостоятельно собрать облегченную систему. Например, Redis является серверной частью очереди по умолчанию для PHP-фреймворка Laravel, где планировщик был реализован авторами фреймворка.

Изучить Redis легко.

RabbitMQ

Между Redis и RabbitMQ есть несколько тонких отличий, поэтому давайте сначала уберем их с дороги.

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

Если подумать, очереди задач также можно рассматривать как систему обмена сообщениями, в которой планировщик, рабочие и «отправители» заданий можно рассматривать как объекты, участвующие в передаче сообщений.

RabbitMQ имеет следующие преимущества:

• Улучшенные абстракции для передачи сообщений, сокращающие объем работы на уровне приложений, если передача сообщений — это то, что вам нужно.
• Более устойчив к сбоям и перебоям в подаче электроэнергии (по сравнению с Redis, по крайней мере, по умолчанию).
• Поддержка кластера и федерации для распределенных развертываний.
• Полезные инструменты для управления и мониторинга ваших развертываний.
• Поддержка практически всех нетривиальных языков программирования.
• Развертывание с помощью выбранного вами инструмента (Docker, Chef, Puppet и т. д.).

Когда использовать RabbitMQ? Я бы сказал, что это отличный выбор, когда вы знаете, что вам нужно использовать асинхронную передачу сообщений, но не готовы справиться с высокой сложностью некоторых других вариантов организации очереди в этом списке (см. ниже).

ActiveMQ

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

Вот где ActiveMQ превосходит:

• Он реализован на Java и поэтому имеет действительно аккуратную интеграцию с Java (соответствует стандарту JMS).
• Поддерживается несколько протоколов: AMQP, MQTT, STOMP, OpenWire и т. д.
• Управляет безопасностью, маршрутизацией, истечением срока действия сообщений, аналитикой и т. д. из коробки.
• Встроенная поддержка популярных шаблонов распределенного обмена сообщениями, экономящая ваше время и избавляющая от дорогостоящих ошибок.

Это не означает, что ActiveMQ доступен только для Java. У него есть клиенты для Python, C/C++, Node, .Net и других экосистем, так что опасений по поводу возможного коллапса в будущем быть не должно. Кроме того, ActiveMQ построен на полностью открытых стандартах, и создание собственных легковесных клиентов должно быть простым.

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

Амазонка MQ

Amazon MQ заслуживает краткого, но важного упоминания. Если вы считаете, что ActiveMQ — идеальное решение для ваших нужд, но не хотите заниматься созданием и обслуживанием инфраструктуры самостоятельно, Amazon MQ предлагает для этого управляемый сервис. Он поддерживает все протоколы, которые поддерживает ActiveMQ — в функциях нет никакой разницы — поскольку на самом деле он использует сам ActiveMQ.

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

Amazon SQS

Мы не можем ожидать, что Amazon будет молчать, когда речь заходит о критических элементах инфраструктуры, не так ли?

Итак, у нас есть Amazon SQS, который представляет собой полностью размещенную простую службу очередей (в буквальном смысле) от известного гиганта AWS. Опять же, тонкие различия важны, поэтому обратите внимание, что в SQS нет концепции передачи сообщений. Как и Redis, это простой сервер для приема и распределения заданий в очередях.

Итак, когда вы хотели бы использовать Amazon SQS? Вот несколько причин:

• Вы фанат AWS и больше ничего не будете трогать (честно говоря, таких людей много, и я думаю, что в этом нет ничего плохого).
• Вам нужно размещенное решение, поэтому убедитесь, что частота отказов равна нулю и ни одно из заданий не потеряно.
• Вы не хотите создавать кластер и должны контролировать его самостоятельно. Или, что еще хуже, вам придется создавать инструменты мониторинга, когда вы могли бы использовать это время для продуктивной разработки.
• Вы уже вложили значительные средства в платформу AWS, и сохранение ее имеет смысл для бизнеса.
• Вам нужна целеустремленная, простая система очередей без всякой ерунды, связанной с передачей сообщений, протоколами и прочим.

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

бобовый стебель

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

• Это строго система очереди заданий и ничего больше. Вы подталкиваете к нему рабочие места, которые позже получают работники. Так что, если ваше приложение имеет хоть малейшую потребность в передаче сообщений, вам следует избегать использования Beanstalkd.
• Нет сложных структур данных, таких как наборы, приоритетные очереди и т. д.
• Beanstalkd — это то, что называется очередью «первым пришел — первым обслужен» (FIFO). Расставить задачи по приоритету невозможно.
• Вариантов кластеризации нет.

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

Вывод

Если вы дочитали до этого места (или дошли до беглого чтения), то, скорее всего, вас интересуют системы очередей или они вам нужны. Если это так, список на этой странице будет вам полезен, если только вы не ищете систему очередей для конкретного языка/фреймворка.

Хотел бы я сказать вам, что организация очередей проста и надежна на 100%, но это не так. Это грязно, и так как все это происходит в фоновом режиме и происходит очень быстро (ошибки могут остаться незамеченными и стать очень дорогостоящими). Тем не менее, очереди крайне необходимы, и вы обнаружите, что они являются мощным оружием (возможно, даже самым мощным) в вашем арсенале. Удачи!