As I said in my initial comment asking for clarification, for such a partition distribution scheme, you will need to implement a custom ConsumerPartitionAssignor
.
each instance should pick a limited number of threads with one topic/partition each
Instances don't "pick" topics/partitions; one instance is selected and it decides which instance(s) get which topic/partition(s).
See its javadocs.
/**
* This interface is used to define custom partition assignment for use in
* {@link org.apache.kafka.clients.consumer.KafkaConsumer}. Members of the consumer group subscribe
* to the topics they are interested in and forward their subscriptions to a Kafka broker serving
* as the group coordinator. The coordinator selects one member to perform the group assignment and
* propagates the subscriptions of all members to it. Then {@link #assign(Cluster, GroupSubscription)} is called
* to perform the assignment and the results are forwarded back to each respective members
*
* In some cases, it is useful to forward additional metadata to the assignor in order to make
* assignment decisions. For this, you can override {@link #subscriptionUserData(Set)} and provide custom
* userData in the returned Subscription. For example, to have a rack-aware assignor, an implementation
* can use this user data to forward the rackId belonging to each member.
*/
public interface ConsumerPartitionAssignor {
To add more threads (consumers) to an instancee, increase the container concurrency.
For a large number of instances, I would recommend a COOPERATIVE
rebalance protocol.