Limites de Message Queue for Apache Kafka - ApsaraMQ for Kafka

ApsaraMQ for Kafka impose des limites de service. Le dépassement de ces limites peut provoquer des exceptions applicatives ; veillez donc à ce que votre utilisation reste dans les seuils autorisés.

Important

Le contrat de niveau de service (SLA) ne couvre pas l'instabilité causée par le dépassement de ces limites.

Limites d'utilisation

Le tableau suivant répertorie les limites d'utilisation d'ApsaraMQ for Kafka.

Élément	Limite	Description
Nombre total de topics (total des partitions)	Une valeur spécifique	Le stockage et la coordination s'effectuent au niveau de la partition. Un nombre excessif de topics (ou de partitions totales) peut entraîner une fragmentation du stockage, ce qui dégrade les performances et la stabilité du cluster.
Nombre minimal de partitions par topic	Instances en abonnement et à la demande : Pour les topics utilisant le stockage cloud : 2 Pour les topics utilisant le stockage local : 1 Instances serverless : Pour les topics utilisant le stockage natif cloud : 1	Si le trafic est élevé, une seule partition peut devenir un point chaud et provoquer un déséquilibre des données. Configurez un nombre approprié de partitions.
Réduction du nombre de partitions pour un topic	Non pris en charge	Il s'agit d'une limitation inhérente à la conception d'Apache Kafka.
Exposition de ZooKeeper	Non pris en charge	Depuis Apache Kafka 0.9.0, les clients n'ont plus besoin d'accéder à ZooKeeper. Le ZooKeeper utilisé par ApsaraMQ for Kafka est partiellement partagé et n'est pas exposé pour des raisons de sécurité. Vos applications n'ont pas besoin d'accéder à ZooKeeper.
Connexion à la machine sur laquelle Message Queue for Apache Kafka est déployé	Non pris en charge	Aucune.
Versions prises en charge	2.2.x à 3,3.x	Les instances non serverless prennent en charge les versions 2.2.x à 2.6.x. Les instances serverless prennent en charge la version 3.3.x. Pour mettre à jour la version de l'instance, consultez Mettre à jour la version d'une instance.
Ratio partition/topic	1:1	Le nombre de topics disponibles est directement lié au nombre total de partitions. Par exemple, si vous achetez une instance avec la spécification alikafka.hw.2xlarge disposant de 50 partitions achetées et de 1 000 partitions gratuites, le nombre total de partitions est de 50 + 1 000 = 1 050. Dans ce cas, vous pouvez utiliser jusqu'à 1 050 topics. Remarque Cela s'applique uniquement aux instances non serverless.
Modification de la région d'une instance	Non pris en charge	Une fois qu'une instance est déployée, sa région est fixe et ne peut pas être modifiée. Pour changer de région, libérez l'instance et achetez-en une nouvelle.
Modification des propriétés réseau d'une instance	Pris en charge	Vous pouvez modifier les propriétés réseau selon vos besoins. Pour plus d'informations, consultez Mettre à niveau les configurations de l'instance.
Taille du message	10 Mo	Les messages ne peuvent pas dépasser 10 Mo. Les messages plus volumineux sont rejetés.
Surveillance et alertes	Pris en charge	Les données de surveillance présentent un délai d'une minute.
Endpoint	Dépend de l'édition achetée	Instances non serverless : Édition Standard : prend en charge l'endpoint par défaut et l'endpoint SSL. Édition Professionnelle : prend en charge l'endpoint par défaut, l'endpoint SSL et l'endpoint SASL. Instances serverless : prennent en charge l'endpoint par défaut, l'endpoint SSL et l'endpoint SASL.
Topics à partition unique utilisant le stockage cloud	Peuvent devenir indisponibles lors d'arrêts ou de mises à niveau.	Créez des topics comportant plusieurs partitions. Si vous devez utiliser une seule partition, sélectionnez le stockage local. Remarque Cette limitation s'applique uniquement aux instances non serverless. Sur les instances serverless, le stockage cloud à partition unique est hautement disponible. Seules les instances de l'édition Professionnelle permettent de sélectionner le stockage local lors de la création d'un topic. Cette fonctionnalité n'est pas disponible pour les instances de l'édition Standard.
Nombre maximal de messages par lot	32 767	Si les messages individuels sont très petits, définissez `batch.size` sur une valeur inférieure ou égale à 16 384. Remarque Cette limite s'applique uniquement aux instances non serverless.

Remarque

Message Queue for Apache Kafka ne prend plus en charge l'achat d'instances non serverless basées sur des éditions par topic. Pour les instances existantes achetées de cette manière, le ratio topic/partition est de 1:16. Pour les instances de l'édition Professionnelle, le nombre de topics est le double du nombre de topics achetés.

Limites de quota

Le tableau suivant répertorie les limites de quota pour Message Queue for Apache Kafka. Le dépassement de ces limites peut entraîner des problèmes de stabilité. La section « Autres limites » répertorie les scénarios susceptibles d'affecter négativement le serveur. Utilisez ces fonctionnalités avec précaution pour éviter de surcharger le serveur et d'impacter sa stabilité.

Sauf indication contraire, les limites s'appliquent par cluster. Pour demander une augmentation de quota, soumettez un ticket.

Dans le tableau, « // » indique une division entière, qui arrondit vers le bas.

Élément	Limite				Description
Élément	Instances non serverless	Serverless (Basic)	Serverless (Standard et Professionnelle)	Limite stricte	Description
Connexions par nœud	Commence à 1 000. Augmente de 1 000 pour chaque tranche supplémentaire de 100 Mo/s de trafic de production réel. Maximum : 10 000. Formule : `C = min(10000, 1000 + (F // 100) * 1000)`	Commence à 2 000. Augmente de 1 000 pour chaque tranche supplémentaire de 300 Mo/s de capacité de production réservée. Maximum : 10 000. Formule : `C = min(10000, 2000 + (F // 300) * 1000)`		Oui	Le nombre de connexions TCP sur un seul broker. Pour augmenter la limite de connexion, soumettez un ticket. Lorsque la limite est dépassée, les nouvelles connexions s'établissent lentement et les connexions les moins récemment utilisées (LRU) sont terminées.
Connexions SSL par nœud	Commence à 200. Augmente de 100 pour chaque tranche supplémentaire de 100 Mo/s de trafic de production réel. Maximum : 1 000. Formule : `C = min(1000, 200 + (F // 100) * 100)`	Commence à 200. Augmente de 100 pour chaque tranche supplémentaire de 300 Mo/s de capacité de production réservée. Maximum : 1 000. Formule : `C = min(1000, 200 + (F // 300) * 100)`		Oui	Le nombre de connexions TCP SSL sur un seul broker. Lorsque la limite est dépassée, les nouvelles connexions s'établissent lentement et les connexions les moins récemment utilisées (LRU) sont terminées.
Taux d'établissement de connexion par nœud	50/seconde	150/seconde	150/seconde	Oui	Le nombre de tentatives de connexion par seconde entre un client et un serveur. Cela inclut les tentatives ayant échoué pour des raisons telles qu'un échec d'authentification. Lorsque la limite est dépassée, les nouvelles connexions s'établissent lentement.
Taux d'établissement de connexion SSL par nœud	10/seconde			Oui	Le nombre de tentatives de connexion SSL par seconde entre un client et un serveur. Cela inclut les tentatives ayant échoué pour des raisons telles qu'un échec d'authentification. Lorsque la limite est dépassée, les nouvelles connexions s'établissent lentement.
Taille du lot	Une taille de lot dont le 50e percentile (TP50) est inférieur à 4 Ko est considérée comme fragmentée.			Non	La taille d'un lot de messages dans une requête PRODUCE. Les lots fragmentés (lots fréquents et de petite taille) augmentent la charge CPU du serveur et affectent la stabilité du cluster. Utilisez des versions de client 2.4 ou ultérieures pour améliorer le regroupement en lots. Pour plus d'informations, consultez Améliorer les performances d'envoi (réduire les requêtes fragmentées).
Taux de requête Produce par cluster	Commence à 10 000 requêtes/seconde. Augmente de 2 000 pour chaque tranche supplémentaire de 20 Mo/s de trafic de production réel. Formule : `R = 10000 + (F // 20) * 2000`	Commence à 10 000 requêtes/seconde. Augmente de 5 000 pour chaque tranche supplémentaire de 300 Mo/s de capacité de production réservée. Formule : `R = 10000 + (F // 300) * 5000`	Commence à 10 000 requêtes/seconde. Augmente de 2 000 pour chaque tranche supplémentaire de 60 Mo/s de capacité de production réservée. Formule : `R = 10000 + (F // 60) * 2000`	Non	Le nombre de requêtes PRODUCE envoyées par les clients par seconde. Un taux de requête élevé peut augmenter la charge CPU du serveur et affecter la stabilité du cluster. Pour augmenter la limite de requêtes, soumettez un ticket.
Taux de requête Fetch par cluster	Commence à 5 000 requêtes/seconde. Augmente de 1 000 pour chaque tranche supplémentaire de 20 Mo/s de trafic de consommation réel. Formule : `R = 5000 + (F // 20) * 1000`	Commence à 5 000 requêtes/seconde. Augmente de 2 500 pour chaque tranche supplémentaire de 100 Mo/s de capacité d'abonnement réservée. Formule : `R = 5000 + (F // 100) * 2500`	Commence à 5 000 requêtes/seconde. Pour chaque augmentation de 20 Mo/s du débit d'abonnement réservé, le nombre de requêtes par seconde augmente de 1 000. Formule : `R = 5000 + (F // 20) * 1000`	Non	Le nombre de requêtes FETCH provenant des clients par seconde. Un taux de requête élevé peut augmenter la charge CPU du serveur et affecter la stabilité du cluster. Pour augmenter la limite de requêtes, soumettez un ticket.
Taux de validation d'offset par nœud	Commence à 100 requêtes/seconde. Augmente de 100 pour chaque tranche supplémentaire de 100 Mo/s de trafic de production réel. Maximum : 1 000 requêtes/seconde. Formule : `R = min(1000, 100 + (F // 100) * 100)`	Commence à 100 requêtes/seconde. Augmente de 100 pour chaque tranche supplémentaire de 100 Mo/s de capacité de production réservée. Maximum : 1 000 requêtes/seconde. Formule : `R = min(1000, 100 + (F // 100) * 100)`		Non	Le nombre de requêtes OFFSET_COMMIT envoyées par les clients par seconde. Un taux de requête élevé peut augmenter la charge CPU du serveur et affecter la stabilité du cluster. Pour augmenter la limite de requêtes, soumettez un ticket.
Taux de requête de métadonnées par cluster	Commence à 100 requêtes/seconde. Augmente de 100 pour chaque tranche supplémentaire de 100 Mo/s de trafic de production réel. Maximum : 1 000 requêtes/seconde. Formule : `R = min(1000, 100 + (F // 100) * 100)`	Commence à 100 requêtes/seconde. Augmente de 100 pour chaque tranche supplémentaire de 100 Mo/s de capacité de production réservée. Maximum : 1 000 requêtes/seconde. Formule : `R = min(1000, 100 + (F // 100) * 100)`		Non	Requêtes de métadonnées client reçues par le serveur, telles que `METADATA, INIT_PRODUCER_ID, CREATE_ACL et JOIN_GROUP`. Avertissement Un taux de requête excessif peut affecter la stabilité du cluster.
Nombre maximal de partitions	Pour le nombre maximal de partitions selon les différentes spécifications d'instance, consultez Spécifications d'instance et limites de partition.			Oui	Le nombre total de partitions sur tous les topics. Si la limite est dépassée, vous ne pouvez pas créer de nouveaux topics ni ajouter de partitions. Pour augmenter la limite de partitions, soumettez un ticket.
Taux de création/suppression de partitions par cluster	900 partitions toutes les 10 secondes			Non	Cela inclut toutes les opérations de partition effectuées via la console, l'API ou les outils Kafka Admin.
Nombre de groupes de consommateurs par cluster	2 000 par cluster Le ratio d'abonnement recommandé entre les topics et les groupes est de 1:1 et ne doit pas dépasser 3:1.			Non	Le nombre de groupes de consommateurs utilisés par les clients. Pour augmenter la limite de groupes, soumettez un ticket. Avertissement Un nombre excessif de groupes de consommateurs peut augmenter la charge du coordinateur sur le serveur et compliquer la gestion des métadonnées, ce qui affecte les performances et le temps de récupération après incident.
Version du format de message	La version du format de message pour la production et la consommation de messages doit être V1 ou ultérieure.			Oui	Nous recommandons d'utiliser des versions de client 2.4 ou ultérieures. Avertissement L'utilisation d'un ancien format de message Kafka peut empêcher la production ou la consommation de messages et entraîner des problèmes tels qu'une augmentation de l'utilisation du CPU du serveur, une diminution du débit et des problèmes de compatibilité ou de sécurité.
Interception des horodatages non valides	Lorsque `message.timestamp.type=CreateTime`, le broker rejette un message si la différence entre l'horodatage du broker à la réception et l'horodatage du message dépasse la valeur configurée de `message.timestamp.difference.max.ms`. Cette configuration empêche les réglages d'horodatage incorrects. Si l'horodatage est défini trop loin dans le passé, le segment de journal peut être supprimé immédiatement. S'il est défini trop loin dans le futur, le segment de journal risque de ne jamais être supprimé.			Oui	Le client reçoit une erreur claire : INVALID_TIMESTAMP (32, "The timestamp of the message is out of acceptable range.").
Limite de taille des topics compactés	Les topics compactés ne sont pas activés par défaut.			Oui	Les topics compactés sont désactivés par défaut pour empêcher les schémas d'écriture anormaux d'épuiser le stockage du cluster et de provoquer un crash. Si vous avez besoin de cette fonctionnalité, soumettez un ticket.
Autres limites	L'activation d'algorithmes de compression comme GZIP consomme davantage de ressources serveur, ce qui peut augmenter la latence et réduire le débit. L'initialisation d'un grand nombre de transactions à haute fréquence pour obtenir un `Producer Id` peut provoquer des erreurs d'épuisement de la mémoire (OOM) et une surcharge du serveur, ce qui affecte la stabilité. Pour cette raison, nous avons ajusté le paramètre noyau `transactional.id.expiration.ms` à 60 minutes. Si vous avez des exigences spécifiques, soumettez un ticket. Si l'utilisation du processeur d'une instance dépasse 85 %, cela peut affecter la stabilité du cluster et entraîner des problèmes tels que des temps d'arrêt ou des fluctuations de latence importantes lors de la production et de la consommation de messages. Les performances de Kafka dépendent du cluster. Si votre comportement de production ou l'attribution des partitions est déséquilibré, vous risquez de ne pas pouvoir utiliser pleinement la capacité du cluster. La fonctionnalité de messagerie transactionnelle open source présente de nombreux problèmes connus et non corrigés, tels que KAFKA-12671. Utilisez cette fonctionnalité avec prudence. Pour plus d'informations, consultez Problèmes KAFKA. Une duplication de messages peut se produire dans Kafka dans divers scénarios, par exemple lors d'un rééquilibrage. Pour prévenir tout impact commercial dû à la duplication des messages, mettez en œuvre une logique de consommation idempotente.			Non	Aucune