我们正在探索在Spark作业中跨多个任务进行协调的Kafka。每个Spark任务都充当同一主题上消息的生产者和消费者。到目前为止，我们看到了不错的表现，但我想知道是否有办法改进它，因为我们通过做与文件建议相反的事情来获得最佳表现。目前，我们只使用一台带有多个CPU的Broker机器，但如果需要，我们可以使用更多。
到目前为止，我们已经尝试了以下设置：
- 单个主题、单个分区、多个使用者，不使用组ID:最佳性能
- 单个主题、单个分区、多个使用者，每个使用者使用自己的组ID：比(1)慢2倍
- 单个主题、单个分区、多个使用者，所有人都使用相同的组ID：卡住或非常慢
- 单个主题，与消费者一样多的分区，单个组ID：卡住或非常慢
- 单个主题，与消费者一样多的分区，每个分区都使用自己的组ID或不使用组ID：有效，但比(1)或(2)慢得多
我不明白为什么我们会按照文档的建议行事，从而获得最佳性能。
我的问题是：
- 有很多关于拥有多个分区的好处的文章，即使是在一个代理上，但很明显，我们看到了性能的下降
- 除了弹性因素外，增加额外的经纪人还有什么好处？我们看到，即使在压力很大的时候，我们的单个Broker CPU利用率也从未超过50%。而且，简单地增加单个虚拟机的CPU数量比管理多个虚拟机更容易。获得更多经纪人有什么好处吗？(出于速度考虑，而非弹性)
- 如果以上是肯定的，那么很明显，我们不可能每个消费者都有一个经纪人。现在我们正在运行30-60个Spark任务，但它可能会达到数百个。因此，如果每个任务都有一个分区，那么我们几乎不可避免地会遇到这样的情况：每个Broker负责几十个分区。那么，根据以上测试，我们还会看到更糟糕的性能吗
请注意，我们正在设置生产者，以不等待来自Brokers的确认，正如我们在文档中看到的那样，有许多分区会减慢速度：
producer=KafkaProducer(引导服务器=[SERVER]，acks=0)
谢谢你的想法。
我认为您缺少了一个重要的概念：Kafka每个主题分区只允许一个消费者，而可能有多个消费者组从同一分区中读取您似乎在提交补偿或太多的组重新平衡问题上有问题。
以下是我的想法；
- 单个主题、单个分区、多个使用者，不使用组ID:最佳性能
这里实际发生的是->你的一个消费者无所事事。
- 单个主题、单个分区、多个使用者，每个使用者使用自己的组ID：比(1)慢2倍
两个使用者都在独立地获取和处理相同的消息。
- 单个主题、单个分区、多个使用者，所有人都使用相同的组ID：卡住或非常慢
同一组中只有一个成员可以从单个分区中读取。这不应给出与第一种情况不同的结果。
- 单个主题，与消费者一样多的分区，单个组ID：卡住或非常慢
这是将每个使用者分配到不同分区的情况。而且，在这种情况下，我们期望以最快的速度消费。
单个主题，与消费者一样多的分区，每个分区都使用自己的组ID或不使用组ID：有效，但比(1)或(2)慢得多
第一步和第二步的备注相同。
有很多关于拥有多个分区的好处的文章，即使是在一个代理上，但很明显，我们看到了性能的下降。
事实上，通过拥有多个分区，我们可以并行化消费者。如果使用者具有相同的组id，那么他们将从不同的分区进行消费。否则，每个使用者将从所有分区进行消费。
除了弹性方面的考虑外，添加额外的经纪人还有什么好处？我们看到，即使在压力很大的时候，我们的单个Broker CPU利用率也从未超过50%。而且，简单地增加单个虚拟机的CPU数量比管理多个虚拟机更容易。获得更多经纪人有什么好处吗？(出于速度考虑，而非弹性)如果以上是肯定的，那么很明显，我们不可能每个消费者都有一个经纪人。现在我们正在运行30-60个Spark任务，但它可能会达到数百个。因此，如果每个任务都有一个分区，那么我们几乎不可避免地会遇到这样的情况：每个Broker负责几十个分区。那么，根据以上测试，我们还会看到更糟糕的性能吗？
创建新主题时，集群中的一个代理将被选为分区领导者，所有读/写操作都将在其中处理。因此，当您有许多主题时，它将自动在代理之间分配工作负载。如果您有一个具有多个主题的单个代理，那么所有生产者/消费者都将从/向同一个代理进行生产/消费。