ApsaraMQ for Kafka:Troubleshoot frequent consumer rebalances in ApsaraMQ for Kafka

Síntoma

Se producen rebalanceos frecuentes en el cliente consumidor al usar ApsaraMQ for Kafka.

Causa

La causa raíz depende de la versión del cliente, ya que el mecanismo de latidos difiere entre versiones.

• Clientes anteriores a la versión 0.10.1.0: no existe un hilo dedicado para los latidos. Estos se envían dentro de la llamada a poll(). Cuando el procesamiento de mensajes tarda más que session.timeout.ms, el broker no recibe ningún latido, elimina al consumidor del grupo y desencadena un rebalanceo.

• Clientes de la versión 0.10.1.0 o posteriores: un hilo dedicado envía latidos de forma independiente al procesamiento de mensajes. Sin embargo, si el consumidor no llama a poll() dentro del intervalo definido por max.poll.interval.ms (valor predeterminado: 5 minutos), el cliente abandona el grupo de consumidores y se desencadena un rebalanceo. El valor predeterminado de max.poll.interval.ms es de 5 minutos. Esta situación ocurre normalmente cuando el procesamiento de un lote de mensajes toma demasiado tiempo.

A continuación se muestran los mensajes de error asociados comúnmente con los rebalanceos. Identificar el error específico le ayudará a localizar la causa raíz con mayor rapidez:

• **NOT_COORDINATOR / join group failed**: indica que el coordinador de grupo cambió (por ejemplo, debido a un failover del broker) o que un tiempo de espera agotado en los latidos provocó la eliminación del consumidor del grupo. El consumidor intenta reincorporarse al grupo, lo cual desencadena un rebalanceo.

• **MemberIdRequiredException / consumer poll timeout**: en clientes anteriores a la versión 0.10.1.0, este error suele deberse a un consumidor bloqueado que impide el envío de latidos. En clientes de la versión 0.10.1.0 o posteriores, señala que un procesamiento lento de mensajes hizo que el consumidor superara max.poll.interval.ms sin llamar a poll(), lo que obliga al cliente a abandonar el grupo de consumidores.

• **CommitFailedException**: indica que el consumidor tardó demasiado en procesar los mensajes o no logró enviar los latidos a tiempo. El broker elimina al consumidor del grupo (y desencadena un rebalanceo) antes de que finalice la confirmación del desplazamiento.

Parámetros clave

Los siguientes parámetros controlan el comportamiento de los rebalanceos:

Soluciones

1. Ajuste los valores de los parámetros/@cmd

   Configure los siguientes parámetros según la versión de su cliente:

   **session.timeout.ms**

   Versión del cliente	Valor recomendado
   Anterior a 0.10.1.0	Mayor que el tiempo necesario para procesar un lote de mensajes, pero sin exceder los 30 segundos. Se recomiendan 25 segundos.
   0.10.1.0 o posterior	Conserve el valor predeterminado de 10 segundos.

   **max.poll.records**

   Establezca este valor muy por debajo del resultado de la siguiente fórmula:

   max.poll.records << messages_per_thread_per_second * number_of_threads * max.poll.interval.ms

   **max.poll.interval.ms** (solo para la versión 0.10.1.0 o posterior)

   Establezca este valor por encima del resultado de la siguiente fórmula:

   max.poll.interval.ms > max.poll.records / (messages_per_thread_per_second * number_of_threads)

   **heartbeat.interval.ms** (versión 0.10.1.0 o posterior)

   Establezca heartbeat.interval.ms en un máximo de 10 000 milisegundos (10 segundos). Este valor controla la frecuencia con la que el consumidor envía latidos al broker y siempre debe ser menor que session.timeout.ms. Una práctica habitual consiste en fijarlo en un tercio de session.timeout.ms.

   Configuración de parámetros en Spring Kafka

   Si utiliza Spring Kafka, configure todos los parámetros anteriores en el archivo application.yml:

   spring:
     kafka:
       consumer:
         properties:
           session.timeout.ms: 10000
           heartbeat.interval.ms: 3000
           max.poll.interval.ms: 300000
           max.poll.records: 50

   Ajuste los valores para que coincidan con su throughput de consumo. El valor de max.poll.interval.ms debe superar el tiempo necesario para procesar un solo lote de max.poll.records mensajes.

2. Mejore la velocidad de consumo y separe los hilos de procesamiento/@cmd

   Traslade el procesamiento de mensajes a un hilo dedicado para que el hilo del consumidor pueda llamar a poll() de manera puntual. Esto evita que un procesamiento lento bloquee los latidos o supere el intervalo de sondeo.

3. Reduzca la cantidad de temas por grupo de consumidores/@cmd

   Mantenga cada grupo de consumidores suscrito a un máximo de cinco temas. Para lograr una estabilidad óptima, suscriba un solo tema por grupo de consumidores.

4. Actualice a la versión 0.10.1.0 o posterior/@cmd

   Los clientes anteriores a la versión 0.10.1.0 carecen de un hilo dedicado para los latidos, por lo que son vulnerables a tiempos de espera agotados durante cargas de procesamiento intensas. Al actualizar a la versión 0.10.1.0 o posterior, se desacopla el envío de latidos del procesamiento de mensajes y se elimina este tipo de rebalanceos.

Preguntas frecuentes

P: ¿Cómo reduzco temporalmente los rebalanceos para acelerar el consumo de mensajes acumulados?

Siga estos pasos para minimizar los rebalanceos y limpiar la acumulación de mensajes lo más rápido posible:

1. Utilice un cliente de la versión 0.10.1.0 o posterior. Los clientes anteriores a esta versión carecen de un hilo dedicado para los latidos y tienden a generar rebalanceos bajo cargas intensas. Actualice antes de ajustar otros parámetros.

2. **Aumente max.poll.interval.ms** hasta un valor superior al tiempo máximo necesario para procesar un solo lote de mensajes. Así evitará que el consumidor se considere inactivo durante un procesamiento intenso.

3. **Disminuya max.poll.records** para reducir la cantidad de mensajes obtenidos en cada llamada a poll(). Los lotes más pequeños terminan más rápido y reducen el riesgo de superar max.poll.interval.ms.

4. Reduzca la cantidad de temas suscritos por grupo de consumidores. Limite las suscripciones a cinco temas o menos. Para lograr una estabilidad óptima, suscriba un solo tema por grupo de consumidores.

5. Evite bloquear el hilo del consumidor. Traslade la lógica de procesamiento de mensajes a un hilo asíncrono independiente para que el hilo del consumidor quede libre y llame a poll() de manera puntual.