Фоновые процессы для заданий, с которыми сталкивается пользователь?

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

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

Является ли это жизнеспособным использованием фоновых работников или их следует использовать только в тех случаях, когда пользователь не ждет результатов немедленно (например, отправка электронных писем)?

Это лучший способ спроектировать это приложение?


ruby ruby-on-rails background-process delayed-job resque
person David Tuite    schedule 21.03.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

На мой взгляд, это идеальный вариант использования комбинации WebSockets и реакторная структура, такая как EventMachine или node.js.

Почему веб-сокеты?

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

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

Почему каркас реактора?

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

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

Подводя итог: использование фреймворка Reactor + WebSockets не только улучшит пользовательский опыт, но и упростит реализацию. Ознакомьтесь с библиотекой socket.io для node.js: она должна позволить реализовать ваш вариант использования в дюжине строки кода или около того.

person psyho    schedule 23.03.2012