kafka的消息传递模型比rabbitmq简单得多，用户明智地使用它所提供的少量抽象。真的，主题是Kafka唯一应该做的路由层次。分区仅用于扩展、提供顺序（但仅限于分区内，如果您有一个顺序相关的应用程序，这是一个值得注意的可伸缩性问题），并促进主题内的并发使用者。
在分区级别执行路由的问题是它不可伸缩，因为分区是kafka的元素，它提供了可伸缩性（至少在消息传递层）。显然，kafka不是为粒度路由而设计的。它专为持久、可靠、可扩展的发布/订阅消息而设计。分区的设计也不是为了跨集群扩展。就其本质而言，分区对于一个或几个kafka节点是本地的（取决于主题的复制因子），但是kafka将主题中的多个分区分布在集群中。这意味着，如果消息倾向于某个特定的分区，而不是均匀地分布在某个主题的分区上，那么就有可能出现热点（这就是为什么kafka生产者通常为您处理分区）。
在客户端的过滤方面，我认为你是对的：对我来说，这感觉像是浪费了很多资源，但也许我只是太不喜欢浪费资源了。
简言之，我认为，如果你试图用如此复杂的术语来思考Kafka的信息抽象，你可能会冒着把自己挖到一个洞里的风险。kafka在很大程度上是为通过分区来分配负载而设计和优化的，因此将它们用于不同的用例（即使有点相似）肯定是不理想的。
我觉得你可以在Kafka特性的上下文中管理你的用例。我发现，在kafka的主题框架中，复杂路由方案的最大挑战是防止多个主题中的重复数据，但一旦您了解了多个应用程序如何从同一主题中的不同位置使用数据，问题似乎就消失了。从这个意义上说，Kafka更应该被看作是一个日志而不是一个队列。
另一方面，我认为您对管理分区所需的znode的担心是没有根据的。如果您有足够的主题和分区来消耗zookeeper节点的内存（一吨），那么您可能已经遇到了更大的资源问题。