Не знает ли кто-нибудь? Распространенные системы управления очередями не умеют (ну или я не дочитываю мануал) двух вещей, которые иногда бывают очень полезными: а) иногда заявки на один и тот же объект могут накапливаться и быть обработанными все вместе (то есть например по объекту пришло три уведомления об изменении, обработчик обновляет объект до текущего состояния и тогда можно закрыть все три заявки. В существующих системах тебя вызовут три раза и максимум что ты можешь сделать — это быстро понять, что обновления уже применены и быстро закрыть заявку). NB: если за время выполнения заявки пришло еще уведомление, то обработчик должен быть вызван еще один раз.
б) batch-batch-обработка, то есть обработчик получает N заявок, а потом возвращает список тех, которые он обработал успешно, остальные будут повторены другими воркерами. ‎- псы в рапиде
Проблема в том, что по любым ключевым словам, которые я могу придумать, поисковая выдача понятным образом засорена. ‎- псы в рапиде
я знаю, как сделать это на чистой транзакционной реляционке с optimistic locking, но вообще считается, что реляционка — плохой выбор для масштабируемого queueing. ‎- псы в рапиде
б) в nsq есть. клиент получает управляемые N мессаг с сервера, которым он по мере обработки делает finish или requeue. если он отваливается или тупит дольше таймаута, nsq делает за него requeue сам. (+ клиент может сделать touch, который значит "я ещё не, но работаю над этим, не надо таймаут)" ‎- смешная третья опция
a) понятно почему нигде нет. это значит добавлять identity сообщениям и scalable индекс по нему. либо ты можешь это себе позволить, и делаешь всю очередь ручками в реляционке, либо нет и дедупликацию делаешь опять же сам, в окне из б) ‎- смешная третья опция
[смутно кажется, что в rabbitmq б) тоже было, потому что я ещё в хх делал то как у тебя описано, в окне, и очередь была на раббите Upd: открыл сурцы и ха-ха, хер там, раббит мы выкинули и сделали свою очередь] ‎- смешная третья опция
@earwin: спасибо! проглядел кратко http://nsq.io/, какие-то странные у него guarantees, я к таким не привык! ‎- псы в рапиде
@kuchin: м? это просто текст с обзорным сравнением десятка стандартных решений, ничего про мой вопрос я там не нашел. плохо искал? ‎- псы в рапиде
Мне из моего несколько архаичного опыта кажется что и 1 и 2 из коробки не задача очереди, а уже какого фреймворка над ней. В принципе и 1 и 2 можно сделать поверх очереди либо средне масшатбируемо с РДБМС и хорошо масштабируемо с какой-то NoSQL но с какой и как тут я не знаю. ‎- Все собаки попадают в рай
мне кажется они на этом уровне ничего про объекты не знают, там только сообщения. активация может быть либо edge либо level trigerred. если тебя интересует только последний апдейт объекта, то есть структуры данных для этого, например такое используется при апдейтах price-tickers. я правильно понимаю? ‎- big data in petite analysts
Иначе, возможна ситуация когда обработчик не слезает с очереди, поскольку все время получает апдейты. мне кажется с точки зрения производительности никакого выигрыша не будет. Правильный способ решить эту проблему кмк и на стороне pub и на стороне sub, один loop наполняет структуру данных, обновляя объекты на месте, это гарантирует что там всегда последний апдейт, другой отсылает сообщения, то же самое возможно на стороне клиента. все это релевантно когда количество апдейтов на одну и ту же структуру действительно большое — делим обработчик на две части: одна обновляет структуру на каждый мессадж, реальный обработчик объектов (обычно он дороже) читает из нее ‎- big data in petite analysts
поправь, если я не правильно тебя понял ‎- big data in petite analysts