привет, а есть те, кто завозил ZK с SASL на жаве? что-то я смотрю в доку и плакать хочется, в принципе вопрос так же актуален и к Кафке

хочется просто подружить клиент кафки с org.apache.kafka.common.security.plain.PlainLoginModule

товарищи, простой вопрос (наверное).
Если продьюсер выставляет отличный от брокера тип компрессии, то (я предполагаю) на мнение продьюсера наплевать.
Не могу найти подтверждение в доке

а брокер уже настроен или нужна настройка брокера?

не, брокер уже ходит на admin/password и все ок, вопрос только в клиенте жавы

Sasl SSL Или sasl plain?

sasl plain

pain...

Всем привет! Поделитесь опытом, пожалуйста. У нас на проекте используется Кафка, клиент на Java.
Есть задача отправлять эвенты клиентам по Server Sent Event. После подключения клиент должен получить все эвенты пока он был оффлайн, а затем продолжать получать сообщения, созданные после подключения.
Хочу реализовать следующим образом. Продюсеры, которые хотят уведомить клиента, отправляют сообщения в специальный топик. Когда клиент подключается, создаем нового Кафка консьюмера на основе id пользователя(каждый пользователь это отдельная консьюмер-группа), подписываемся на все партишены в топике. Затем запрашиваем батч сообщений из Кафки, отфильтровываем сообщения для клиента, отправляем их по SSE, затем фиксируем оффсет в Кафка и так до бесконечнеости. Если клиент отключается, то просто отписываемся от всех партишенов. Простой тест показал, что при 2 партишенах прочитать 1500 сообщений пользователя из 3 млн сообщений в топике одним консьюмером занимает примерно 1,5 - 2 мин, что не проходит по требованиям. Поэтому хочу увеличить количество портишенов(например, до 1024) У нас продюсеры  роутят сообщения по ключу. Консьюмер будет делать предположение в каком партишене искать сообщения на основе ключа и подписываться только на этот партишен.  

Есть такие вопросы:
1. Насколько плохо иметь большое количество консьюмеров с точки зрения Кафки. Допустим, их будет параллельно более 1000 на этот топик?
2. Вывезет ли Кафка такое количество партишенов и консьюмеров?
3. Есть в описанной схеме что-то что я не учел или можно сделать лучше?
4. В схеме с фиксированным количеством партишенов есть проблема, что нельзя будет их увеличить потом так, чтобы не потерять сообщения пользователя. Как бы это можно было бы решить?

у меня вопрос - а Кафка вам тут зачем?

Кафка здесь как персистентное хранилище для всех сообщений пользователя с возможностью подписки

а что делать, если пользователь пришел через месяц, и его консьюмер группа уже отсутсвует?

Именно поэтому я за «не хранить данные в брокере сообщений»

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

Если  для пользователя не удалось получить оффсет, то значит пользователь подключается в первый раз или, как Вы заметили, его группа удалена. В таком случае отправляем клиенту специальное сообщений, после которого он запрашивает по ресту все что ему нужно, а консьюмер подписывается с latest.
Я, кстати, что-то не нашел инфу как долго хранится метадата группы, только то, что она в отдельном топике. Буду рад, если дадите наводку

Можете поделиться в чем недостатки такого подхода?

offsets.retention.minutes

спасибо

Подозреваю, что так или иначе на каждого пользователя придется заводить топик, за этим делом надо будет как-то следить (например, оценивать объем), сложно адресовать отдельную запись (да, я уверен, что такая необходимость рано или поздно вылезет), и это всё просто чтобы выполнять задачи, которые всегда выполнялись обычным хранилищем.
Ну и кафка конечно не обычный message queue, но ожидать что в какой-то момент данные грохнет инженер, потому что он думает, что очереди забились и там уже стылые сообщени, вполне можно.

Всем стрим завтра https://twitter.com/gamussa/status/1257699244150067201?s=21 - позвоните в колокольчик чтобы не пропустить.
Ну а если пропустите - все равно запись будет. Он стрим прикольнее будет, конечно