А как он залочится то?

ну он набирает задачи пока не кончится очередь, либо пока не попадётся задача для пользователя для которого он обрабатывает

типа поддерживает set множество пользователей которые в данный момент обрабаытваются

Ну а если второй комп параллельно выгребает?

И u1-2 выполнится раньше чем u1-1

на втором компе будут только воркеры-подзадач

то есть u1-1,u2-1,u3-1,u4-1 обработаются параллельно потом u1-2, потом u1-3,u2-2

Не, чёт сильно плохо с горизонтальным масштабированием в этой схеме

ну с блокировками всегда так себе с горизонтальным масштабированием

Ладно, сделаю без ack

И будет норм

Вангую

А чуть что - буду делать свой кролик

тогда если воркер умрёт, задача потеряется

Не потеряется

Я имел ввиду с ack но без лока

Т.е. 100 воркеров = 100 каналов

Хотя, нахрена тут акк

Если все равно будет слишком поздно

Ладно, посмотрим

Потеряется - и хрен с ним

Значит пользователь не кликнул куда-то)

Вроде для кролика был плагин sharding exchange, но я не помню, что в нем с ребалансом

хорошая идея конечно для аггрегирующего плагина

Вопрос, здесь говорили о cachex, а никто не сравнивал его случайно по скорости с con_cache?

@Virviil а у тебя опыта с tarantool нет? у них в модуле очередей, кажется, есть то, что тебе нужно https://github.com/tarantool/queue#utube---a-queue-with-sub-queues-inside

кажется даже в точности твой кейс

Выглядит похоже

Почему луа блять

Ничего не понятно

Lua - можно освоить за 1-2 дня. Он один из самых простых языков программирования.

(Если уже умеешь программировать)

у меня скорее сам тарантул бы вызвал вопросы

я не сомневаюсь, что он очень крутой, но его все же желательно понимать

а "понимать" это заметный порог вхождения для любой бд

Может быть я когда нибудь делаю на тарантуле все это

Но пока что хрен с ним )

Я просто представляю глубину жопы, в которую меня отправит devops ))

ну вот я так же облизываюсь на него, но всерьез рассматривать не получается

Его очень круто юзать в качестве быстрых очередей

для разного рода CPA или тизерных сетей

Он отлично живет как сервер приложений, удобно некоторую логику скидывать именно на него

меня тянет на нем сделать кастомные очереди на замену тому, что у нас есть, но все равно много работы нужно

Достаточно просто поставить и заюзать на мелкой задаче)

несмотря на все плюшки в коробке, работы много понадобится

Если не будет от этого никакого профита.. то надо ли)

"работает? не лезь))"

Лучше новое писать или переписывать реально нужное

в том и дело, что переписывать действительно нужно

и tnt выглядит очень привлекательной платформой

но все равно инвестиции очень солидные получаются

Есть такой плюс, как работа с этой самой очередью в фоне

если такое надо

Смотря откуда данные берутся и т.д.

А как там передаются данные?

Через бинарный протокол и сокет?

Вроде http было

надо глянуть реализации

Http?

Так на самом протоколе вся скорость потеряется

Не может быть

http можно, но вообще там свой протокол

В rmq я упаковал erlang term to binary

И получил

Без всяких лишних

Кайф короче

Мне кажется там должно быть тоже самое

Иначе не имеет смысла

Да, там по всякому можно

он и сам свой http сервер умеет делать

а так по tcp слушает

Я гоню, http было не с ним))

это я с кликхаусом так работал

Там вот что весело.. ты можешь запустить в отдельном потоке функцию, которая будет цепляться к mysql, доставать данные, обрабатывать их и складывать к себе. Потом ты по ним можешь телать быстрые поиски и всю фигню

Если у тебя тизерка, то это прям супер

особенно в фоне обновлять веса тизеров в момент их доставания. Там такая адовая скорость, что ни одна другая база так не сделает

а вот еще недавно делали решение.. куча запросов по API, надо делать валидацию запроса на уникальность кучей способов

> запустить в отдельном потоке функцию ну все же не потоке, а файбере

да)

но хуже от этого не становится, конечно

сам факт, что оно работает))

Так вот, мы хранили все запросы за месяц в тарантуле

он сам их удалял

но поиск делали в начале по тупому, каждый раз создавая запрос.. там штук 300-500 было в него за 1 сек

и это из php

потом переписали на функцию в lua и тупо скармливаем ей сам запрос

за 0,0000 отдает ответы)))

просто сказка))

Нагрузка растет, а мы отдыхаем)

я сонный и уставший после работы)) а уже ночь, поэтому всякую хрень пишу))

В rmq я упаковал erlang term to binary

так tnt-queue тоже вроде пофиг, что ты в payload положишь

Просто с точки зрения эффективности связка JS/React очень выигрывает с аналогичными решениями

Скорее всего выигрывает связка JS/Vue уж очень много проектов на vue