Имитация очереди задач Google Appengine с Gearman

Question

Одна из характеристик, которые мне больше всего нравятся в Очередь задач Google, - ее простота. В частности, мне нравится, что для выполнения задачи требуется URL-адрес и некоторые параметры, а затем сообщения на этот URL-адрес.

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

Моя цель состоит в том, чтобы очередь задач была независимой от базы кода, чтобы я мог нажать новую живую версию без перезапуска любых рабочих. Итак, я подумал: почему бы не сделать задачи исполняемыми по URL-адресу так же, как очередь задач с движком Google?

Этот процесс будет работать следующим образом:

1. запрос пользователя приходит и запускает несколько задач, которые не должны быть блокирующие.
2. Каждая задача имеет уникальный URL-адрес, поэтому я устанавливаю задачу ретранслятора POST на указанный URL.
3. Сервер ретранслятора находит работника, передает URL-адрес и отправляет данные работнику
4. Рабочий просто отправляет URL-адрес с данными, тем самым выполняя задачу.

Предположим следующее:

1. Каждый запрос от Gearman работника подписывается как-то так, что мы знаем, что приходит с сервера Gearman и не злонамеренный запрос.
2. Задачи ограничены работать менее чем за 10 секунд (Там не было бы долго задач, которые могли бы тайм-аут)

Каковы потенциальные недостатки такого подхода? Вот один, что меня беспокоит:

• Сервер потенциально может получить молотком с большим количеством запросов всех сразу, показываемых по предварительному запросу. Таким образом, один пользовательский запрос может повлечь за собой 10 одновременных HTTP-запросов. Полагаю, у меня мог бы быть один рабочий со сном перед каждым запросом на ограничение скорости.

Любые мысли?

Answer 1

Как пользователь как Django, так и Google AppEngine, я, безусловно, ценю то, что вы получаете. На работе я в настоящее время работаю над тем же самым сценарием, используя некоторые довольно интересные инструменты с открытым исходным кодом.

1. Посмотрите на Celery. Это распределенная задача, построенная с помощью Python, которая предоставляет три концепции: очередь, набор рабочих и хранилище результатов. Он совместим с различными инструментами для каждой части.

2. Очередь должна быть ожесточенной и быстрой. Проверьте RabbitMQ на отличную реализацию очереди в Erlang, используя протокол AMQP.

3. Рабочие в конечном счете могут быть функциями Python.Вы можете вызвать работников с использованием либо очереди сообщений, или, возможно, более уместно, что вы описываете - используя webhooks

Заканчивать документацию Celery webhook. Используя все эти инструменты, вы можете создать готовую распределенную очередь задач производства, которая будет выполнять ваши требования выше.

Следует также упомянуть, что в отношении вашей первой ловушки сельдерей реализует ограничение скорости выполнения задач с использованием алгоритма Token Bucket.