LINUX.ORG.RU

Посоветуйте сервер очередей

 , , , ,


0

2

Есть крупный проект. До какого-то времени очереди хранились в БД MySQL, но сейчас в очереди пишутся такие объемы данных, что БД лочится, собственно, от одних очередей. Чтобы было понятнее - речь идет о миллионах записей. Каждую минуту/декаминуту/час/день добавляются или удаляются тысячи записей.

Я начал переходить на Gearman, перевел небольшую часть проекта на него, но сейчас мне кажется, что это было не правильным решением. Вот мои основные претензии:

  • Три уровня приоритезации, которые предоставляет Gearman, все таки, не хватает. В некоторых очередях у нас доходило до 10 уровней.
  • Самая большая для меня проблема - дублирующиеся задачи. В гирмен можно напихать сколько угодно однотипных, одинаковых задач, при чем, даже с одинаковым ID! В последнем случае, правда, при выполнении одной из задач с одинаковым ID сразу «выполняются» и все остальные задачи с таким же ID, но все равно, это не подходит, т.к. таких задач может скопиться десятки тысяч.

Это мои основные проблемы, остальное, в общем-то, не критично.

Короче, мои основные требования к серверу очередей:

  • Возможность работать из PHP
  • Гибкая настройка приоритезации
  • Задачи должны быть только уникальные

Что можете посоветовать?

Deleted

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

foozzi ★★★ ()
Ответ на: комментарий от foozzi

А с дублирующимися задачками ни как не боролся? Хотя, возможно, такой проблемы у тебя и вовсе не было =(

Deleted ()

Советую остаться на скуле, и-таки вкурить в реорганизацию/доп.индексирование. Тысячи записей в минуту - это не предел.

bvn13 ★★★★★ ()
Ответ на: комментарий от Deleted

Откуда они у вас там вообще появляются? И, скажем так, сервер очередей это то что сообщение от одного компонента доставит другому (другим) компонентам. Оно не должно следить за приоритетами, дублями и вот этим всем, вы должны решать это на стороне своего приложения. Или же если это делает сервер то вы получите просадку производительности по сравнению с «глупыми» реализациями.

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

micronekodesu ★★ ()
Ответ на: комментарий от bvn13

почитай, а вообще еще вспомнил что юзал! это rabbitmq! Вот!

foozzi ★★★ ()

почитайте про кролика, про эрланг, может понравится, подойдет

anonymous ()

а Gearman что использует в качестве хранилища задач, не MySQL разве? Или у тебя все в памяти?

anonymous ()

Достаточно вбить в гугл Gearman и он сам предложит RabbitMQ, ZeroMQ, Redis без всяких лоров

Если ты такой крутой ставь 64гб озу и загоняй туда heap таблицы без шума и пыли

Eof ()

Несколько вариантов:

1. Писать свои очереди на Redis. Можно легко масштабировать объединяя в кластеры.

2. Использовать nats https://nats.io/about/ - поставил вторым вариантом, так как сам лично не использовал, но от друзей очень хорошие отзывы по нему. Если верить тестам с офф сайта, то он обходит redis в 2 раза.

3. Использовать Колоночные базы данных, типа Vertica - этот вариант 'самый не очень'. Обычно в колоночных БД производительность высокая при одновременной вставки скажем миллиона записей, атамаризация скорее всего негативно скажется на производительность. Тут нужно исходить из потребностей и возможностей.

xSudo ★★★ ()
Последнее исправление: xSudo (всего исправлений: 1)
Ответ на: комментарий от Deleted

Это да, только оно, по сути, либа, на которой нужно свой сервер строить.

micronekodesu ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.