Cooperative Rebalancing

Cooperative and Incremental Rebalancing

Before KIP-848, Kafka 2.4 129 softened the classic protocol with incremental cooperative rebalancing (KIP-429): with the cooperative-sticky assignor, members keep the partitions that stay with them and revoke only those that move, at the cost of a second rebalance round to hand them over.

Output of 40
  0.1s A assigned [0, 1, 2]
  6.1s B assigned []
  6.2s A revoked  [0]
  6.2s A assigned []
  9.2s B assigned [0]
  9.3s A assigned []
...

rebalance_demo.py cooperative shows both rounds: in the first, B joins with nothing and A revokes only partition 0; in the second, three seconds later, B receives it. A never stopped consuming partitions 1 and 2. On a classic-protocol group, prefer cooperative-sticky; to migrate, list it together with the old assignor, roll the members, then remove the old one. New applications should use the consumer protocol directly.