Todos los productos
Search
Centro de documentos

ApsaraMQ for Kafka:Límites

Última actualización: Sep 09, 2026

ApsaraMQ for Kafka tiene límites de servicio definidos. Superarlos puede provocar excepciones en las aplicaciones, así que asegúrese de que su uso se mantenga dentro de ellos.

Importante

El acuerdo de nivel de servicio (SLA) no cubre la inestabilidad causada por superar estos límites.

Límites de uso

A continuación se muestran los límites de uso de ApsaraMQ for Kafka.

Elemento

Límite

Descripción

Número total de topics (particiones totales)

Un valor específico

El almacenamiento y la coordinación se gestionan en el nivel de partición. Un exceso de topics (o de particiones totales) fragmenta el almacenamiento, lo que degrada el rendimiento y la estabilidad del clúster.

Número mínimo de particiones por topic

  • Instancias de suscripción y pay-as-you-go:

    • Para topics con almacenamiento en la nube: 2

    • Para topics con almacenamiento local: 1

  • Instancias serverless:

    • Para topics con almacenamiento nativo de la nube: 1

Si el tráfico es alto, una sola partición se convierte en un punto de congestión y provoca desequilibrio de datos. Configure un número adecuado de particiones.

Reducción del número de particiones de un topic

No compatible

Esta es una limitación inherente al diseño de Apache Kafka.

Exposición de ZooKeeper

No compatible

Desde Apache Kafka 0.9.0, los clientes ya no necesitan acceder a ZooKeeper. El ZooKeeper que utiliza ApsaraMQ for Kafka es parcialmente compartido y no se expone por motivos de seguridad. Sus aplicaciones no requieren acceso a ZooKeeper.

Inicio de sesión en la máquina donde está desplegado Message Queue for Apache Kafka

No compatible

Ninguna.

Versiones compatibles

De 2.2.x a 3.3.x

  • Las instancias que no son serverless admiten las versiones de 2.2.x a 2.6.x.

  • Las instancias serverless admiten la versión 3.3.x.

Para actualizar la versión de la instancia, consulte Upgrade an instance version.

Proporción de particiones por topic

1:1

La cantidad de topics disponibles depende directamente del número total de particiones. Por ejemplo, si adquiere una instancia de especificación alikafka.hw.2xlarge con 50 particiones compradas y 1,000 gratuitas, el total será de 50 + 1,000 = 1,050. En este caso, podrá usar hasta 1,050 topics.

Nota

Esto aplica únicamente a las instancias que no son serverless.

Cambio de región de una instancia

No compatible

Una vez desplegada la instancia, su región queda fija y no se puede modificar. Para cambiarla, libere la instancia y adquiera una nueva.

Modificación de las propiedades de red de una instancia

Compatible

Modifique las propiedades de red según lo requiera. Para más información, consulte Upgrade instance configurations.

Tamaño de mensaje

10 MB

Los mensajes no pueden superar los 10 MB. Los mensajes más grandes se rechazan.

Monitoreo y alertas

Compatible

Los datos de monitoreo tienen un retraso de 1 minuto.

Endpoint

Depende de la edición adquirida

  • Instancias que no son serverless:

    • Standard Edition: admite el endpoint predeterminado y el endpoint SSL.

    • Professional Edition: admite el endpoint predeterminado, el endpoint SSL y el endpoint SASL.

  • Instancias serverless: admiten el endpoint predeterminado, el endpoint SSL y el endpoint SASL.

Topics de partición única con almacenamiento en la nube

Pueden dejar de estar disponibles durante interrupciones o actualizaciones.

Cree topics con más de una partición. Si necesita usar una sola partición, seleccione almacenamiento local.

Nota
  • Esta limitación aplica solo a las instancias que no son serverless. En las instancias serverless, el almacenamiento en la nube de partición única ofrece alta disponibilidad.

  • Solo las instancias Professional Edition permiten seleccionar almacenamiento local al crear un topic. Esta función no está disponible en Standard Edition.

Número máximo de mensajes por lote

32,767

Si los mensajes individuales son muy pequeños, establezca batch.size con un valor no mayor a 16,384.

Nota

Este límite aplica únicamente a las instancias que no son serverless.

Nota

Message Queue for Apache Kafka ya no permite adquirir instancias que no sean serverless basadas en ediciones de topics. Para las instancias existentes adquiridas bajo este modelo, la proporción de topics por partición es de 1:16. En las instancias Professional Edition, la cantidad de topics equivale al doble de los topics adquiridos.

Límites de cuota

A continuación se muestran los límites de cuota de Message Queue for Apache Kafka. Superarlos puede causar problemas de estabilidad. La sección "Otros límites" describe escenarios que podrían afectar negativamente al servidor. Utilice estas funciones con precaución para evitar sobrecargarlo y comprometer la estabilidad.

Salvo que se indique lo contrario, los límites aplican por clúster. Para solicitar un aumento de cuota, envíe un ticket.

En la tabla, "//" indica división entera, cuyo resultado se redondea hacia abajo.

Elemento

Límite

Descripción

Instancias que no son serverless

Serverless (Basic)

Serverless (Standard y Professional)

Límite estricto

Conexiones por nodo

  • Comienza en 1,000.

  • Aumenta en 1,000 por cada 100 MB/s adicionales de tráfico real de producción.

  • Máximo: 10,000.

Fórmula:

C = min(10000, 1000 + (F // 100) * 1000)

  • Comienza en 2,000.

  • Aumenta en 1,000 por cada 300 MB/s adicionales de capacidad de producción reservada.

  • Máximo: 10,000.

Fórmula:

C = min(10000, 2000 + (F // 300) * 1000)

Sí

Cantidad de conexiones TCP en un único broker.

Para aumentar el límite de conexiones, submit a ticket.

Cuando se supera el límite, las nuevas conexiones se establecen lentamente y se cierran las conexiones menos utilizadas recientemente (LRU).

Conexiones SSL por nodo

  • Comienza en 200.

  • Aumenta en 100 por cada 100 MB/s adicionales de tráfico real de producción.

  • Máximo: 1,000.

Fórmula:

C = min(1000, 200 + (F // 100) * 100)

  • Comienza en 200.

  • Aumenta en 100 por cada 300 MB/s adicionales de capacidad de producción reservada.

  • Máximo: 1,000.

Fórmula:

C = min(1000, 200 + (F // 300) * 100)

Sí

Cantidad de conexiones TCP SSL en un único broker.

Cuando se supera el límite, las nuevas conexiones se establecen lentamente y se cierran las conexiones menos utilizadas recientemente (LRU).

Tasa de establecimiento de conexiones por nodo

50/segundo

150/segundo

150/segundo

Sí

Cantidad de intentos de conexión por segundo entre un cliente y un servidor. Incluye los intentos con errores por motivos como fallos de autenticación.

Cuando se supera el límite, las nuevas conexiones se establecen lentamente.

Tasa de establecimiento de conexiones SSL por nodo

10/segundo

Sí

Cantidad de intentos de conexión SSL por segundo entre un cliente y un servidor. Incluye los intentos con errores por motivos como fallos de autenticación.

Cuando se supera el límite, las nuevas conexiones se establecen lentamente.

Tamaño de lote

Un tamaño de lote con un percentil 50 (TP50) inferior a 4 KB se considera fragmentado.

No

Tamaño de un lote de mensajes en una solicitud PRODUCE. Los lotes fragmentados (frecuentes y pequeños) incrementan la carga de CPU del servidor y afectan la estabilidad del clúster. Use versiones de cliente 2.4 o posteriores para mejorar la agrupación en lotes. Para más información, consulte Improve send performance (reduce fragmented requests).

Tasa de solicitudes de producción por clúster

  • Comienza en 10,000 solicitudes/segundo.

  • Aumenta en 2,000 por cada 20 MB/s adicionales de tráfico real de producción.

Fórmula:

R = 10000 + (F // 20) * 2000

  • Comienza en 10,000 solicitudes/segundo.

  • Aumenta en 5,000 por cada 300 MB/s adicionales de capacidad de producción reservada.

Fórmula:

R = 10000 + (F // 300) * 5000

  • Comienza en 10,000 solicitudes/segundo.

  • Aumenta en 2,000 por cada 60 MB/s adicionales de capacidad de producción reservada.

Fórmula:

R = 10000 + (F // 60) * 2000

No

Cantidad de solicitudes PRODUCE enviadas por los clientes por segundo. Una tasa elevada incrementa la carga de CPU del servidor y afecta la estabilidad del clúster.

Para aumentar el límite de solicitudes, submit a ticket.

Tasa de solicitudes de extracción por clúster

  • Comienza en 5,000 solicitudes/segundo.

  • Aumenta en 1,000 por cada 20 MB/s adicionales de tráfico real de consumo.

Fórmula:

R = 5000 + (F // 20) * 1000

  • Comienza en 5,000 solicitudes/segundo.

  • Aumenta en 2,500 por cada 100 MB/s adicionales de capacidad de suscripción reservada.

Fórmula:

R = 5000 + (F // 100) * 2500

  • Comienza en 5,000 solicitudes/segundo.

  • Por cada incremento de 20 MB/s en el rendimiento de suscripción reservado, la cantidad de solicitudes por segundo aumenta en 1,000.

Fórmula:

R = 5000 + (F // 20) * 1000

No

Cantidad de solicitudes FETCH de los clientes por segundo. Una tasa elevada incrementa la carga de CPU del servidor y afecta la estabilidad del clúster.

Para aumentar el límite de solicitudes, submit a ticket.

Tasa de confirmación de desplazamientos por nodo

  • Comienza en 100 solicitudes/segundo.

  • Aumenta en 100 por cada 100 MB/s adicionales de tráfico real de producción.

  • Máximo: 1,000 solicitudes/segundo.

Fórmula:

R = min(1000, 100 + (F // 100) * 100)

  • Comienza en 100 solicitudes/segundo.

  • Aumenta en 100 por cada 100 MB/s adicionales de capacidad de producción reservada.

  • Máximo: 1,000 solicitudes/segundo.

Fórmula:

R = min(1000, 100 + (F // 100) * 100)

No

Cantidad de solicitudes OFFSET_COMMIT enviadas por los clientes por segundo. Una tasa elevada incrementa la carga de CPU del servidor y afecta la estabilidad del clúster.

Para aumentar el límite de solicitudes, submit a ticket.

Tasa de solicitudes de metadatos por clúster

  • Comienza en 100 solicitudes/segundo.

  • Aumenta en 100 por cada 100 MB/s adicionales de tráfico real de producción.

  • Máximo: 1,000 solicitudes/segundo.

Fórmula:

R = min(1000, 100 + (F // 100) * 100)

  • Comienza en 100 solicitudes/segundo.

  • Aumenta en 100 por cada 100 MB/s adicionales de capacidad de producción reservada.

  • Máximo: 1,000 solicitudes/segundo.

Fórmula:

R = min(1000, 100 + (F // 100) * 100)

No

Solicitudes de metadatos de clientes recibidas por el servidor, como METADATA, INIT_PRODUCER_ID, CREATE_ACL, and JOIN_GROUP.

Aviso

Una tasa de solicitudes excesiva puede afectar la estabilidad del clúster.

Número máximo de particiones

Para conocer el número máximo de particiones según las distintas especificaciones de instancia, consulte Instance specifications and partition limits.

Sí

Total de particiones en todos los topics. Si se supera el límite, no podrá crear nuevos topics ni agregar particiones.

Para aumentar el límite de particiones, submit a ticket.

Tasa de creación o eliminación de particiones por clúster

900 particiones cada 10 segundos

No

Incluye todas las operaciones sobre particiones ejecutadas desde la consola, la API o las herramientas de administración de Kafka.

Cantidad de grupos de consumidores por clúster

2,000 por clúster

Se recomienda una proporción de suscripción de 1:1 entre topics y grupos, sin exceder 3:1.

No

Cantidad de grupos de consumidores utilizados por los clientes.

Para aumentar el límite de grupos, submit a ticket.

Aviso

Un número excesivo de grupos de consumidores incrementa la carga del coordinador en el servidor y complica la gestión de metadatos, lo cual afecta el rendimiento y el tiempo de recuperación ante fallos.

Versión del formato de mensaje

La versión del formato de mensaje para producir y consumir debe ser V1 o posterior.

Sí

Se recomienda utilizar versiones de cliente 2.4 o posteriores.

Aviso

Usar un formato de mensaje de Kafka antiguo puede impedir la producción o el consumo de mensajes. Además, genera problemas como mayor uso de CPU en el servidor, menor rendimiento y complicaciones de compatibilidad o seguridad.

Interceptación de marcas de tiempo no válidas

Cuando message.timestamp.type=CreateTime, el broker rechaza un mensaje si la diferencia entre su marca de tiempo al recibirlo y la incluida en el mensaje supera el valor configurado en message.timestamp.difference.max.ms. Esta configuración evita marcas de tiempo incorrectas. Si la marca de tiempo se establece demasiado en el pasado, el segmento de registro podría eliminarse de inmediato; si se define muy lejana en el futuro, es posible que nunca se elimine.

Sí

El cliente recibe un error claro: INVALID_TIMESTAMP (32, "The timestamp of the message is out of acceptable range.").

Límite de tamaño de topics compactados

Los topics compactados no están habilitados de forma predeterminada.

Sí

Los topics compactados se deshabilitan de forma predeterminada para evitar que patrones de escritura anormales agoten el almacenamiento del clúster y provoquen una caída.

Si requiere esta función, envíe un ticket.

Otros límites

  • Habilitar algoritmos de compresión como GZIP consume más recursos del servidor, lo que incrementa la latencia y reduce el rendimiento.

  • Inicializar una gran cantidad de transacciones a alta frecuencia para obtener un Producer Id provoca errores de falta de memoria (OOM) y sobrecarga en el servidor, lo que afecta la estabilidad. Por este motivo, ajustamos el parámetro del kernel transactional.id.expiration.ms a 60 minutos. Si tiene requisitos específicos, submit a ticket.

  • Si la utilización de CPU de una instancia supera el 85%, la estabilidad del clúster se ve afectada. Esto genera problemas como interrupciones o fluctuaciones de latencia prolongada en la producción y el consumo de mensajes.

  • El rendimiento de Kafka depende del clúster. Si su comportamiento de producción o la asignación de particiones presentan desequilibrios, es posible que no aproveche toda la capacidad del clúster.

  • La función de mensajería transaccional de código abierto presenta diversos problemas conocidos sin resolver, como KAFKA-12671. Úsela con precaución. Para más información, consulte KAFKA ISSUES.

  • En Kafka pueden duplicarse mensajes en distintos escenarios, como durante un reequilibrio. Para evitar impactos en su negocio por mensajes duplicados, implemente lógica de consumo idempotente.

No

Ninguna