Кафка предметной адресации / потребления - PullRequest
0 голосов
/ 05 июля 2019

Будучи новичком в kafka, мы задаемся вопросом, поддерживает ли kafka наш вариант использования. Мы пытаемся создать поток событий, который включает в себя различные типы событий, например, Создан, Доработка, Deleted.

У нас есть два вида потребителей

  1. Которые должны непрерывно потреблять весь поток, рассмотрим аудит Audit.
  2. Выборочный потребитель, которому нужно подписаться только на один тип события, например, Created-> CreateConsumer, Обновлено -> UpdateConsumer.

Наши данные будут неравномерно распределены, например, У нас может быть 80% данных как созданных и 10% данных как обновленных.

Что нам интересно, какова хорошая стратегия для этого? Дополнительное требование к масштабированию на основе данных микширования:

Запустить 5 экземпляров AuditConsumer.

Запустите 4 экземпляра CreateConsumer.

Запустите 1 экземпляр UpdateConsumer.

Ответы [ 2 ]

1 голос
/ 05 июля 2019

Может быть несколько стратегий:

  1. Вы можете использовать тип события в качестве ключей, чтобы установить разделы и позволить потребителям получать из каждого раздела.
  2. Выдвижение различных типов событийв разных темах.от "create_event" до "creation_topic", от "updated_event" до "updated_topic".
  3. Push все события в одну тему.Используйте поток Kafka, чтобы использовать события и фильтровать их по типу события и выполнять дальнейшую обработку.

Лично я предпочту третий, использующий потоки kafka для фильтрации событий.Что касается масштабирования, вы можете масштабировать до максимального количества разделов.

1 голос
/ 05 июля 2019

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

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

CreatedEvent / UpdatedEvent / DeletedEvent записано в тему event_input_stream.

AuditConsumer потребляет от event_input_stream с группой потребителей audit.

EventSplitter потребляет из event_input_stream с группой потребителей splitter. EventSplitter проверяет тип события и выдает один из created_event, updated_event, deleted_event.

CreatedConsumer потребляет от created_event.

UpdatedConsumer потребляет с updated_event.

DeletedConsumer потребляет от deleted_event.

                                           /> created_event > CreatedConsumer
event > event_input_stream > EventSplitter -> updated_event > UpdatedConsumer
                                           \> deleted_event > DeletedConsumer

Проблема с тем, что все потребители читают из одной и той же темы, заключается в том, что UpdateConsumer нужно будет прочитать все сообщения, даже если они отбрасывают 90% из них. Это фактически означает необходимость одинакового масштабирования всех потребителей, поскольку они фактически будут потреблять одинаковое количество сообщений.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...