Спасибо

Коллеги, всем привет. У меня вопросик есть.
Есть кафка брокеры с зукиперами.
Есть приложение, которые слушает сообщения из кафка топика(Nifi).
В связи временными сетевыми проблемами, приложение перестает читать сообщения из топика, из-за того, что его консьюмеры не могут обратно вступить в консьюмер группу.

Один из примеров.
Консьюмер группа находиться в неопределенном состоянии больше суток.

Состояние группы:
-----
Warning: Consumer group 'my_cons_group' is rebalancing.
GROUP              COORDINATOR (ID)     ASSIGNMENT-STRATEGY STATE      #MEMBERS
my_cons_group  KAFKA-1.LOCAL:9092 (1)           CompletingRebalance 19
---

Мемберы группы(их 19 штук показывает, покажу часть), хотя число консьюмеров у меня 2.
-----
Warning: Consumer group 'my_cons_group' is rebalancing.
GROUP                CONSUMER-ID                   HOST      CLIENT-ID    #PARTITIONS  
my_cons_group consumer-1-d0822efb-956a-4df1-8a80-55a8c4d2d61b /10.120.0.12  consumer-1   0        
my_cons_group consumer-1-a8ff3691-0fc4-48bd-b825-35cf43b8f6bb /10.120.0.10  consumer-1   0        
my_cons_group consumer-1-0f6c5e50-f0f3-4320-babe-8b0971d32384 /10.120.0.10  consumer-1   0        
my_cons_group consumer-1-5c0e4386-26c5-48eb-8f5b-0347d34570d2 /10.120.0.10  consumer-1   0        
my_cons_group consumer-1-95b6d778-b416-4915-9237-19b22e592c63 /10.120.0.12  consumer-1   0
....        
-----

В настройках консьюмера:
heartbeat.interval.ms = 3000
session.timeout.ms = 10000

Сколько раз не перезапускай приложение, результат один.
Помогает перезапуск брокера. После перезапуска делатся чистка мемберов и новая ребалансировка, после чего все ок.

Должна ли кафка подчищать мертвых мемберов сама?

Добрый день. Подскажите, как правильно настроить параллелизм стрима если он читает с топика из 3х партиций?  Запустить 3 инстанса с одинаковым application id, или выставить в конфигах стрима количество тредов=3?

Чат, вот прям сейчас метан по Кафке https://twitter.com/jugnsk/status/1304315870299271168?s=21

Всем привет! Есть вопрос про использование коннекторов к БД в плане архитектуры (его наверняка задавали уже, можно просто меня ткнуть носом 🙂 ). Вот предположим есть REST API сервис с реляционной базой под капотом. Этот сервис поддерживает своё REST API (обратная совместимость в рамках минорных версий и т.д.). Но под капотом, предположим, он активно развивается, структура базы меняется, сам тип RDBMS меняется (переезжают с Oracle на Postgres, предположим, да ещё и по частям). Плюс, у них есть некоторые достаточно тяжелые запросы, которые они кэшируют под капотом. Получается, что мы должны нарушить инкапсуляцию этого сервиса (через KStream/KTable джойнить самим потоки по ключу или типа того) и каждый раз допиливаться при том же самом API? Добавим ещё, что для нас решение выглядит как черный ящик (разрабатывается вне нашей компании, сорцов нет). Кмк, здесь возникает как раз проблема, когда интегрировались через БД в свое время.

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

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

не

15 консюмеров - 10 парт
10 консюмеров читают - 5 отдыхают

в рамках одной группы

парты это партиции?

да)

Из одной консюмерной группы могут - это будет выглядеть как параллельная вычитка.
Каждый консюмер будет забирать следующий оффсет

ну вот чето разные показания

Если группа одна, то в кафке они предтсавляются, как один потребитель.

Но значит кол-во партиций на кол-во групп влияет? могут разные группы из одной партиции читать?

или нужно кол-во партиций >= кол-ва групп

Количество групп не ограничено
В рамках одной группы не более одного консьюмера на партицию

Причём тут этот сервис и кстримс, у вас поменяется архитектура под капотом но апи и база или другой источник данных останется