Planteamiento y contexto
Esta pregunta evalúa la transferencia de propiedad distribuida en lugar de memorizar una configuración de Kafka. El rebalanceo eager revoca primero todas las particiones, mientras que el rebalanceo cooperativo permite que los miembros conserven las particiones que no necesitan moverse y revoca solo el conjunto de migración. Una respuesta completa cubre versiones de miembros, protocolo del asignador, confirmación de offsets (offset commits), ventanas de falla y telemetría.
Qué evalúa el entrevistador
- Si explicas las diferencias de revocación y traspaso (handoff) entre los protocolos eager y cooperativo.
- Si planificas un orden gradual compatible en lugar de asumir que un solo miembro puede cambiar por sí solo.
- Si la propiedad, los offsets, el trabajo en curso y los tiempos de confirmación están alineados.
- Si se manejan caídas, tiempos de espera (timeouts), duplicados, reversiones (rollbacks) y límites de capacidad.
Preguntas para clarificar
Confirma las versiones de los clientes, la lista actual de asignadores, la membresía estática, el tiempo de procesamiento por mensaje, la ventana de duplicados aceptable y el presupuesto de latencia de rebalanceo. Pregunta si el procesamiento es idempotente, si el destino (sink) admite deduplicación y si el despliegue se puede realizar por etapas y revertir. Establece el escalado máximo, el recuento de particiones y los umbrales de alerta.
Estructura de respuesta en 30 segundos
Primero actualiza cada miembro a una versión compatible con el protocolo cooperativo mientras mantienes una lista de asignadores compatible. Una vez que el soporte del protocolo sea uniforme, despliega CooperativeStickyAssignor como la estrategia preferida y elimina la anterior. Cada rebalanceo revoca solo las particiones que se mueven; el consumidor deja de obtener datos de ellas, confirma los offsets completados y el nuevo propietario reanuda a partir de los offsets confirmados. Monitorea la cantidad de rebalanceos, las particiones revocadas, la latencia de procesamiento y los duplicados. Una caída se apoya en el timeout de sesión y la recuperación de offsets; la reversión restaura la configuración compatible anterior mediante otro cambio gradual.
Solución paso a paso
1. Definir la matriz de compatibilidad de protocolos
El asignador se negocia a nivel de grupo, por lo que cambiar una sola instancia no es suficiente. Actualiza todos los clientes a una versión que comprenda el rebalanceo cooperativo antes de depender de él. Mantén una entrada de compatibilidad durante la primera fase, luego da preferencia a cooperative y elimina la estrategia anterior después de que el grupo esté listo:
partition.assignment.strategy=\
org.apache.kafka.clients.consumer.CooperativeStickyAssignor,\
org.apache.kafka.clients.consumer.RangeAssignorValida el protocolo negociado y la asignación del grupo después de cada fase; revisar únicamente un archivo de configuración no es evidencia de que el grupo en ejecución haya cambiado.
2. Diseñar la revocación y el traspaso de particiones
El conjunto de revocación cooperativa contiene únicamente las particiones que deben moverse. Al revocar, deja de consumir de esas particiones, finaliza o descarta el lote seguro actual y confirma los offsets completados. Continúa procesando las particiones que no fueron revocadas. El nuevo propietario comienza desde los offsets confirmados, por lo que las claves de idempotencia del negocio o la deduplicación en el destino gestionan los duplicados.
3. Alinear los offsets con el trabajo en curso
Confirma después del efecto secundario de negocio, nunca antes. Si la revocación llega durante un lote, establece un indicador de parada y finaliza en un punto seguro; si se alcanza el límite de tiempo, deja de obtener datos y registra el lote no finalizado. El procesamiento asíncrono necesita seguimiento de secuencias por partición para que solo se confirme un prefijo contiguo completado.
4. Planificar el despliegue gradual
Un controlador de despliegue reinicia pequeños lotes de miembros y espera la estabilidad del grupo y la recuperación del retraso (lag) después de cada lote. Registra una línea base, actualiza los clientes, observa el protocolo, cambia al asignador preferido, ensaya cambios de escala y solo entonces aumenta el tamaño del lote. Haz una pausa ante tormentas de rebalanceo o infracciones de latencia en lugar de modificar el timeout de sesión y el max poll interval al mismo tiempo.
5. Diseñar el comportamiento ante caídas y reversiones
Tras la caída de un miembro, el coordinador reasigna sus particiones cuando expira el timeout de sesión. El reemplazo reanuda desde el último offset confirmado, por lo que los efectos secundarios previos a la caída podrían repetirse. La reversión restaura el asignador anterior en la lista de compatibilidad y utiliza el mismo orden gradual; no elimines a la fuerza un miembro nuevo que aún esté en ejecución. Registra la generación, el ID del miembro, los conjuntos de revocación y los fallos de confirmación para diagnosticar condiciones de carrera.
6. Agregar salvaguardas de capacidad y telemetría
Monitorea la frecuencia y duración del rebalanceo, el recuento de particiones revocadas, el lag del consumidor, el intervalo de sondeo (poll interval), la latencia de confirmación, la tasa de duplicados y los miembros sin asignación. Prueba reinicios simultáneos, particiones saturadas (hot partitions), procesamiento que exceda max.poll.interval, fluctuaciones de red y recuentos de particiones cercanos a los recuentos de miembros. Si la capacidad es insuficiente, reduce el tamaño del lote de despliegue o agrega consumidores antes de continuar.
Ejemplo de respuesta de alta calidad
Verificaría que cada cliente admita la asignación cooperativa y luego utilizaría una configuración gradual en dos fases: conservar un asignador compatible mientras se actualizan las versiones y, solo después, preferir CooperativeStickyAssignor y eliminar la estrategia anterior. Las devoluciones de llamada (callbacks) de revocación detienen únicamente las particiones que se están moviendo, terminan en un punto seguro y confirman un offset contiguo; las particiones conservadas continúan. Los nuevos propietarios reanudan desde los offsets confirmados, gestionando los duplicados mediante idempotencia. Un controlador de lotes pequeños supervisa los rebalanceos, el lag, los intervalos de sondeo, los fallos de confirmación y la tasa de duplicados. Las caídas se recuperan mediante el timeout de sesión y los offsets, mientras que la reversión sigue el mismo orden gradual compatible en lugar de eliminar forzosamente miembros activos.
Errores comunes
- Modificar un solo consumidor e ignorar la negociación de asignadores a nivel de grupo.
- Considerar el rebalanceo cooperativo como una pausa de cero tiempo a pesar de que las particiones en movimiento aún deben traspasarse.
- Confirmar offsets antes del efecto secundario de negocio.
- Continuar obteniendo datos tras la revocación o confirmar resultados asíncronos no contiguos.
- Cambiar varias configuraciones de timeout al mismo tiempo y perder evidencia causal.
- Monitorear solo el lag mientras se ignoran la frecuencia de rebalanceo, los conjuntos de revocación y los duplicados.
Preguntas de seguimiento
¿El rebalanceo cooperativo garantiza cero duplicados?
No. Las caídas, los reintentos de confirmación y los límites de revocación pueden repetir el trabajo. El objetivo es reducir las pausas de todo el grupo y acotar la ventana de duplicados; los destinos aún requieren idempotencia o deduplicación.
¿Por qué cada miembro debe admitir la asignación cooperativa?
El protocolo del asignador se negocia por el grupo. Un miembro que no pueda interpretar o ejecutar la semántica cooperativa puede hacer que la negociación falle o forzar el comportamiento eager, por lo que primero deben desplegarse versiones compatibles.
¿Qué sucede si el procesamiento excede max.poll.interval?
Usa lotes más pequeños, un grupo asíncrono controlado o un cambio de parámetros revisado cuidadosamente mientras mantienes las llamadas a poll dentro del plazo. Simplemente aumentar el timeout puede retrasar la detección de fallas y extender la propiedad de la partición.
¿Cómo se valida la seguridad de la reversión?
Inyecta caídas de miembros, fluctuaciones de red y fallos de confirmación en un grupo de pruebas (staging). Registra la generación, los offsets, los conjuntos de revocación y los efectos secundarios deduplicados. Verifica que el asignador anterior se estabilice dentro de la matriz de compatibilidad sin omitir offsets no confirmados.