Nivel 2 · 25 min

Consumer Groups de Kafka

Los consumer groups son el mecanismo de Kafka para consumo escalable y tolerante a fallos. Un grupo de consumidores comparte el trabajo de leer un topic — cada partición se asigna a exactamente un consumidor por grupo. Entender la coordinación del grupo, el rebalanceo, el lag y las estrategias de offset es esencial para consumidores confiables.

Coordinación del Consumer Group

Todos los consumidores de un grupo comparten el group.id. Kafka asigna cada partición a exactamente un consumidor del grupo — nunca dos consumidores del mismo grupo leen la misma partición simultáneamente. Esto habilita escalado horizontal (agregar consumidores para escalar) y tolerancia a fallos (si un consumidor falla, sus particiones se reasignan). El broker group coordinator gestiona la membresía del grupo. Un consumidor se convierte en group leader y realiza la asignación de particiones según el assignor configurado.

Rebalanceo de Particiones

El rebalanceo se dispara cuando un consumidor se une o deja el grupo (incluyendo crashes). Durante el rebalanceo, todos los consumidores dejan de procesar — el efecto stop-the-world. Rebalanceo eager (default): todos los consumidores sueltan sus particiones, se rebalancea, todas se reasignan. Rebalanceo cooperativo/incremental (Kafka 2.4+): solo las particiones afectadas se revocan y reasignan — las demás continúan procesando. Usá CooperativeStickyAssignor para minimizar la disrupción. Los rebalanceos agregan latencia y pueden causar reprocesamiento si los offsets no se commitearon antes de perder la partición.

Consumer Lag y Estrategias de Offset

Consumer lag = offset latest en la partición - offset commiteado por el consumidor. Lag alto significa que el consumidor se está quedando atrás de los productores. Monitoreá con kafka-consumer-groups.sh --describe o métricas JMX. Para commits de offset: auto-commit (enable.auto.commit=true) commitea cada 5 segundos por defecto — riesgo de reprocesamiento si el consumidor falla entre commits. Commit manual: commitSync() después del procesamiento exitoso (at-least-once), o commitAsync() para mayor throughput con algo de riesgo de duplicados. Para garantías fuertes, commitear offsets y actualizar estado en la misma transacción.

Puntos clave

Cada partición es consumida por exactamente un consumidor por grupo — la unidad de paralelismo es la partición, no el topic.
El rebalanceo cooperativo (CooperativeStickyAssignor) reduce dramáticamente el efecto stop-the-world — usalo en producción.
El consumer lag es tu métrica operacional más importante — lag sostenido significa que los consumidores no pueden seguir el ritmo de los productores.

Code example

// Commit manual de offset: at-least-once
while (true) {
  ConsumerRecords<K,V> records = consumer.poll(Duration.ofMillis(100));
  for (ConsumerRecord<K,V> record : records) {
    processRecord(record); // primero procesar
  }
  consumer.commitSync(); // luego commitear
  // si process lanza excepcion, el registro se reprocesa
}