Решение для распределения МНОГО простых сетевых задач?

Я хотел бы создать своего рода распределенную установку для запуска тонны небольших/простых веб-запросов REST в производственной среде. Для каждого 5-10 связанных запросов, которые выполняются с узла, я создам очень небольшое количество полученных данных, которые необходимо будет хранить в стандартной реляционной базе данных (например, PostgreSQL).Решение для распределения МНОГО простых сетевых задач?

Какие платформы созданы для этого типа проблем? Природа, размеры данных и количества, похоже, противоречат мышлению Hadoop. Есть также больше архитектуры с сеткой, такие как Condor и Sun Grid Engine, о которых я уже говорил. Я не уверен, есть ли у этих платформ какое-либо восстановление от ошибок (проверка успешности задания).

Мне бы очень хотелось, чтобы была очередь типа FIFO, с которой я мог добавлять задания, с конечным результатом обновления моей базы данных.

Любые предложения по лучшему инструменту для работы?

источник

2010-05-01 EmpireJones

Звучит очень похоже на (проприетарную) программу мониторинга, которую я заканчиваю. Периодически он загружается с нескольких URL-адресов с настраиваемыми интервалами, анализирует и сохраняет результаты в базе данных PostgreSQL. Я реализовал это как одну программу на C++, которая поддерживает приоритетную очередь загружаемых заданий (на самом деле std :: map, потому что задания нужно вытащить, когда мониторинг отключен) и использует libcurl для выполнения загрузки. Я не рассматривал группировку результатов в основном потому, что программа мониторинга и база данных живут на одном сервере. Я действительно не использовал платформу, поэтому +1 :-) –

Вы посмотрели Celery?

источник

2010-05-01 08:23:19 drg

Проекты выглядят интересными, хотя и довольно молодыми. Я также не уверен в его надежности, основываясь на часто задаваемых вопросах: «Одна из причин, по которой очередь никогда не опорожняется, может заключаться в том, что у вас есть старый процесс сельдерея, который забирает сообщения в заложники. Это может произойти, если сельдерей не был должным образом закрыт». Кроме того, зависимость django вызывает раздражение: «Хотя можно использовать Celery вне Django, нам все равно нужно запустить Django, это использовать ORM и кеш-фрейм». – EmpireJones

@empirejones На самом деле этот раздел часто задаваемых вопросов больше не имеет отношения. Речь шла об удалении текущих ожидающих заданий в очереди. Работник может зарезервировать несколько заданий заранее (из-за подсчета предварительной выборки), если работник отключает соединение брокера, задания отправляются в другом месте (или тот же рабочий, если он снова подключается). Связанные ошибки теперь исправлены, это превращает это в проблему с многопроцессорной обработкой и forking. – asksol

Решение для распределения МНОГО простых сетевых задач?

ответ

Смежные вопросы