Comments 9
Когда то давно немного работал с gearman. Осталось ощущение, что он больше подходит для задач rpc, нежели для создания полноценных очередей.
Тормозит на новых ядрах линукс, и похоже, проект забросили…
Умеет ли Gearman работать с отложенными сообщениями? Например есть задача, для выполнения которой нужно отправить по API n запросов и каждый этап занимает, ну допустим минуту. Нет смысла долбиться по API постоянно. Здесь вот было бы самое то использовать отложенные сообщения.
Если не трудно, можете рассказать почему выбрали именно Gearman, а не ActiveMQ или RabbitMQ?
Если не трудно, можете рассказать почему выбрали именно Gearman, а не ActiveMQ или RabbitMQ?
1) время выполнения задач для Gearman некритично. Я не очень понял вашу задачу, но мне кажется, что в данном случае Gearman решит ваши проблемы. Напишите подробнее мне в личку, думаю, что помогу вам
2) я начал работать в проекте, в котором был выбран именно Gearman. Убедился, насколько это простой и хороший инструмент, и далее в своих проектах использовал именно Gearman. Для него не хватало оболочки — именно то, о чем публикация. Я написал оболочку и далее о выборе инструмента не задумывался.
Несколько раз смотрел RabbitMQ, но, мне кажется, он много сложнее в использовании.
Проблема Gearman в том, что работать с ним под Windows — на том же DenWer или OpenServer — очень неудобно. У меня есть в планах написать библиотеку, которая будет заменять классы GearmanWorker(), GearmanClient().
2) я начал работать в проекте, в котором был выбран именно Gearman. Убедился, насколько это простой и хороший инструмент, и далее в своих проектах использовал именно Gearman. Для него не хватало оболочки — именно то, о чем публикация. Я написал оболочку и далее о выборе инструмента не задумывался.
Несколько раз смотрел RabbitMQ, но, мне кажется, он много сложнее в использовании.
Проблема Gearman в том, что работать с ним под Windows — на том же DenWer или OpenServer — очень неудобно. У меня есть в планах написать библиотеку, которая будет заменять классы GearmanWorker(), GearmanClient().
Да зачем в личку, думаю раз тема о очередях и их реализациях, всем будет интересно. Мне по крайней мере была бы интересна такая дискуссия, если бы кто-то её вёл.
Более подробный пример: нам нужно совершить платёж. Мы отправляем сообщение в очередь, его получает воркер и делает запрос по API. На данном этапе платёжный шлюз только проверяет указанные данные. И проверяет он их допустим минимум 5 минут. Если мы после отправки первого запроса тут же отправим второй — «ну что там, как данные, годятся?» то мы получим ответ — «нет, жди ещё». И так все эти 5 минут.
Решение — нужно эти 5 минут ждать и не отправлять запросов. Это может быть реализовано например через крон, выгребать например записи из базы, фильтруя по какому-то признаку, или это может быть реализовано встроенными средствами брокера.
Вот я имел в виду — есть ли какие-то встроенные средства для этого?
В своё время когда выбирали брокер, я не нашёл таких средств, в RabbitMQ про это писали, что решается костылями, и устроил в итоге только ActiveMQ, там можно указать в заголовке время, через которое отправленное сообщение попадёт в очередь.
А сейчас стало любопытно, корректно ли я интерпретировал ситуацию с продуктами.
Более подробный пример: нам нужно совершить платёж. Мы отправляем сообщение в очередь, его получает воркер и делает запрос по API. На данном этапе платёжный шлюз только проверяет указанные данные. И проверяет он их допустим минимум 5 минут. Если мы после отправки первого запроса тут же отправим второй — «ну что там, как данные, годятся?» то мы получим ответ — «нет, жди ещё». И так все эти 5 минут.
Решение — нужно эти 5 минут ждать и не отправлять запросов. Это может быть реализовано например через крон, выгребать например записи из базы, фильтруя по какому-то признаку, или это может быть реализовано встроенными средствами брокера.
Вот я имел в виду — есть ли какие-то встроенные средства для этого?
В своё время когда выбирали брокер, я не нашёл таких средств, в RabbitMQ про это писали, что решается костылями, и устроил в итоге только ActiveMQ, там можно указать в заголовке время, через которое отправленное сообщение попадёт в очередь.
А сейчас стало любопытно, корректно ли я интерпретировал ситуацию с продуктами.
Не очень правильно называть Gearman сервером очередей, ему больше подходит определение Сервер Задач. В отличие от классических, всем известных RabbitMQ и ActiveMQ, Gearman создавался именно как решение для распределенного выполнения задач, а не как решение по доставке сообщений от одного компонента к другогому. В Gearman вы можете передавать воркерам весь payload, когда в RabbitMQ вам пришлось бы использовать дополнительное хранилище как контекст, иначе бы получили переполнение оперативной памяти и деградацию сервиса.
Sign up to leave a comment.
Сервер очередей Gearman: опыт практического использования и веб-приложение Gearman Monitor && Control