ApsaraMQ for Kafka:Terms

Apache Kafka

Plateforme distribuée et open source dédiée au traitement des flux de données en temps réel. Publiez, abonnez-vous, stockez et traitez des flux de données en temps réel. Pour plus d'informations, consultez Apache Kafka.

ApsaraMQ for Kafka

Service Apache Kafka entièrement managé proposé par Alibaba Cloud. ApsaraMQ for Kafka gère le déploiement et la maintenance tout en offrant une grande évolutivité, une haute fiabilité et un débit élevé à moindre coût. Pour plus d'informations, consultez Présentation d'ApsaraMQ for Kafka

Modèle publication-abonnement

Modèle de communication asynchrone découplant les producteurs des consommateurs. Un producteur envoie des messages vers un topic sans savoir quels consommateurs les liront. Un consommateur lit les messages d'un topic sans savoir quel producteur les a envoyés. ApsaraMQ for Kafka utilise ce modèle. Pour plus d'informations, consultez Modèle publication-abonnement d'ApsaraMQ Kafka.

Message

Unité de base des données dans ApsaraMQ for Kafka. Chaque message est représenté en interne sous forme de tableau d'octets. Les exemples courants incluent les vues de pages, les journaux serveur et les métriques des ressources système telles que l'utilisation du CPU et de la mémoire.

Durée de conservation des messages

Durée maximale de conservation des messages lorsque la capacité du disque est suffisante.

• Valeurs valides : 24 à 480 heures. Valeur par défaut : 72 heures.

• Lorsque l'utilisation du disque atteint 85 %, le système supprime d'abord les messages les plus anciens pour maintenir la disponibilité du service.

Taille maximale des messages

Taille maximale d'un seul message que les producteurs peuvent envoyer et que les consommateurs peuvent recevoir.

• Les instances Standard Edition et Professional Edition prennent en charge des messages jusqu'à 10 Mo.

• Avant de modifier cette valeur, assurez-vous qu'elle correspond à la taille maximale des messages configurée sur vos producteurs et consommateurs.

Broker

Nœud serveur au sein d'un cluster ApsaraMQ for Kafka. Le nombre de brokers et leurs configurations évoluent automatiquement en fonction des spécifications de trafic de votre instance. Aucune gestion manuelle des brokers n'est requise.

ZooKeeper

Service de coordination distribué et open source. Dans ApsaraMQ for Kafka, ZooKeeper gère les clusters, stocke les configurations et gère l'élection des leaders. ZooKeeper est un composant interne qui ne nécessite aucune interaction de la part de l'utilisateur.

Cluster

Ensemble de brokers travaillant conjointement pour stocker et servir les messages.

Instance

Entité de ressource indépendante dans ApsaraMQ for Kafka. Chaque instance correspond à un cluster.

Instance connectée via VPC

Instance qui expose uniquement un endpoint de réseau privé virtuel (VPC). Une instance connectée via VPC est accessible uniquement depuis le VPC dans lequel elle est déployée.

Instance connectée via Internet et VPC

Instance qui expose à la fois un endpoint public et un endpoint VPC. Ce type d'instance est accessible depuis le VPC dans lequel elle est déployée ainsi que via Internet.

Endpoint

Adresse utilisée par les producteurs et les consommateurs pour se connecter à ApsaraMQ for Kafka, selon l'un des formats suivants :

• <broker-ip>:<port> -- adresse IP et port au niveau du broker

• <instance-domain>:<port> -- nom de domaine et port au niveau de l'instance

Pour plus d'informations, consultez Comparaison des endpoints.

Topic

Topic de message utilisé pour classer les messages.

Partition

Sous-division d'un topic. Chaque partition constitue une file d'attente de messages ordonnée et lisible indépendamment. Les partitions servent deux objectifs :

• Parallélisme : plusieurs consommateurs peuvent lire différentes partitions simultanément.

• Évolutivité : le stockage des données et les opérations d'E/S sont répartis entre les brokers du cluster.

Le nombre de partitions détermine le débit maximal et la concurrence des consommateurs pour un topic.

Rééquilibrage du trafic des topics

Opération qui redistribue uniformément le trafic des topics après une montée en puissance (scale out) d'un cluster ApsaraMQ for Kafka. Exécutez un rééquilibrage pour vous assurer que les nouveaux brokers partagent la charge. Pour plus d'informations, consultez Rééquilibrer le trafic des topics.

Répliques

Copies de chaque partition offrant une redondance des données et une haute disponibilité. Chaque partition possède un nombre configurable de répliques, appelé facteur de réplication.

• Facteur de réplication par défaut : 3.

• Des facteurs de réplication plus élevés augmentent la tolérance aux pannes, mais également la consommation de stockage et la surcharge réseau.

Répliques de partition

Nombre total de répliques pour toutes les partitions d'un topic, calculé comme suit :

Répliques de partition = Nombre de partitions x Facteur de réplication

Par exemple, un topic comportant 10 partitions avec un facteur de réplication de 3 possède 30 répliques de partition. Un nombre plus élevé de répliques de partition améliore la tolérance aux pannes et les performances en lecture, mais augmente la surcharge réseau et de stockage.

Stockage cloud

Moteur de stockage construit sur des disques Alibaba Cloud. Par rapport au stockage local, le stockage cloud offre une meilleure Auto Scaling, une plus grande fiabilité, une meilleure disponibilité et un meilleur rapport qualité-prix. Utilisez le stockage cloud pour la plupart des charges de travail. Pour plus d'informations, consultez Comparaison des moteurs de stockage.

Stockage local

Moteur de stockage utilisant l'algorithme In-Sync Replicas (ISR) d'Apache Kafka natif. Utilisez le stockage local lorsque votre charge de travail nécessite une compaction, l'idempotence, des transactions ou des messages ordonnés par partition. Pour plus d'informations, consultez Comparaison des moteurs de stockage.

Politique de nettoyage

Politique de nettoyage des journaux pour un topic. Les politiques de nettoyage s'appliquent uniquement aux topics utilisant le stockage local sur les instances Professional Edition. ApsaraMQ for Kafka prend en charge deux politiques :

• Delete (par défaut) : conserve les messages jusqu'à la période de conservation configurée. Lorsque l'utilisation du disque dépasse 85 %, le système supprime d'abord les messages les plus anciens pour maintenir la disponibilité.

• Compact : conserve uniquement la dernière valeur pour chaque clé de message, conformément à la compaction des journaux Apache Kafka. Utilisez cette politique pour les scénarios de récupération d'état, tels que la restauration d'un système ou le rechargement d'un cache après un redémarrage. Kafka Connect et Confluent Schema Registry nécessitent des topics avec compaction des journaux.

Producteur

Application qui envoie des messages à ApsaraMQ for Kafka.

Consommateur

Application qui lit les messages depuis ApsaraMQ for Kafka.

Groupe

Ensemble de consommateurs partageant le même ID de groupe. Au sein d'un groupe de consommateurs, chaque message provenant d'un topic abonné est remis à exactement un consommateur. Cela permet :

• Équilibrage de charge : le traitement des messages est réparti entre les membres du groupe.

• Consommation parallèle : plusieurs consommateurs traitent les messages d'un topic simultanément.

Abonnement

Relation entre un groupe de consommateurs et les topics qu'il consomme. Seuls les groupes de consommateurs activement connectés peuvent être interrogés. Les groupes déconnectés ne sont pas visibles.

Offset

Numéro de séquence attribué à chaque message lors de son arrivée dans une partition. Les offsets identifient la position d'un message dans le journal de la partition et permettent de suivre la progression de la consommation.

Offset le plus ancien

Offset du premier message disponible dans une partition. Pour plus d'informations, consultez Afficher l'état de la partition.

Offset maximal

Offset du message le plus récent dans une partition. Pour plus d'informations, consultez Afficher l'état de la partition.

Offset du consommateur

Offset du dernier message qu'un groupe de consommateurs a consommé dans une partition. Cette valeur permet de suivre la progression de la consommation du groupe. Pour plus d'informations, consultez Afficher les informations sur les consommateurs.

Messages accumulés

Nombre de messages non consommés dans une partition, calculé comme suit :

Messages accumulés = Offset maximal - Offset du consommateur

Une augmentation de ce nombre indique que les consommateurs prennent du retard, soit parce qu'ils sont bloqués, soit parce qu'ils consomment plus lentement que les producteurs n'envoient. Pour résoudre l'accumulation, analysez l'état des consommateurs et augmentez la capacité de consommation. Vous pouvez effacer tous les messages accumulés pour consommer à partir du dernier offset, ou réinitialiser l'offset du consommateur à un moment précis. Pour plus d'informations, consultez Réinitialiser les offsets des consommateurs.

Heure de la dernière consommation

Moment où le message consommé le plus récemment a été publié initialement sur le broker. Lorsqu'il n'y a pas de messages accumulés, cette valeur est proche de l'heure d'envoi actuelle.

Message normal

Type de message par défaut. Les messages ayant la même clé sont stockés dans la même partition dans l'ordre d'envoi. Toutefois, en cas de redémarrage ou de panne d'un broker, un petit nombre de messages peut être livré dans le désordre. Pour plus d'informations, consultez Comparaison des moteurs de stockage.

Message ordonné par partition

Type de message garantissant un ordre strict au sein d'une partition. Les messages ayant la même clé sont stockés dans la même partition dans l'ordre d'envoi, et cet ordre est maintenu même en cas de panne des brokers. La contrepartie : les partitions affectées cessent d'accepter les écritures jusqu'à ce que les brokers défaillants soient restaurés. Pour plus d'informations, consultez Comparaison des moteurs de stockage.

Mise à niveau majeure

Mise à niveau qui modifie le numéro de version majeur d'une instance ApsaraMQ for Kafka. Par exemple, passer de la version 0.10.x à la version 2.x. Pour plus d'informations, consultez Mettre à niveau les versions des instances.

Mise à jour mineure

Mise à jour qui conserve le numéro de version majeur inchangé. Par exemple, passer de la version 0.10 à la version 0.10.2, ou de la version 0.10.2 à la version optimisée pour le noyau 0.10.2. Pour plus d'informations, consultez Mettre à niveau les versions des instances.

RAM

Resource Access Management (RAM) est un service Alibaba Cloud permettant de gérer les identités utilisateur et les autorisations d'accès aux ressources. Utilisez RAM pour contrôler qui peut accéder aux ressources ApsaraMQ for Kafka via la console ou les opérations API. Pour plus d'informations, consultez Présentation.

ACL

Les listes de contrôle d'accès (ACL) gèrent les autorisations des utilisateurs et clients Simple Authentication and Security Layer (SASL) pour envoyer et recevoir des messages via des SDK. Les ACL s'appliquent spécifiquement aux scénarios dans lesquels vous souhaitez mettre en œuvre un contrôle d'accès pour les utilisateurs qui utilisent des SDK pour envoyer et recevoir des messages. Cette fonctionnalité est cohérente avec les ACL Apache Kafka open source. Pour plus d'informations, consultez Présentation.

Connecteur

Composant qui synchronise les données entre ApsaraMQ for Kafka et d'autres services Alibaba Cloud. Pour plus d'informations, consultez Présentation.

Tag

Paire clé-valeur associée à une ressource ApsaraMQ for Kafka. Utilisez les tags pour classer, rechercher et regrouper les ressources selon des critères personnalisés. Pour plus d'informations, consultez Gérer les tags.