Доброго времени суток.
2 вопроса.

1. Есть продюссер, который пишет в топик. В топике N партиций. Есть N консюмеров, который топик читают. Можно ли как-то обеспечить масштабируемость консюмеров свыше этих N партиций? Может слуиться ситуация пиковой нагрузки, когда гонсюмер выплюнет, скажем, миллиард сообщений и хотелось бы в такие моменты скейлить консюмеров, чтобы бытрее разгребли. Но скейлить больше N нет смысла.


2. В партицию летят сообщения, которые тут же обрабатываются консюмером. Иногда попадаются такие сообщения, для обработки которых нужно подождать еще одного сообщения в этой же партиции. Хранить у себя в конюмере - так себе вариант (если упадет/ребаланснется, то потеряется этот стейт). KSQL и джойн стрима на себя же?

1. Именно вычитывальщиков(консумеров) больше чем N не сделать, но каждый вычитывальщик может обрабатывать сообщения в многопотоке (в спринг-кафке вроде была возможность это настраивать) если ваши данные позволяют это делать (не зависят от порядка, обрабатываются одинаково быстро и им нужно только cpu/ram для этого, которые имеются в запасе)

2. если боитесь падений и ребалансирвоки, то кажется что вам недопустимо терять стейт, а значит и вариантов кроме как использовать базу не будет (либо для сохранения стейта, либо для хранения оффсетов) с KSQL не работал, поэтому может оно конечно и решит вашу проблему

Нет волшебства. Нужно либо Schema Registry использовать (тогда сериализатор и десериализатор сможет информацию о схеме вынимать из payload), либо каким-то образом передавать информацию о типе

Всем привет, а confluent ldap auth только в enterprise  или для ce тоже можно пользоваться?

Enterprise

Sad

Был где-то опинсорсный

Я simplest possible нашёл наработку))) вот думаю либо на основе него чего нить переделать, либо может готовое есть уже

Ну тут как всегда - build vs buy

Buy в России не работает ведь)))

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

https://medium.com/agoda-engineering/how-agoda-manages-1-5-trillion-events-per-day-on-kafka-f0a27fc32ecb

немного про нашу кафку в agoda =)

с небольшим дополнением:
в данной статье описывается что disk first
в текущий момент происходит переработка и disk будет лишь как fallback

Пробовали Rack-ами разделять по важности ? Или имеет несколько кластеров + цепочки ММ/репликаторов вам удобнее?

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

но больше на физ уровне это

с учётом 5дц (из них 2 основных + 3 более мелких)
плюс дев/qa окружения то скрипты для разворачивания и мониторинга отдельных кластеров уже имеются

сори за офтоп, а вас тоже в Бангкок отвезли? (недавно рекрутер из agoda писал, говорил про релокацию в Бангкок)

без 9 дней 3 года =)