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


Системы массового обслуживания – лучший секрет серверной разработки.

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

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

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

Что такое система массового обслуживания?

Давайте начнем с понимания, что такое очередь.

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

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

Зачем вам системы очередей?

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

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

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

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

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

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

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

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

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

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

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

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

Redis

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

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

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

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

Обучение Редис это просто.

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 и т. Д.)

Amazon 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 был в течение долгого времени и является испытанным в бою, быстрым и легким бэкэндом для очередей на работу. Есть несколько характеристик Beanstalkd, которые отличают его от Redis:

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

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

Вывод

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

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

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me