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

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

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

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

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


java apache-kafka architecture consumer
person Max    schedule 28.02.2019    source источник
comment
на самом деле лучше задать вопрос, как это сделать? не понятно о чем ты спрашиваешь   -  person Deadpool    schedule 28.02.2019
comment
@Дэдпул, у меня есть сервис. У него есть кафка с темой, которая содержит события клиентов. Мне нужно разработать API для передачи этих событий клиентам.   -  person Max    schedule 28.02.2019
comment
что означает, что вы должны потреблять события из темы кафки, верно? тогда в чем проблема в этом?   -  person Deadpool    schedule 28.02.2019
comment
@Deadpool, да, мне нужно использовать события из темы kafka. Проблема в том, что каждый клиент имеет уникальное смещение. Итак, если у меня есть 100 одновременных клиентов, мне нужно 100 потребителей kafka, верно? Что, если у меня будет 1000 онлайн-клиентов?   -  person Max    schedule 28.02.2019
comment
я не понял, each client has unique offset. каждое сообщение в kafka будет иметь смещение, что вы имеете в виду под client здесь? В соответствии с этим (I use clientId for partition key). одни и те же клиентские события будут попадать в один и тот же раздел? а если у вас 1000 клиентов с топиком 100 разделов?   -  person Deadpool    schedule 28.02.2019
comment
@Deadpool Да, каждое сообщение в kafka будет иметь смещение. Я использую потребительский API Java, поэтому, когда я poll(), я могу получить смещение записи. Я возвращаю это смещение как часть результата моего API. Итак, клиент знает, какое последнее смещение события он получает. Проблема связана с количеством потребителей в моем подходе. Мне нужно создать потребителя для каждого клиента API. Кажется, что это плохой дизайн. Да, одни и те же клиентские события попадут в один и тот же раздел.   -  person Max    schedule 28.02.2019
comment
Если я понимаю, основываясь на ключе, найдите, какое событие клиента было, и отправьте его соответствующему клиенту, для этого вам нужна только одна группа потребителей.   -  person Deadpool    schedule 28.02.2019

Ответы (1)


arrow_upward
0
arrow_downward

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

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

Проблемы с текущим дизайном

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

Предложение

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