Всем привет. Есть спринг-бут приложение без клаудов-стримов и прочего. Есть

один топик. Партиций условно 10. Пишут в топик 1-2-3 сервиса, но много. Лиснеров по количеству партиций, 10 подов. Каждый инстанс там по своей партиции взял и разгребает. Процессинг при разгребании чуть сложный, потому приличный лаг накопился. В какую сторону делать "оптимайзинг"? Я так полагаю у спринга тюнить concurrency не следует, если консумеров столько же, сколько партиций?

направлений несколько 1) увеличение кол-ва партиций, да. это самый простой способ увеличить параллелизм и горизонтально масштабироваться. 2) иногда, когда сообщений много, помогает асинхронно закреплять оффсеты обработанных сообщений, если не страшно в случае чего обработать повторно не одно, а сразу несколько. когда ожидание коммита оффсетов занимает заметное время в сравнении со всем процессингом - удается получить заметный прирост производительности на партицию. 3) в развитие второго - параллелить обработку сообщений с одной партиции, но при этом закреплять оффсет по очереди. т.о., "получили сообщение а и б, отправили в параллельную обработку и добавили promise(или что угодно) завершения обработки в очередь с соблюдением порядка сообщений. в фоне обрабатываем очередь, дожидаясь обработки следующего сообщения, и коммитим его оффсет." тогда можно устроить параллелизм в рамках одной партиции. но нужно ли вам это? проще масштабироваться горизонтально.

Благодарю за развёрнутый ответ. 1 - там топик живёт сутки, событий в нём много, ребалансировка полагаю займёт продолжительное время, потому пока откинул данный вариант. 2,3 - в этом направлении и предполагаю. Там события такие, что не сильно страшно перечитать в случае чего или потерять парочку. Потому склоняемся к batch и какой-нибудь auto-commit-offset по времени

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