В общем задача такая у меня есть http через который обращаются клиенты с идентификатором, на http-сервисе каждый идентификтор должен соответствовать group.id на kafka subscriber т.е придется создавать на каждый http-request новый kafka-subscriber а это переподключения соединения. Возможно как нибудь создать один kafka-subscriber и ребиндить ему group.id ? или может быть есть какиенибудь другие решения ?
Тоже интересует. Нужно сделать SSE что бы кидало ивенты с топика но думаю тупо создавать consumer group per http запрос это слишком дорого
Можешь рассказать чуть подробнее о бизнес процессе? В чем необходимость склейки ид клиента и потребителя данных в кафке? Как одно связано с другим?
По сути нужен http интерфейс к субраскрайберу, что бы кафка сама хранила оффсет на вычитывание и была соответствующася авторизация.
Менять на лету group.id не получится. Сама идея с использованием группы для этого - "так себе". С ее помощью можно реализовать только семантику mostly once. Смотри, сообщения будут пропадать при таком сценарии: 1. Клиент запросил у сервиса данные 1. Сервис по http запросу считал сообщения в соответствии с указанной в запросе группой 2. Отправил ответ клиенту 3. В момент получения у клиента выключили свет - пакет потерян 4. Клиент поднялся и сделал запрос снова. В итоге клиент получит новую порцию данных. О том, что какой-то кусок данных не был доставлен никто никогда не узнает. Возможно, это норм с точки зрения текущего бизнес сценария. В любом случае можно сделать проще и сразу повысить гарантии обработки сообщения: в запросе к сервису передавать последний успешнопрочитанный оффсет, чтобы сервис отдавал данные начиная с него. В итоге сервис остается stateless, гарантия доставки обеспечивается. Возможно, нужно либо брать, либо реализовывать что-то наподобие вот такого. Как тебе вариант?
Меня пока больше интересует не то что http 'mostly once' - здесь согласен можно добавить последний прочитынный оффсет. А иммено как создать kafka subscriber который будет читать разные топики для разных пользователей по одному соединению, предполагаю что это сервис. http sink connector немного нето, как я понял из схемы, он активный т.е когда приходит новое сообщение в топик он пытается забросить его на какойнибудь сервер по rest. А нужен пассивный интерфейс в виде rest сервиса.
Разные топики для разных пользователей? Т.е. пользователь A читает топик topicA, а пользователь B читает топик topicB? Если так, то тогда все есть из коробки, и с группами играть не стоит: при чтении можно определить какой топик читать. В любом случае группы идеологически предназначены для другого: не для разграничения доступа, а для масштабирования обработки. Наверное несовсем правильно их использовать для этих целей.
Из коробки тоесть на http rest кафки ты имееш ввиду ?
Нет, я имею ввиду, что не нужно изобретать нового алгоритма работы на основе group.id. Если есть соответствие между топиками и клиентами, и это множество не пересекается. Свой REST клиент в любом случае нужно будет писать.
Один топик может читать несколько разных клиентов, поэтому когда ты создаеш консумер на каждого клиента скажем на java клиенте нужно чтобы у каждого клиента был свой уникальный group.id "под которым" кафка и будет хранить вычитываемое смещение. Поправьте меня если я неправ.
Всё так, только было бы проще использовать для этого оффсеты при каждом запросе, чем делить клиенты на группы. Если все-таки очень хочется через группы, то можно сделать тоже самое, но без групп: в отдельный топик писать какой клиент какой оффсет прочитал, этот топик смапить на глобальную таблицу. В этом случае уходит проблема переключения соединений.
Обсуждают сегодня