ApsaraMQ for Kafka:Client parameter configuration

acks

Controla cuántas confirmaciones del broker requiere el productor antes de considerar exitoso un envío.

Valor recomendado: 1 para la mayoría de las cargas de trabajo que priorizan el rendimiento sobre la durabilidad estricta.

retries

Número máximo de veces que el productor reintenta un envío con errores. Un valor más alto ayuda al productor a recuperarse de fallos transitorios del broker, como elecciones de líder. Combínelo con retry.backoff.ms para controlar el ritmo de los reintentos.

retry.backoff.ms

Retraso entre reintentos de envío. Un valor demasiado bajo puede causar tormentas de reintentos durante las conmutaciones por error del broker.

batch.size

Tamaño máximo de un solo lote por partición. Cuando un lote alcanza este tamaño, el productor lo envía inmediatamente.

Mantenga el valor predeterminado de 16384 para la mayoría de las cargas de trabajo. Un valor menor aumenta el número de solicitudes de red y reduce el rendimiento. Si incrementa batch.size, asegúrese de que buffer.memory sea lo suficientemente grande para alojar los lotes más grandes.

linger.ms

Tiempo máximo que el productor espera a que se llene un lote antes de enviarlo. Esto funciona como el algoritmo de Nagle en TCP: una vez que un lote alcanza batch.size, se envía inmediatamente sin importar el temporizador de espera. Si el lote aún está por debajo de batch.size cuando transcurre linger.ms, el productor envía lo que se haya acumulado.

Un valor mayor de linger.ms aumenta la eficiencia del procesamiento por lotes y el rendimiento a costa de la latencia por mensaje.

buffer.memory

Memoria total que el productor asigna para almacenar en búfer los registros no enviados en todas las particiones. Si este pool se agota, send() se bloquea o lanza una excepción dependiendo de max.block.ms. Un búfer insuficiente provoca una asignación de memoria lenta, reducción del rendimiento o tiempos de espera de envío agotados.

Unidad: bytes. Predeterminado: 33554432 (32 MB).

Fórmula de dimensionamiento:

buffer.memory >= batch.size x number_of_partitions x 2

Por ejemplo, con batch.size=16384 y 50 particiones:

16384 x 50 x 2 = 1,638,400 bytes (~1.6 MB minimum)

Si incrementa batch.size para mejorar el rendimiento, escale buffer.memory proporcionalmente.

partitioner.class

Determina cómo asigna el productor los registros a las particiones. La estrategia de particionamiento adhesivo reduce el número de lotes incompletos al llenar el lote de una partición antes de pasar a la siguiente.

Si su cliente productor es anterior a la versión 2.4, establezca explícitamente el particionador adhesivo para mejorar la eficiencia del procesamiento por lotes.

fetch.min.bytes

Cantidad mínima de datos que acumula el broker antes de devolver una respuesta de obtención. Un valor mayor reduce la frecuencia de obtención y la sobrecarga de CPU del broker, lo que mejora el rendimiento pero aumenta la latencia de mensajes de extremo a extremo. Unidad: bytes.

Evalúe la tasa de mensajes de su productor antes de establecer este valor. Si los mensajes llegan lentamente, un valor grande de fetch.min.bytes añade un retraso innecesario.

fetch.max.wait.ms

Tiempo máximo que espera el broker para acumular fetch.min.bytes antes de devolver una respuesta. Unidad: milisegundos.

El comportamiento varía según el tipo de almacenamiento:

• Almacenamiento local: El broker espera hasta que se alcance fetch.min.bytes o transcurra fetch.max.wait.ms, lo que ocurra primero.

• Almacenamiento en la nube: El broker devuelve una respuesta inmediatamente cuando llegan nuevos datos, sin importar fetch.min.bytes.

max.partition.fetch.bytes

Cantidad máxima de datos que devuelve el broker por partición en una sola obtención. Unidad: bytes.

session.timeout.ms

Tiempo máximo entre latidos antes de que el broker considere muerto al consumidor y desencadene un reequilibrio.

max.poll.records

Número máximo de registros devueltos en una sola llamada a poll(). Si el consumidor no puede procesar tantos registros antes de la siguiente fecha límite de poll(), el broker lo considera muerto y desencadena un reequilibrio.

Fórmula de dimensionamiento:

max.poll.records < messages_per_thread_per_second x consumer_threads x session_timeout_seconds

Por ejemplo, con 500 msg/s por hilo, 4 hilos y un tiempo de espera de sesión de 45 segundos:

500 x 4 x 45 = 90,000

Establezca max.poll.records por debajo de este valor para asegurar que el consumidor siempre termine el procesamiento antes de que expire la sesión.

max.poll.interval.ms

Intervalo máximo entre llamadas consecutivas a poll() antes de que el broker elimine al consumidor del grupo. Este parámetro se aplica solo al cliente Java 0.10.1 y posteriores, donde los latidos se ejecutan en un hilo separado.

Fórmula de dimensionamiento:

max.poll.interval.ms > time_per_record x max.poll.records

En la mayoría de los casos, el valor predeterminado de 300000 (5 minutos) es suficiente. Auméntelo solo si su lógica de procesamiento es excepcionalmente lenta.

enable.auto.commit

Controla si el consumidor confirma automáticamente los desplazamientos en un intervalo fijo.

auto.commit.interval.ms

Intervalo para confirmaciones automáticas de desplazamientos cuando enable.auto.commit es true.

Un intervalo más corto reduce la ventana para mensajes duplicados tras un fallo, pero aumenta el número de solicitudes de confirmación al broker.

auto.offset.reset

Determina qué sucede cuando el consumidor no tiene un desplazamiento confirmado o el desplazamiento confirmado no es válido (por ejemplo, el desplazamiento se eliminó debido a políticas de retención).

Valor recomendado: latest. El uso de earliest hace que el consumidor reprocese todos los mensajes retenidos cada vez que encuentra un desplazamiento no válido, lo que puede provocar procesamiento duplicado y un pico en el retraso del consumidor.

Si su aplicación maneja la gestión de desplazamientos manualmente (por ejemplo, almacenando desplazamientos en una base de datos externa), establezca esto en none.