Le nombre de partitions ne peut qu'augmenter, jamais diminuer. Il s'agit d'une contrainte de conception inhérente à Apache Kafka et non d'une limitation spécifique à ApsaraMQ for Kafka.
Fonctionnement de l'affectation des partitions
Kafka affecte chaque message à une partition selon la formule hash(key) % number_of_partitions. Chaque partition conserve un journal de messages ordonné et indépendant. La suppression d'une partition entraîne deux problèmes majeurs :
Perte de données. Tous les messages stockés dans cette partition sont perdus.
Redistribution des clés. Le modulo changeant, la correspondance de hachage est modifiée pour toutes les clés. Les consommateurs qui dépendent d'un ordre basé sur les clés — par exemple, pour traiter tous les événements d'un utilisateur donné de manière séquentielle — reçoivent alors les messages dans le désordre ou les perdent entièrement.
Solutions alternatives
Planifiez le nombre de partitions dès le départ. Estimez ce nombre en fonction du débit cible et du parallélisme des consommateurs, puis arrondissez à la valeur supérieure. Bien qu'il soit possible d'ajouter des partitions ultérieurement, cela redistribue tout de même les affectations de clés ; il est donc recommandé de surdimensionner votre configuration initiale.
Recréez la rubrique si vous avez besoin de moins de partitions. Créez une nouvelle rubrique avec le nombre de partitions souhaité, migrez les producteurs et les consommateurs vers cette nouvelle rubrique, puis mettez hors service l'ancienne une fois que tous les messages ont été consommés ou ont expiré.
Limitations de haute disponibilité (HA) des rubriques à partition unique
En mode de stockage cloud, une rubrique dotée d'une seule partition (partitionNum=1) n'offre pas de haute disponibilité (HA). Si le nœud hébergeant cette partition devient indisponible, que ce soit en raison d'une panne ou d'une mise à niveau, la rubrique reste inaccessible jusqu'à ce que le nœud soit de nouveau en ligne.
La console Message Queue for Apache Kafka vous avertit lorsque vous tentez de créer une rubrique de stockage cloud avec une seule partition. Les rubriques de stockage cloud à partition unique ne sont pas recommandées.
Comportement des nouvelles tentatives avec les rubriques à partition unique
Le mécanisme de nouvelle tentative du producteur Kafka impacte les rubriques à partition unique de la manière suivante :
Lors des mises à niveau progressives — Lorsqu'un nœud est temporairement hors ligne pendant une mise à niveau planifiée, le mécanisme de nouvelle tentative permet d'atténuer l'impact de l'interruption. Les producteurs peuvent retenter la livraison des messages et reprendre l'envoi une fois le nœud rétabli. Cela réduit (sans toutefois l'éliminer) le risque de perte de messages durant la maintenance planifiée.
Lors de pannes de nœuds imprévues — Les nouvelles tentatives ne peuvent pas empêcher la perte de données en cas de panne inattendue d'un nœud. Si le nœud ne récupère pas dans le délai imparti aux nouvelles tentatives, les messages présents dans la file d'attente de retry risquent d'être perdus. Les politiques de nouvelle tentative ne sauraient se substituer à la haute disponibilité.
Afin de garantir la haute disponibilité pour vos charges de travail de production, configurez votre rubrique avec au moins deux partitions. Avec plusieurs partitions, Message Queue for Apache Kafka continue de servir les requêtes de lecture et d'écriture à partir des partitions répliques situées sur des nœuds sains, même si l'un des nœuds tombe en panne.
Quels sont les risques liés à la modification du nombre de partitions d'une rubrique interne Kafka ?
Kafka utilise des rubriques internes (telles que __consumer_offsets) pour la tenue de registres interne et la gestion des états. Bien que les clients Kafka puissent généralement détecter automatiquement les changements du nombre de partitions, la modification manuelle du nombre de partitions d'une rubrique interne (par exemple, en l'augmentant de 1 à 12) introduit des risques significatifs :
Problèmes d'ordre des messages — La modification du nombre de partitions altère le routage des messages vers les partitions. Des messages précédemment assignés à une partition donnée peuvent désormais correspondre à une autre partition, entraînant un traitement des messages dans le désordre.
Incohérence d'état — Les rubriques internes stockent des données d'état critiques, telles que les offsets des groupes de consommateurs. La modification de leur nombre de partitions peut corrompre ces données, provoquant des comportements inattendus chez les consommateurs, des échecs de rééquilibrage ou une instabilité du cluster.
Ne modifiez pas manuellement le nombre de partitions des rubriques internes. Si vous estimez qu'une modification est nécessaire, contactez le support technique Alibaba Cloud afin d'évaluer les risques avant toute intervention.