Кафка лучший способ добиться фильтрации сообщений - PullRequest
0 голосов
/ 21 апреля 2020

Хотите узнать лучший способ для нижеследующего случая.

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

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

или 1 топи c для каждого потребителя и 1 раздел или несколько разделов в каждой топи c?

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

Ответы [ 2 ]

0 голосов
/ 22 апреля 2020

На мой взгляд, это хороший пример использования Kafka.

Я рекомендую не дублировать данные и обрабатывать все сообщения в one topi c с несколькими разделами . Обработка данных вне Kafka масштабируется с количеством разделов, поэтому я бы установил число на основе вашего ожидаемого количества данных и требуемого throuput. Если у вас есть требования к порядку сообщений в разделенной топике c, вы можете использовать собственный разделитель в вашем производителе для управления распределением данных в эту топику c. Имейте в виду, что порядок сообщений в Kafka гарантирован только в пределах раздела.

Потребители, которые подписываются на эту топику Kafka c, должны быть максимально независимыми от производителя. Поэтому я бы не стал пытаться заставить производителя «что-то делать» для потребителей. В идеале, производитель не должен знать что-либо о потребителях, особенно если вы планируете добавить больше потребителей в будущем.

Потребители также должны быть независимы друг от друга, и все они используют разные группы потребителей. . Таким образом, каждый потребитель может самостоятельно считывать данные из topi c. Кроме того, в случае сбоя потребитель может самостоятельно перечитать данные Kafka topi c с самого начала, не затрагивая других потребителей.

0 голосов
/ 21 апреля 2020

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

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

Вы выбираете, использовать ли одну топи c, topi c для приложения-потребителя или что-то между ними.

Одна topi c подходит, если потребители в каждом приложении находятся в отдельной группе с потребителями в других приложениях, так что каждое приложение получает все сообщения. Недостатком является то, что каждому придется отфильтровывать сообщения, в которых они не заинтересованы.

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

Другой подход состоит в том, чтобы иметь темы, основанные на некотором логическом разделении, основанном на типе сообщений, где несколько приложений могут подписаться на топи c, а некоторые приложения могут подписаться по нескольким темам, и они могут не интересоваться всеми сообщениями, но производителям не нужно знать, кто потребляет, только к какой логической области относится сообщение (где вам решать, как разделить темы и типы сообщений). )

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