Когда использовать очередь сообщений и когда использовать облачный фоновой рабочий

Когда я буду использовать очередь сообщений, такую как ironMQ, и когда я буду использовать сотрудника по обработке заданий, например ironWorker?

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

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

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

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

Ответ 1

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

Вы должны использовать IronMQ, если хотите запустить процессы/серверы-потребители/рабочие.
Вы должны использовать IronWorker, если хотите Iron.io заботиться о процессах/серверах для потребителей/рабочих. Вы также получаете кучу других функций/преимуществ, используя IronWorker, а не только тот факт, что вам не нужно управлять своими собственными серверами и масштабировать их и т.д.

Нет, вам не нужна очередь сообщений, если вы используете IronWorker, потому что IronWorker - это ваша очередь сообщений + ваша обработка этой очереди.

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

Ответ 2

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

Сделать API на сервере центра обработки проверок; требует, чтобы человеческие ресурсы писали API-код, API и клиент на стороне магазина должны быть безотказными (заказы должны быть доставлены в центр обработки).
Поместить проверки в БД с сервера магазина, получить их на сервере обработки; он требует доступа к одному и тому же БД из магазинов и процессингового центра, который иногда недостаточно безопасен. Обратите внимание, что использование отдельного сервера БД должно действовать как очередь сообщений. Он должен быть масштабируемым, поэтому мне нужно тратить деньги на инфраструктуру и администратора.
Отправить в очередь сообщений из магазина, получить из очереди сообщений с другой стороны; требуется установка службы очереди сообщений и поддержка инфраструктуры.

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

То же самое для систем IronWorker и т.д. для асинхронной обработки. Например, если у меня есть небольшое приложение, я могу делать такие задания прямо на моем сервере. Это требует только специальной библиотеки. В случае с средним приложением я могу настроить сервер и установить программное обеспечение для обработки асинхронных задач. Если у меня огромное приложение с множеством задач, оно требует поддержки масштабируемой инфраструктуры, балансировки нагрузки задач и т.д.

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