Комментарии 40
Назначение Gearman и Capistrano пересекается хотя бы отчасти?
К сожалению не знаком с Capistrano чтобы точно сказать, но на первый взгляд — Capistrano более готовое решение, нацеленное на запуск скриптов на множестве серверов — такое легко реализуется через Gearman. Всё же Gearman продукт гораздо более широкого профиля.
По-моему Capistrano и Gearman могут хорошо использоваться в связке. Capistrano будет централизовано заливать новые версии исполнителей, убивать старые и запускать новые, то есть отчасти нивелирует основной недостаток Gearman.
Подробнее об использовании HTTP в gearman можно почитать здесь.
Где?
А вообще интерсная статья, спасибо, надо покопаться поглубже в продукте. Вопрос сразу возник — контроль за запуском/убийством исполнителей от самого Gearman не зависит? То есть реализовывать запуск исполнителя и его убийство после 1000 запросов во избежание ликов придётся внешними средствами? И ещё один — для асинхронных задач предусмотрена только потеря ответа — передача его куда-нибудь (параметром к другой задаче) не предусмотрена?
Ступил что-то насчёт первого вопроса, на разных же серверах процессы крутятся. Можно, конечно, и удалённый запуск реализовать, но не unix way.
Линк добавил, спасибо.
Да, связи между исполнителями и сервером, кроме как приём-отправка задач — нет, тоесть контроль жизни worker'а полностью в Ваших руках. Естественно никто не мешает реализовать это в виде отдельной задачи :).
И опять да, асинхронные задачи не подразумевают под собой дальнейшей работы с резултатом, но опять таки, можно вызвать из самого испольнителя ещё одну задачу с результатом, либо передать этот результат куда-нибудь ещё.
Да, связи между исполнителями и сервером, кроме как приём-отправка задач — нет, тоесть контроль жизни worker'а полностью в Ваших руках. Естественно никто не мешает реализовать это в виде отдельной задачи :).
И опять да, асинхронные задачи не подразумевают под собой дальнейшей работы с резултатом, но опять таки, можно вызвать из самого испольнителя ещё одну задачу с результатом, либо передать этот результат куда-нибудь ещё.
Поддержку нужного количества исполнителей удобно реализовывать через supedvisord. Управляет он только локальными процессами, но там есть некоторые средства расширения, возможно получится сделать все что вы хотите.
Выйти исполнитель может и сам, счетчик в цикле приема задач поставить дело недолгое.
Выйти исполнитель может и сам, счетчик в цикле приема задач поставить дело недолгое.
Примерно для такой же задачи я реализовывал механизм распределения задач по алгоритмуround-robin
Но мне необходим был полный контроль за процессом выполнения задания.
Нужен был пользовательский интерфейс для настройки так называемых цепочек выполнения.
Тогда мне почему не попался на глаза этот фреймворк.
Надо будет поковырять его.
Спасибо за наводку:)
Но мне необходим был полный контроль за процессом выполнения задания.
Нужен был пользовательский интерфейс для настройки так называемых цепочек выполнения.
Тогда мне почему не попался на глаза этот фреймворк.
Надо будет поковырять его.
Спасибо за наводку:)
Когда встал выбор сервера задач/очередей выбрал для себя Starling, т.к. он легковесный, поддерживает Memcache протокол, и клиенты есть во всех языках. Можно воркера хоть на чём писать. И ещё он очень быстрый. Но он конечно, не так наворочен, как Gearman. Нет приоритета задач, например.
Gearman это не только сервер очередей, но и средство распределения работы. С помощью него достаточно удобно распараллеливать задачи аля Map/Reduce.
Да, согласен. Я и написал, что он не так наворочен как Gearman. Кстати, есть ещё Hadoop (это что касается Map-Reduce). Вообще, мне кажется надо выбирать исходя из ситуации и требований.
Согласен, и протокол memcached это удобно. Кстати насчет легковесности и скорости у gearman тоже все хорошо, сишный сервер кушает отсилы несколько мегабайт вместе с памятью на задачи и обрабатывает миллионы задач в день (например в Yahoo 6 миллионов задач в день проходит через gearman, в ЖЖ не знаю точно думаю порядок тот же).
Отдельное спасибо за подробное описание минусов.
Кучу времени сэкономлено.
Кучу времени сэкономлено.
Хочется акцентировать внимание ещё на нескольких моментах:
1. gearman ещё и неплохое средство failover'a: ничто не мешает клинтской части ходить на несколько gearman серверов, ничто не мешает каждому воркеру зарегистрироваться на нескольких серверах. Ничто не мешает одни и те же воркеры запускать сразу на нескольких машинах. Ничто не мешает воркеру «браться за работу» только если есть ресурсы (воркер должен «забрать задачу», сервер только посылает уведомления о наличии задачи). И всё это вместе чудесно работает. Таким образом «с полпинка» реализуется отказоустойчивость всех используемых компонентов с довольно гибким распределением нагрузки — отказ или повышенная загрузка любого одного узла никак не влияет на работу системы в целом.
2. Данные, которые передаются воркеру (и обратно) — это по сути дела одна огромная JSON-encoded строка (успешно передавал ~100MB данных, прекрасно пропускает). Что в свою очередь накладывает некий overhead.
3. Для синхронных задач — это далеко не самое лучшее средство. Всё происходит всё-таки довольно неспешно. Задачи, где критично время отклика я бы рекомендавал распределять как-то иначе. Всю свою прелесть оно проявляет на задачах где надо «отдать кому-нибудь и пусть оно где-то отработает, где есть кому это сделать, а мы пока дальше пойдём».
4. Великолепная на мой взгляд фича (хоть и не для всех задач) на синхронных задачах (частично упоминалось выше): если два клиента пришлют одинаковый запрос — он будет выполнен только один раз, НО результат получат оба, что при определённых условиях может сэкономить море ресурсов.
1. gearman ещё и неплохое средство failover'a: ничто не мешает клинтской части ходить на несколько gearman серверов, ничто не мешает каждому воркеру зарегистрироваться на нескольких серверах. Ничто не мешает одни и те же воркеры запускать сразу на нескольких машинах. Ничто не мешает воркеру «браться за работу» только если есть ресурсы (воркер должен «забрать задачу», сервер только посылает уведомления о наличии задачи). И всё это вместе чудесно работает. Таким образом «с полпинка» реализуется отказоустойчивость всех используемых компонентов с довольно гибким распределением нагрузки — отказ или повышенная загрузка любого одного узла никак не влияет на работу системы в целом.
2. Данные, которые передаются воркеру (и обратно) — это по сути дела одна огромная JSON-encoded строка (успешно передавал ~100MB данных, прекрасно пропускает). Что в свою очередь накладывает некий overhead.
3. Для синхронных задач — это далеко не самое лучшее средство. Всё происходит всё-таки довольно неспешно. Задачи, где критично время отклика я бы рекомендавал распределять как-то иначе. Всю свою прелесть оно проявляет на задачах где надо «отдать кому-нибудь и пусть оно где-то отработает, где есть кому это сделать, а мы пока дальше пойдём».
4. Великолепная на мой взгляд фича (хоть и не для всех задач) на синхронных задачах (частично упоминалось выше): если два клиента пришлют одинаковый запрос — он будет выполнен только один раз, НО результат получат оба, что при определённых условиях может сэкономить море ресурсов.
Ничто не мешает воркеру «браться за работу» только если есть ресурсы (воркер должен «забрать задачу», сервер только посылает уведомления о наличии задачи).
Важный нюанс — завтра точно пойду копаться в рабочее время!
Не понял, что произойдет если воркер взял задачу в обработку и упал на полпути?
Что будет с «плохой» задачей? Будет ли она отмечена как обработанная?
Если нет, то вернется ли она в очередь?
Если вернется, то как скоро и с каким приоритетом? На прежнее место или в конец? Не тормознет ли «плохая» задача всю очередь?
Как работают приоритеты? Сначала будут выполнены все задачи с высоким приоритетом, затем с низким, или есть какое-то чередование (2 с высоким, 1 с низким)?
Есть ли возможность перезапустить задания за определенный интервал времени?
Что будет с «плохой» задачей? Будет ли она отмечена как обработанная?
Если нет, то вернется ли она в очередь?
Если вернется, то как скоро и с каким приоритетом? На прежнее место или в конец? Не тормознет ли «плохая» задача всю очередь?
Как работают приоритеты? Сначала будут выполнены все задачи с высоким приоритетом, затем с низким, или есть какое-то чередование (2 с высоким, 1 с низким)?
Есть ли возможность перезапустить задания за определенный интервал времени?
Возможность потери задачи сведена к минимуму, она может покинуть сервер только в случае успешного выполнения, тоесть если воркер с задачей упал, воркер выкидывается (по таймауту) из пула, а задача возвращается в начало очереди. Приоритет не поменяется.
Общие приоритеты, на сколько я знаю, работают топорно — сначала высокий приоритет — потом низкий.
Вот возможность таймаута на задачу меня в своё время тоже интересовала, так как в документации ничего про это сказанно не было — полезли в код. И судя по всему они хотели это сделать, но так и не реализовали на данный момент :).
Общие приоритеты, на сколько я знаю, работают топорно — сначала высокий приоритет — потом низкий.
Вот возможность таймаута на задачу меня в своё время тоже интересовала, так как в документации ничего про это сказанно не было — полезли в код. И судя по всему они хотели это сделать, но так и не реализовали на данный момент :).
задача возвращается в начало очереди
Вот это и смущает. Получается, что несколько проблемных задач в начале очереди застопорят последующие задачи.
Только для того же воркера. Остальные будут работать как обычно.
У сервера есть событие, которое отсылается клиенту в случае ошибки на стороне воркера. У задания есть уникальный идентификатор. Можно посчитать количество перезапусков.
Вот только я не знаю, как убрать задание из очереди. Это надо документацию перечитывать.
У сервера есть событие, которое отсылается клиенту в случае ошибки на стороне воркера. У задания есть уникальный идентификатор. Можно посчитать количество перезапусков.
Вот только я не знаю, как убрать задание из очереди. Это надо документацию перечитывать.
Только для того же воркера. Остальные будут работать как обычно.
Я про ситуацию, когда проблемных заданий больше чем воркеров.
Не может получиться так, что воркер после перезапуска снова возмет проблемную задачу, которая вернулась в начало очереди?
Так и будет. Воркер (необязательно именно тот же) будет брать задачу до тех пор, пока не будет достигнуто определенное число попыток.
Полистал доку. У севера есть параметр
Полистал доку. У севера есть параметр
-j (--job-retries), который регулирует количество повторных попыток. Работает глобально, что не всегда удобно.На сколько я помню, можно было задаче указать статус WORK_FAIL — и она просто будет отмечена как выполненая, но неуспешно. Только поддерживалось это не во всех клиентах на момент моих изысканий :). У них там в документации подробно расписан протокол и там есть много интересных вещей, которые я так понимаю ещё планируются к реализации, по примеру выше обсуждаемого job-timeout — CAN_DO_TIMEOUT.
На самом деле, я бы не стал сильно расчитывать на интеллектуальность распределения задач, по логике разработчиков, такие вещи лучше контролировать извне, ибо тут действительно — всем угодить очень сложно.
открытый вариант платного DataSynapse получается пишут
Для отладки чуть-чуть помогает mod_gearman под апач (если, конечно, он у вас есть).
В принципе управляющий протокол там не сложный, текстовый. Можно накидать простенький монитор используя всего две команды (status, workers), чтобы следить за тем, кто и что выполняет.
В принципе управляющий протокол там не сложный, текстовый. Можно накидать простенький монитор используя всего две команды (status, workers), чтобы следить за тем, кто и что выполняет.
А клиент при асинхронной задаче как-то оповещается о выполнении? Есть ли какой-то колбек?
Чем хуже/лучше Rabbit/Activq MQ?
Я тоже хотел бы знать ответ на последний вопрос: Чем хуже/лучше Rabbit/Activq MQ?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Gearman – фреймворк для распределения задач, введение