AA
Он не обеспечивает последовательность же
Size: a a a
2021 April 23
МБ
можно сделать по одному консьюиеру на очерердь
AA
Тоже думаю
МБ
где-то я видел пример как разруливать сообщения разных типов по конкретным консьюмерам
ЯК
через ProducerConsumer?
IK
Вы видно вчера на митапе не были) Там как раз об этом @apelsinka223 говорила
AA
AN
GenStage - это чистый back pressure, если очередь спускают "сверху" то ген стейдж не нужен. И костыли, о которых вчера Настя рассказывала, только усложнят систему и вызовут кучу проблем под нагрузкой, которые вы устанете отлаживать
NM
Коллеги, поделитесь кто чем пользуется для успешного и быстрого разгребания очереди кролика? Broadway, другие библиотеки, самописные велосипеды? Условия примерно такие прилетели разом 1000 запросов, надо все отработать и отдать ответы в пределах двух минут. С прикидкой на то, что через год может быть 10К запросов
VS
Самописный, открываю несколько соединений, в каждом несколько каналов, по сотне консьюмеров на каждом.
AD
broadway самый простой способ. поднять достаточное количество consumer-ов чтобы они параллельно разгребали. 1000 запросов за 2 минуты должны уложиться
AD
вообще такие объемы и срок не должны быть проблемой и скорость наверно тут не стоит рассматривать как главный приоритет
AL
да, бродвей норм - будет вычитывать пачками. ну либо просто консьюмеров нарастить
AL
вообще, если нужно именно быстро читать и параллелить, консьюмер должен исключительно вычиткой и передачей в обработчик сообщения заниматься. а вот обработчиков уже накинуть как можно больше. если прямо в консьюмере делать обработку, то, конечно, он будет медленно ворочаться
AD
Возьмите просто библиотеку AMQP и создайте сами консумеров, не слушайте остальных. Browaday только замедлит положение, он сделает ровно то же, только еще и будет через себя данные гонять.
Чтобы посчитать кол-во консюмеров возьмите скорость обработки одного такого запроса и посчитайте что-то типа
consumers_count = (1000 * one_job_avg_execution_time_seconds) / (2 * 60)
Чтобы посчитать кол-во консюмеров возьмите скорость обработки одного такого запроса и посчитайте что-то типа
consumers_count = (1000 * one_job_avg_execution_time_seconds) / (2 * 60)
AD
зачем эта экономия на спичках? если бы реально нужна была скорость, то и очередь бы не использовали
AD
Бывает что в очередь пишет какая-то ламда функция и она не контролируется
AD
брать и делать все сразу идеально без секунды замедления ни в одном проекте не нужно. будет необходимость - когда будет настоящая нагрузка, а не выдуманные узкие места - тогда и стоит начинать писать свои решения. А когда разницы нет - почему бы не взять готовую либу где с минимумом кода уже будет все работать, пусть и на пару наносекунд медленнее
AB
а акать он их тоже будет пачками?
AB
то есть, отдельный запрос можно nack-нуть, чтобы он в dlx отправился, или что там еще на стороне сервера настроено?