Apache Kafka RabbitMqと同様）で強力なルーティング機能を使用できますか？
Kafkaを評価し、ソフトウェアのRabbitMqを置き換えようとしています。
オフライン消費、巨大な永続性、優れたパフォーマンス、低遅延、高スループットに対するRabbitMqの観点から、Kafkaの利点を知っています。
ただし、RabbitMqがトピック交換で持つ機能が必要ですグラニュラールーティング異種消費用。
Kafkaのブローカーあたりのパーティション数を増やすことで、ある程度これを実現できます。ただし、znodeでのトピックメタデータのオーバーヘッド、待ち時間の増加など、独自の制限があります。
私たちのユースケースは、パーティション内のデータをフィルタリングすることです。 1つのパーティションで同様のタイプのセンサーデータを100個取得するとします。消費者は、センサーデータの一部のみを選択し、残りを無視する機能を持つことができますか。
アプリケーション（コンシューマー）側でフィルタリング/ルーティングを行うことはできますが、再利用可能ではなく、各コンシューマー側で追加のオーバーヘッドが発生するようです。
Kafkaは、最適な数のパーティションを持つことで、豊富なルーティング機能を提供できる方法はありますか？
ありがとう、Ashish
KafkaのメッセージングモデルはRabbitMQよりもはるかに単純なモデルであり、ユーザーは、意図したとおりに提供されるいくつかの抽象化を使用するのが賢明です。実際、トピックは、Kafkaで実行する必要があるルーティングの唯一のレベルです。パーティションは、スケーリング、順序の提供（ただし、パーティション内でのみ、順序に依存するアプリケーションがある場合のスケーラビリティの注目すべき問題）、およびトピック内での同時コンシューマーの促進にのみ機能します。
パーティションのレベルでルーティングを行う場合の問題は、パーティションがKafkaの要素であり、少なくともメッセージング層で）スケーラビリティを提供するため、スケーラブルではないことです。明らかに、Kafkaは、きめ細かいルーティング用に設計されていません。永続的で信頼性が高く、スケーラブルなpub/subメッセージング用に設計されています。また、パーティション全体で拡張できるように設計されていません。その性質上、パーティションは1つまたはいくつかのローカルにあります= Kafkaノード（トピックのレプリケーションファクターによって異なります）、ただしKafkaは、トピック内の複数のパーティションをクラスター全体に分散します。これは、次の場合にホットスポットが発生する可能性があることを意味します。メッセージは、トピック内のパーティション間で均等に分散されるのではなく、特定のパーティションを優先します（これが、Kafkaプロデューサーが通常はパーティション分割を処理する理由です）。
クライアント側でのフィルタリングに関しては、あなたは正しいと思います。それは私には多くの無駄なリソースのように感じますが、おそらく私は無駄なリソースがあまりにも嫌いです。
つまり、Kafkaのメッセージングの抽象化をこのように複雑な用語で考えようとすると、穴を掘るリスクがあると思います。 Kafkaは、パーティションを介して負荷を分散するように設計および最適化されているため、漠然と類似している場合でも、別のユースケースにそれらを採用することは確かに理想的ではありません。
Kafkaの機能のコンテキスト内でユースケースを管理できると思います。 Kafkaのトピックフレームワーク内の複雑なルーティングスキームの最大の課題は、複数のトピック内の重複データを防ぐことですが、同じトピック内の異なる位置から複数のアプリケーションがどのように消費できるかを理解すると、その問題は解消されるようです。この意味で、Kafkaは、キューではなくログとして考えることが重要です。
ちなみに、パーティションの管理に必要なznodeに関する懸念は根拠がないと思います。 ZooKeeperノードのメモリ（1トン）を消費するのに十分なトピックとパーティションがある場合は、すでにはるかに大きなリソースの問題が発生している可能性があります。