Стратегия разгрузки для более длительных задач в экспресс-маршрутах

Question

У меня есть приложение, которое использует Express как ориентированную на пользователя инфраструктуру для моего REST API, а также RabbitMQ для вызовов функций, подобных RPC, в кластерный бэкэнд. Кроме того, я использую Q, чтобы обещать всю свою рабочую нагрузку в Маршрутах.

В одном из маршрутов, которые я использую, я запускаю некоторые функции, которые сканируют URL-адрес, указанный в параметрах маршрута, выполняет поиск по GeoIP, нормализует форматы результатов и т. Д. Это может занять несколько секунд в зависимости от времени ответа отсканированные URL-адреса серверов.

То, что я хотел бы достичь, заключается в том, что пользователь, который отправляет новый URL-адрес для обхода, получает немедленную обратную связь с его запросом (статус 200 = «Обходной запрос подтвержден»), и не имеет запроса, ожидающего завершения обхода ,

Мои идеи либо

• Отправка URL в определенной очереди в RabbitMQ, и есть другой способ, чтобы слушать на работу очереди по
• Используя что-то вроде дочерних процессов внутри Маршруты Экспресс

Что было бы лучшим решением для решения этой проблемы? Спасибо за ваш ценный вклад.

Answer 1

Очень загруженный вопрос с множеством опций, каждый из которых имеет свои собственные воздействия на общую систему. Не уверен, есть ли ответ . Это действительно вопрос предпочтения и того, с чем вам комфортно. ИМО, я постараюсь, чтобы все было просто. Добавление другого процесса (RabbitMQ) означает другой пакет программного обеспечения (или даже весь сервер) для управления, настройки, разрешения и безопасности.

Несколько вещей, чтобы рассмотреть. Является ли основная часть обрабатываемых операций ввода-вывода привязана или связана с ЦП? Если вы используете удаленный сервис для выполнения запросов GeoIP, это может быть больше ограничений ввода-вывода, которое идеально подходит для узла. Почему бы не иметь узел просто обрабатывать все через:

process.nextTick(function() { 
    // Do your lookup here 
} 

res.status(201).end(); 

Затем используйте что-то вроде socket.io отправить результаты клиенту асинхронно?

В любом случае, я бы рекомендовал возвращающую 202 - Accepted, а не 200.