单个Kafka主题上的Avro编码消息，单个分区。这些消息中的每一个仅由特定使用者使用。例如，关于该主题的消息a1，a2，b1和c1，有3个名为A，B和C的使用者。每个使用者都将获得所有消息，但最终A将消耗a1和a2，b1上的B以及c1上的C。
我想知道在Kafka上使用avro时通常如何解决此问题：
看起来每个选项都有其优点和缺点。我想知道是否有人们遵循的约定，或者有其他解决方法。
取决于...
If您只有一个分区的主题，唯一的选择是让每个使用者读取所有数据并过滤客户端该使用者感兴趣的数据。在这种情况下，每个使用者都需要使用不同的group.id将使用者彼此隔离。
如果可以控制您正在阅读的输入主题，则当然可以使用选项2。对于每个使用者，您可能仍具有不同的group.id，因为看来该使用者代表应相互隔离的不同应用程序。问题仍然在于，这是否是一个好的模型，因为partitions的想法是提供水平向外扩展和数据并行处理。但是，如果每个应用程序仅从一个分区读取，则似乎与该模型不符。您还需要知道哪些数据进入哪个分区生产者端和消费者端才能正确映射。因此，这意味着生产者和消费者之间的“协调”似乎是不希望的。
选项3似乎表明您无法控制输入主题，因此希望将数据分支到多个主题？一般而言，这似乎是一个好方法，因为主题是数据的[[logic]]分类。但是，最好有3个主题作为不同数据的开始！如果从一开始就没有3个输入主题，那么选项3似乎不能提供良好的概念设置，但是，它不会提供太多的性能优势，因为Kafka Streams应用程序需要读取和写入每个记录一次。您获得的节省是，每个应用程序只会使用一个主题，因此这里避免了读取多余的数据-如果您愿意，假设有100个应用程序（每个应用程序仅对数据的1/100感兴趣），能够将负载从99倍的读取开销显着降低到1倍的读取和1倍写入开销。对于您的情况，从2倍的读取开销减少到1倍的读取开销和1倍的写入开销，您实际上并没有减少太多。此外，您需要管理Kafka Streams应用程序本身。选项4似乎是正交的，因为它似乎回答了有关过滤如何工作的问题，并且报头可用于选项1和选项3进行实际的过滤/分支。