...
The group and the members represents the current state of a group.
Consumer Group | ||
---|---|---|
Name | Type | Description |
Group ID | uuid | The group ID as configured by the consumer. The ID uniquely identifies the group. |
Group Epoch | int32 | The current epoch of the group. The epoch is incremented by the group coordinator when a new assignment is required for the group. |
Members | []Member | The set of members in the group. |
Partitions Metadata | []PartitionMetadata | The metadata of the partitions that the group is subscribed to. This is used to trigger a rebalance when the partition metadata changes. |
Member | ||
Name | Type | Description |
Member ID | uuid | The unique identifier of the member. The ID is similar to an incarnation ID. It is generated by the client once and must be used during its lifetime. |
Instance ID | string | The instance ID configured by the consumer. |
Client ID | string | The client ID configured by the consumer. |
Client Host | string | The client ID configured by the consumer. |
Subscribed Topic Names | []string | The current set of subscribed topic names configured by the consumer. |
Subscribed Topic Regex | string | The current subscription regular expression configured by the consumer. |
Server Assignor | string | The server side assignor used by the group. |
Client Assignors | []Assignor | The list of client-side assignors supported by the member. The order of this list defined the priority. |
Assignor | ||
Name | Type | Description |
Name | string | The unique name of the assignor. |
Minimum Version | int32 | The minimum version of the metadata schema supported by this assignor. |
Maximum Version | int32 | The maximum version of the metadata schema supported by this assignor. |
Reason | int8 | The reason why the metadata was updated. |
Metadata | bytes | The metadata provided by the consumer for this assignor. |
Target Assignment
The target (or desired) assignment of the group. This represents the assignment that all the members will eventually converge to. It is a declarative assignment which is generated by the assignor based on the group state.
Target Assignment | ||
---|---|---|
Name | Type | Description |
Group ID | uuid | The group ID as configured by the consumer. The ID uniquely identifies the group. |
Assignment Epoch | int32 | The epoch of the assignment. It represents the epoch of the group used to generate the assignment. It will eventually match the group epoch. |
Assignment Error | int8 | The error reported by the assignor. |
Members | []Member | The assignment for each member. |
Member | ||
Name | Type | Description |
Member ID | uuid | The unique identifier of the member. |
Partitions | Partitions | The set of partitions assigned to this member. |
Metadata | bytes | The metadata assigned to this member. |
Current Assignment
The Current Assignment represents the current epoch and assignment of a member. Note that members of a given group could be at a different epoch but they will all eventually converge to the target assignment.
Current Assignment | ||
---|---|---|
Name | Type | Description |
Group ID | uuid | The group ID as configured by the consumer. The ID uniquely identifies the group. |
Member ID | uuid | The member ID of this member. |
Epoch | int32 | The current epoch of this member. The epoch is the assignment epoch of the assignment currently used by this member. This epoch is the one used to fence the member (e.g. offsets commit). |
Error | int8 | The error reported by the assignor. |
Partitions | Partitions | The current partitions used by the member. |
Metadata | bytes | The current metadata used by the member. |
Rebalance Process
The rebalance process is entirely driven by the group coordinator and revolves around three kinds of epoch: the group epoch, the assignment epoch and the member epoch. The process and the epochs are explained in the following chapters.
...
In the beginning, the new protocol will be disabled by default. We envision enabling it by default in a future major release of Kafka.
Rebalance Process
The rebalance process in the consumer is basically the opposite of the process that was described earlier in this document. The consumer will know at any point in time its current epoch and the list of partitions that it owns. There are a few cases to consider:
...