Как разработать API для получения клиентских событий от Kafka?

Question

Я думаю о шаблоне архитектуры, когда у каждого клиента моего сервиса есть собственный потребитель kafka.

Например, есть тема events с некоторым коэффициентом репликации и некоторым количеством разделов, которые я использовал для масштабируемости,Все события для данного клиента принадлежат одному разделу (я использую clientId для ключа раздела).

Каждый клиент имеет свой offset.Так что мой API позволяет использовать offset для получения клиентских событий.

Хорошо ли проект системы?Или каков правильный дизайн API для получения событий?

Answer 1

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

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

Относится к текущему дизайну

1. По мере увеличения количества пользователей количество потоков также должно увеличиваться, что означает, что подход не масштабируется линейно.Стоимость увеличивается с количеством пользователей.
2. Что делать, если потребительский поток выходит из строя?это может привести к сбою уведомления клиента.

Предложение

1. Использование Kstreams для потребления.Рассмотрим kstreams API более высокого уровня для потребления, чем API потребителя.
2. Используя свойство numthreads, вы можете настроить количество потоков.Таким образом, один KStream будет действовать как пул потребителей.
3. Имеет логику маршрутизации для поиска клиента и уведомления.
4. Компромисс: эта логика маршрутизации увеличивает задержку.