Можем ли мы иметь мощную маршрутизацию с Apache Kafka, подобной RabbitMq?

Мы пытаемся оценить Kafka и заменить Rabbit Mq в нашем программном обеспечении.

Мы знаем преимущества Kafka с точки зрения RabbitMq над автономным потреблением, огромной настойчивостью, превосходной производительностью, низкой латентностью и высокой пропускной способностью.

Но нам нужна возможность того, как RabbitMq имеет раздел гранулированной маршрутизации для гетерогенного потребления.

В какой-то мере мы можем достичь этого, имея больше количества разделов на брокера в Кафке. Но у него есть собственные ограничения, такие как накладные расходы на метаданные темы в znode, увеличение латентности.

Наш прецедент - это фильтрация данных в разделе. Предположим, что вы получаете 100 данных датчика аналогичного типа в одном разделе. Может ли потребитель иметь возможность выбирать только некоторые данные датчика и игнорировать остальные.

Мы можем выполнять фильтрацию/маршрутизацию со стороны приложения (потребителя), но, похоже, не должны использоваться повторно и дополнительные накладные расходы на каждой стороне потребителя.

Каким образом Kafka может обеспечить богатую маршрутизацию, имея оптимальное количество разделов?

Спасибо, Ashish

Ответ 1

Модель обмена сообщениями Kafka - это намного более простая модель, чем RabbitMQ, и пользователям разумно использовать несколько абстракций, которые она предоставляет, поскольку они были предназначены. На самом деле, темы - это единственный уровень маршрутизации, который должен быть когда-либо сделан в Кафке. Разделы служат только для масштабирования, обеспечивают порядок (но только внутри раздела, что является заметной проблемой для масштабируемости, если у вас есть приложение, зависящее от порядка) и облегчают одновременное использование пользователей в рамках темы.

Проблема с выполнением маршрутизации на уровне разделов состоит в том, что она не масштабируется, потому что разделы являются элементом Kafka, который обеспечивает масштабируемость (по крайней мере, на уровне обмена сообщениями). Очевидно, что Kafka не предназначен для гранулированной маршрутизации. Он предназначен для постоянной, надежной, масштабируемой, pub/sub-обмена сообщениями. Также не предусмотрены перегородки, предназначенные для масштабирования по всему кластеру. По самой своей природе разделы являются локальными для одного или нескольких узлов Kafka (в зависимости от фактора репликации темы), но Kafka распространяет несколько разделов внутри темы по всему кластеру. Это означает, что есть некоторые возможности для горячего определения, если сообщения благоприятствуют определенному разделу, а не равномерно распределены между разделами в теме (поэтому производитель Kafka обычно обрабатывает разделы для вас).

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

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

У меня есть чувство, что вы можете управлять своим прецедентом в контексте возможностей Kafka. Я считаю, что самая большая проблема со сложными схемами маршрутизации в рамках кафа-темы предотвращает дублирование данных по нескольким темам, но как только вы поймете, как несколько приложений могут потреблять с разных позиций в одной и той же теме, проблема, кажется, исчезает. В этом смысле важно думать о Кафке больше как о журнале, а не о очереди.

С другой стороны, я думаю, что ваша забота о znodes, требуемая для управления разделами, необоснованна. Если у вас достаточно тем и разделов для хранения памяти ваших узлов ZooKeeper (тонна), то вы, вероятно, уже столкнулись с гораздо большими проблемами с ресурсами.