La acumulación de mensajes ocurre cuando el desplazamiento confirmado (committed offset) de un grupo de consumidores queda por detrás del último desplazamiento producido por el broker (high-water mark). La diferencia entre ambos desplazamientos representa la cantidad de mensajes acumulados. Un incremento en este valor no siempre indica un problema; lo importante es determinar si el consumo avanza al mismo ritmo que la producción. Utilice esta guía para diagnosticar si la acumulación es normal y para resolver los casos anómalos.
Funcionamiento del consumo de mensajes
Antes de diagnosticar la acumulación, comprenda el ciclo de consumo de dos fases que ejecuta cada cliente:
Pull: el cliente obtiene los mensajes del broker.
Process: el cliente ejecuta la lógica de negocio para cada mensaje y después confirma el desplazamiento del consumidor en el broker.
La cantidad de mensajes acumulados equivale al high-water mark del broker menos el desplazamiento confirmado del grupo de consumidores. Un número elevado por sí solo no señala un problema. Preste atención a la tendencia: ¿la brecha se mantiene estable, crece o se debe a desplazamientos sin confirmar?
Diagnóstico de la acumulación
Para comprobar si la acumulación es normal, revise las métricas del grupo de consumidores en la consola de ApsaraMQ for Kafka:
Inicie sesión en la consola de ApsaraMQ for Kafka.
En la barra de navegación superior, seleccione la región donde reside su instancia.
En el panel de navegación izquierdo, haga clic en Instances.
En la página Instances, haga clic en el nombre de la instancia de destino.
En la página Instance Details, haga clic en Groups dentro del panel de navegación izquierdo.
En la página Groups, busque el grupo de destino y elija More > Consumer Status en la columna Actions.
En la página Consumer Status, compruebe los valores de Last Consumed At, Accumulated Messages y Consumer Offset.
Estos valores se actualizan cada minuto. Haga clic en Consumption Details para consultar el desplazamiento del consumidor de cada partición.
Utilice a continuación la tabla de decisiones para interpretar las métricas:
|
Symptom |
Diagnosis |
Action |
|
El valor de Last Consumed At es cercano a la hora actual y Accumulated Messages fluctúa dentro de un rango estable |
Comportamiento normal: el cliente extrae y procesa los mensajes a un ritmo constante. |
No se requiere ninguna acción. |
|
Accumulated Messages aumenta de forma continua y Consumer Offset permanece sin cambios |
Comportamiento anómalo: el hilo del consumidor está bloqueado. El cliente dejó de procesar mensajes y de confirmar desplazamientos. |
Consulte Resolve abnormal accumulation. |
|
Accumulated Messages aumenta de forma continua, pero Consumer Offset avanza |
Comportamiento anómalo: el consumo es demasiado lento. El cliente procesa los mensajes, aunque a una velocidad inferior a la de producción. El cuello de botella se encuentra en la fase de procesamiento (fase 2), no en la de extracción. |
Consulte Resolve abnormal accumulation. |
|
Los mensajes parecen acumulados en las particiones, pero el procesamiento posterior funciona con normalidad |
Probable falso positivo. Si el sistema posterior utiliza el modo de consumo |
Confirme los desplazamientos manualmente para eliminar la acumulación reportada. |
|
Accumulated Messages aumenta y Consumer Offset avanza lentamente, mientras que el monitoreo del ancho de banda de consumo a nivel de instancia indica que el rendimiento alcanzó el límite de velocidad |
Posible limitación de velocidad del consumidor. La instancia activó la restricción de rendimiento de consumo. El cliente no está completamente bloqueado, ya que todavía puede extraer mensajes, pero a una velocidad restringida que provoca una acumulación gradual. |
Revise las métricas de monitoreo del ancho de banda de consumo a nivel de instancia. Si se confirma la restricción, evalúe actualizar la especificación de la instancia o reducir el volumen de extracción del consumidor. |
|
Accumulated Messages crece de manera significativa en un tema y el consumo se ralentiza en otros temas de la misma instancia |
Posible impacto indirecto por lecturas en frío. La acumulación en un solo tema no suele afectar directamente a los demás temas de la misma instancia. Sin embargo, si los mensajes acumulados se descargaron al disco, su recuperación genera operaciones de E/S de disco en lugar de lecturas en memoria (lectura en frío). Un alto nivel de IOPS o de rendimiento de lectura en disco puede degradar el rendimiento general de la instancia. |
Revise las métricas de monitoreo de E/S de disco y de rendimiento de red a nivel de instancia. Si las IOPS de lectura o el tráfico de disco son anormalmente altos, priorice la reducción de la acumulación en el tema afectado. |
Un valor alto en Accumulated Messages no siempre significa que exista un problema. La cantidad mostrada depende de la tasa de producción y de la frecuencia con la que se confirman los desplazamientos. Por ejemplo, si un tema recibe 10 000 mensajes por segundo y los desplazamientos se confirman una vez por segundo, el conteo acumulado normalmente fluctuará alrededor de 10 000.
Resolución de la acumulación anómala
Una vez confirmada la acumulación anómala, identifique el cuello de botella y aumente la velocidad de consumo.
Identificación del cuello de botella
Determine si el hilo del consumidor está bloqueado o si simplemente opera con lentitud:
Hilo bloqueado: si Consumer Offset no avanza, es probable que el hilo del consumidor esté atascado. Utilice
jstack(para aplicaciones Java) para capturar un volcado de hilos e identificar el punto de bloqueo. Para obtener más información, consulte jstack - Stack Trace.Procesamiento lento: si Consumer Offset avanza, pero queda rezagado respecto a la producción, analice el perfil de la lógica de procesamiento de mensajes en su aplicación. Busque llamadas de E/S lentas, escrituras en la base de datos u operaciones bloqueantes durante la fase de procesamiento.
Aumento de la velocidad de consumo
Aplique uno o ambos de los siguientes enfoques:
Agregar consumidores: incorpore más instancias de consumidor dentro del mismo grupo de consumidores, ya sea como hilos adicionales en un proceso existente o como procesos independientes. Cada consumidor gestiona una o más particiones. Si la cantidad de consumidores ya iguala o supera el número de particiones, agregar más no tendrá efecto, pues los consumidores adicionales permanecerán inactivos.
Aumentar los hilos de consumo: utilice consumo multihilo dentro de cada instancia de consumidor. Para conocer los detalles de implementación, consulte la sección "Increase consumption rate" en Best practices for consumers.
En la mayoría de los casos, la acumulación anómala de mensajes se debe a un consumo lento o a un hilo de consumo bloqueado. Evite configurar duraciones prolongadas para los parámetros relacionados dentro de la lógica de consumo.
Verificación de rebalanceos
Si los mensajes se acumulan y el estado del consumidor aparece como anómalo en la consola, es posible que el grupo de consumidores esté realizando un rebalanceo. Durante este proceso no se consume ningún mensaje.
Los rebalanceos frecuentes suelen deberse a consumidores que se conectan y desconectan a un ritmo elevado. Para obtener más información, consulte Why do rebalances frequently occur on my consumer client?
Solución de errores read tcp i/o timeout
P: ¿Escalar verticalmente la instancia de ApsaraMQ for Kafka resuelve los errores read tcp i/o timeout que provocan la acumulación de mensajes?
R: El escalamiento vertical generalmente no resuelve de forma directa los errores read tcp i/o timeout. Este error suele relacionarse con problemas de conectividad de red o de configuración del cliente, más que con restricciones de recursos en el servidor. Antes de considerar un escalamiento, siga estos pasos de diagnóstico:
Compruebe que la conexión de red entre el cliente y el broker sea estable. Revise si existe pérdida de paquetes, latencia alta o problemas intermitentes de conectividad.
Revise la versión del cliente. Si es anterior a la 0.10.1.0, actualice a una versión compatible.
Ajuste los parámetros
max.poll.interval.msysession.timeout.ms. Si estos valores son demasiado cortos en relación con el tiempo necesario para procesar cada lote de sondeo, el cliente podría agotar el tiempo de espera y desencadenar un Rebalance no deseado, lo cual interrumpe el consumo y aumenta la acumulación. Establezca estos valores en una duración que contemple el tiempo real de procesamiento de sus mensajes.En la consola de ApsaraMQ for Kafka, revise la página Consumer Status para comprobar si la cantidad de mensajes acumulados y los cambios de desplazamiento coinciden con lo esperado. Considere el escalamiento únicamente si confirmó que el tiempo de espera agotado se debe a un cuello de botella de recursos en el servidor.