因此，c2和c3将发生重新平衡，即使新的消费者加入了订阅*\U t1的用户。
没错。
但我对第4点是如何影响重新平衡的还略知一二。我想，t1、c2和c3中发生的主题创建/删除/更改不会受到影响吗？不是吗？
只要消费者在同一消费者群体中，任何变化（如消费者数量的变化，例如消费者c1订阅*\u t1主题的行为被停止）都将发生再平衡，即使c2和c3与*\u t1无关。这与主题/分区数量的任何变化类似。这是因为对于同一消费者组中的所有消费者，kafka希望确保所有分区（对于所有订阅的主题）都得到处理，即1个分区1个消费者。请注意，一个使用者可以使用多个分区，但反之亦然。
我知道我们可以有三个不同的消费者群体，但我想知道这是否必要和/或是一个好的做法。
推荐的做法（是的，你是对的）是，如果消费者订阅了相同的主题，就把他们放在同一个消费者组中。在上面的例子中，将有3个消费群体，每个消费群体从各自的主题中消费。
消费者组my-consumer-1，c1消费*\U t1
消费群体my-consumer-2，c2消费*\u t2
消费群体my-consumer-3，c3消费*\U t3
因此，my-consumer-1中发生的任何更改都不会对组my-consumer-2和my-consumer-3产生性能影响。
对于后人来说，再平衡的定义如下：
再平衡是一个过程，其中一组使用者示例（属于同一组）协调以拥有一组订阅的主题的互斥分区集。在使用者组的成功重新平衡操作结束时，所有订阅主题的每个分区都将由该组中的单个使用者示例拥有。再平衡的工作方式如下。每个经纪人都被选为消费者群体的一个子集的协调者。组的协调代理负责为订阅的主题编排对使用者组成员身份更改或分区更改的重新平衡操作。它还负责将生成的分区所有权配置传递给正在执行重新平衡操作的组的所有使用者。
一些好消息是，在Kafka2.5中，重新平衡的“效果”可能会有一些“性能”改进：
当使用rebalanceprotocol#cooperative时，consumer#poll仍然可以返回数据，而它正在为那些仍然由consumer拥有的分区进行重新平衡；此外，consumer#commitsync现在可能抛出一个非致命的rebalanceinprogressexception来通知用户此类事件，以便与致命的commitfailedeexception区分开来，并允许用户完成正在进行的重新平衡，然后重新尝试提交那些仍然拥有的分区的偏移量。