ApsaraMQ for Kafka:Best practices for consumers

Cómo evitar reequilibrios frecuentes

Los reequilibrios pausan el consumo mientras se reasignan las particiones. Si ocurren con frecuencia, afectan el rendimiento y aumentan la latencia de procesamiento. Esto sucede cuando los heartbeats de los consumidores exceden el tiempo de espera.

Para evitar reequilibrios frecuentes, ajuste los parámetros correspondientes o incremente la velocidad de consumo. Para consultar los pasos detallados de solución de problemas, consulte Why do rebalances frequently occur on my consumer client?

Número recomendado de particiones

El número predeterminado de particiones en la consola de ApsaraMQ for Kafka es 12, valor adecuado para la mayoría de las cargas de trabajo. Al escalar, siga estas recomendaciones:

Un grupo se suscribe a varios topics

Un solo grupo de consumidores puede suscribirse a múltiples topics. Los mensajes de todos los topics suscritos se distribuyen equitativamente entre los consumidores del grupo.

String topicStr = kafkaProperties.getProperty("topic");
String[] topics = topicStr.split(",");
for (String topic: topics) {
    subscribedTopics.add(topic.trim());
}
consumer.subscribe(subscribedTopics);

Varios grupos se suscriben a un topic

Varios grupos de consumidores pueden suscribirse de forma independiente al mismo topic. Cada grupo recibe todos los mensajes y opera sin afectar a los demás.

Utilice este patrón cuando distintas aplicaciones necesiten procesar el mismo flujo de datos de manera independiente; por ejemplo, un grupo para análisis en tiempo real y otro para archivado de datos.

Mantenga un grupo por aplicación

Use un grupo de consumidores exclusivo para cada aplicación. Si una sola aplicación debe ejecutar diferentes lógicas de consumo, cree archivos de configuración separados (por ejemplo, kafka1.properties y kafka2.properties) con valores distintos de group.id.

Coincidencia de suscripciones dentro de un grupo

Todos los consumidores de un mismo grupo deben suscribirse al mismo conjunto de topics. Las suscripciones no coincidentes complican la solución de problemas y pueden causar comportamientos inesperados durante el reequilibrio.

Confirmación automática frente a confirmación manual

ApsaraMQ for Kafka ofrece dos parámetros para confirmar los offsets de consumidor:

Con la confirmación automática habilitada, el cliente verifica el tiempo transcurrido desde la última confirmación antes de cada sondeo. Si el tiempo supera el valor de auto.commit.interval.ms, confirma el offset actual.

Confirmación manual de offsets

Para confirmar los offsets manualmente, establezca enable.auto.commit en false y llame a la función commit(offsets) después de procesar cada lote.

Comportamiento de restablecimiento de offsets

Los offsets de consumidor se restablecen en dos situaciones:

• No existe un offset confirmado: por ejemplo, cuando un consumidor se conecta a un broker por primera vez.

• El offset confirmado no es válido: por ejemplo, el offset máximo en una partición es 10, pero el consumidor intenta leer desde el offset 11.

Controle el comportamiento de restablecimiento en clientes Java mediante auto.offset.reset:

Implementación de consumo idempotente

Si su aplicación es sensible a los duplicados (por ejemplo, transacciones financieras o procesamiento de pedidos), implemente la deduplicación a nivel de aplicación:

1. Asigne una clave única a cada mensaje durante la producción (por ejemplo, un ID de transacción).

2. Antes de procesar un mensaje consumido, compruebe si la clave ya se procesó.

3. Omita los mensajes cuyas claves ya hayan sido procesadas.

Si su aplicación tolera duplicados ocasionales (por ejemplo, agregación de métricas o ingesta de registros), omita este paso.

Causas comunes de acumulación

Incremento del rendimiento de consumo

Agregue más consumidores. Inicie instancias adicionales de consumidores (un hilo por consumidor) o despliegue más procesos de consumo. El número de consumidores activos no puede superar el número de particiones; los excedentes permanecerán inactivos.

Utilice un pool de hilos para el procesamiento. Desacople el sondeo del procesamiento para paralelizar el trabajo:

1. Defina un pool de hilos con un número fijo de hilos de trabajo.

2. Recupere un lote de mensajes mediante sondeo.

3. Envíe cada mensaje al pool de hilos para su procesamiento concurrente.

4. Una vez completadas todas las tareas del lote, recupere el siguiente.

Este patrón mantiene la capacidad de respuesta del bucle de sondeo mientras distribuye el trabajo de procesamiento entre varios hilos.