Kafka est un excellent middleware de messages distribués. Kafka est utilisé dans de nombreux systèmes pour la communication de messages. Comprendre et utiliser les systèmes de messagerie distribués est presque devenu une compétence nécessaire pour un développeur backend. Aujourd'hui 码哥字节
Je vais commencer par les questions courantes d'entretien avec Kafka et vous parler de Kafka.
La messagerie distribuée est un mécanisme de communication contrairement à RPC, HTTP, RMI, etc., le middleware de messages utilise un agent intermédiaire distribué pour communiquer. Comme le montre la figure, après avoir utilisé le middleware de messages, le système métier en amont envoie des messages, qui sont d'abord stockés dans le middleware de messages, puis le middleware de messages distribue les messages aux applications du module métier correspondant (modèle producteur-consommateur distribué). Cette approche asynchrone réduit le couplage entre les services.
Définir le middleware de message :
Faire référence à des composants supplémentaires dans l'architecture du système augmentera inévitablement la complexité architecturale du système et la difficulté d'exploitation et de maintenance Alors Quels sont les avantages de l'utilisation d'un middleware de messagerie distribuée dans le système ? Quel est le rôle du middleware de messages dans le système ?
Lors des entretiens, les enquêteurs se soucient souvent de la capacité de l'intervieweur à sélectionner des composants open source. Cela peut non seulement tester l'étendue des connaissances de l'intervieweur, mais également la profondeur de ses connaissances sur un certain type de système, et cela peut également être vu. que l'intervieweur a la capacité de comprendre la conception globale du système et de l'architecture du système. Il existe de nombreux systèmes de messagerie distribués open source, et différents systèmes de messagerie ont des caractéristiques différentes. Le choix d'un système de messagerie nécessite non seulement une certaine compréhension de chaque système de messagerie, mais également une compréhension claire de vos propres exigences système.
Ce qui suit est une comparaison de plusieurs systèmes de messagerie distribués courants :
Concepts généraux dans l'architecture Kafka :
Disposition des partitions du sujet Kafka
Sujet des partitions Kafka, et les partitions peuvent être lues et écrites simultanément.
Compensation du consommateur Kafka
Parlez brièvement de l'architecture de Kafka ?
Producteur, Consommateur, Groupe de consommateurs, Sujet, Partition
Le mode push ou le mode pull de Kafka est-il différent ?
Kafka Producer utilise le mode Push pour envoyer des messages au courtier, et Consumer utilise le mode Pull pour la consommation. Le mode pull permet au consommateur de gérer lui-même le décalage, ce qui peut offrir des performances de lecture
Comment Kafka diffuse-t-il les messages ?
Groupe de consommateurs
Les messages de Kafka sont-ils de mise ?
Les niveaux de sujet ne sont pas ordonnés et les partitions sont ordonnées
Kafka prend-il en charge la séparation lecture-écriture ?
Non pris en charge, seul Leader fournit des services externes de lecture et d'écriture
Comment Kafka garantit-il une haute disponibilité des données ?
Copie, ack, HW
Le rôle du gardien de zoo dans Kafka ?
Gestion de cluster, gestion des métadonnées
Prend-il en charge les transactions ?
Après la version 0.11, les transactions sont prises en charge et peuvent être réalisées "exactement une fois"
Le nombre de partitions peut-il être réduit ?
Non, les données seront perdues
L'outil de ligne de commande de Kafka se trouve dans le répertoire /bin
du package Kafka, qui comprend principalement des scripts de gestion de services et de clusters, des scripts de configuration, des scripts de visualisation d'informations, des scripts de sujet, des scripts clients, etc. .
Nous pouvons généralement utiliser kafka-console-consumer.sh
和kafka-console-producer.sh
脚本来测试 Kafka 生产和消费,kafka-consumer-groups.sh
可以查看和管理集群中的 Topic,kafka-topics.sh
habituellement utilisé pour afficher le statut du groupe de consommateurs de Kafka.
La logique de production normale du producteur Kafka comprend les étapes suivantes :
Le processus d'envoi des messages par le producteur est illustré dans la figure ci-dessous, qui doit être envoyé au courtier par lots. 拦截器
,序列化器
和分区器
,最终由累加器
Valeur par défaut : 200, le nombre de messages dans chaque lot, ne fonctionne que pour asyc.
Valeur par défaut : 0, 0 signifie que le producteur n'a pas besoin d'attendre la confirmation du leader, 1 signifie que le leader doit confirmer l'écriture dans son journal local et le confirmer immédiatement, -1 signifie que le producteur doit confirmer une fois toutes les sauvegardes terminées. Il ne fonctionne qu'en mode asynchrone. L'ajustement de ce paramètre est un compromis entre la perte de données et l'efficacité de la transmission. Si vous n'êtes pas sensible à la perte de données mais que vous vous souciez de l'efficacité, vous pouvez envisager de le définir sur 0, ce qui peut grandement améliorer l'efficacité de la transmission. le producteur dans l'envoi des données.
request.timeout.ms
Valeur par défaut : 10000, délai d'attente de confirmation.
partitioner.class
Valeur par défaut : kafka.producer.DefaultPartitioner, doit implémenter kafka.producer.Partitioner, fournir une stratégie de partitionnement basée sur la clé. Parfois, nous avons besoin que le même type de messages soit traité séquentiellement, nous devons donc personnaliser la stratégie d'allocation pour allouer le même type de données à la même partition.
producer.type
Valeur par défaut : sync, précise si le message est envoyé de manière synchrone ou asynchrone. Utilisez kafka.producer.AyncProducer pour l'envoi par lots asynchrone et kafka.producer.SyncProducer pour la synchronisation synchrone. L'envoi synchrone et asynchrone affecte également l'efficacité de la production de messages.
compression.topic
Valeur par défaut : aucune, compression du message, aucune compression par défaut. D'autres méthodes de compression incluent "gzip", "snappy" et "lz4". La compression des messages peut réduire considérablement le volume de transmission du réseau et les E/S du réseau, améliorant ainsi les performances globales.
compressé.topics
Valeur par défaut : null. Lorsque la compression est définie, vous pouvez spécifier une compression de sujet spécifique. Si elle n'est pas spécifiée, toute la compression sera effectuée.
message.send.max.retries
Valeur par défaut : 3, le nombre maximum de tentatives d'envoi de messages.
retry.backoff.ms
Valeur par défaut : 300, intervalle supplémentaire ajouté à chaque essai.
topic.metadata.refresh.interval.ms
Valeur par défaut : 600000, le temps d'obtenir régulièrement les métadonnées. Lorsque la partition est perdue et que le leader est indisponible, le producteur obtiendra également activement les métadonnées. S'il vaut 0, les métadonnées seront obtenues à chaque envoi du message, ce qui n'est pas recommandé. Si elles sont négatives, les métadonnées ne sont récupérées qu’en cas d’échec.
queue.buffering.max.ms
Valeur par défaut : 5000, la durée maximale de mise en cache des données dans la file d'attente du producteur, uniquement pour asyc.
queue.buffering.max.message
Valeur par défaut : 10000, le nombre maximum de messages mis en cache par le producteur, uniquement pour asyc.
queue.enqueue.timeout.ms
Valeur par défaut : -1, 0 est supprimé lorsque la file d'attente est pleine, la valeur négative est le bloc lorsque la file d'attente est pleine, la valeur positive est le temps correspondant du bloc lorsque la file d'attente est pleine, uniquement pour asyc.
Kafka a le concept de groupes de consommateurs. Chaque consommateur ne peut consommer que les messages de la partition attribuée, et chaque partition ne peut être consommée que par un seul consommateur dans un groupe de consommateurs consommé. Ainsi, si le nombre de consommateurs dans le même groupe de consommateurs dépasse le nombre de partitions, certains consommateurs se verront attribuer des partitions qui ne pourront pas être consommées. La relation entre les groupes de consommateurs et les consommateurs est illustrée dans la figure ci-dessous :
Kafka Consumer Client consommant des messages comprend généralement les étapes suivantes :
Parce que le client Consumer de Kafka est thread-safe dans, afin d'assurer le fil sécurité et amélioration Pour les performances de consommation, un modèle de thread similaire à Reactor peut être utilisé du côté consommateur pour consommer des données.
"Modèle de consommation" ;rayon de bordure : 4 px ;marge droite : 2 px ;marge gauche : 2 px ;couleur d'arrière-plan : rgba(27, 31, 35, 0,05) ;famille de polices : « Operator Mono », Consolas, Monaco, Menlo, monospace ;word-break: break-all;color: rgb(0, 150, 136);">hôte:port format.key.serializer
correspond à la méthode de désérialisation de key.
value.serializer
correspond à la méthode de désérialisation de valeur. host:port
格式。key.serializer
对应,key 的反序列化方式。value.serializer
对应,value 的反序列化方式。false
,则需要在程序中手动提交位移。对于精确到一次的语义,最好手动提交位移max.poll.records
false
, vous devez soumettre le déplacement manuellement dans le programme. Pour une sémantique exactement une fois, il est préférable de soumettre le déplacement manuellement 🎜🎜🎜🎜fetch.max.bytes : Le nombre maximum d'octets de données extraites en une seule fois 🎜🎜🎜🎜max.poll.records : Le nombre maximum de messages renvoyés par un seul appel d'interrogation. Si la logique de traitement est très légère, cette valeur peut être augmentée de manière appropriée. Mais max.poll. les données des enregistrements
doivent être traitées dans session.timeout.ms. La valeur par défaut est 500🎜🎜🎜🎜request.timeout.ms : le temps d'attente maximum pour une réponse à une requête. Si aucune réponse n'est reçue dans le délai d'expiration, Kafka renverra le message ou échouera directement si le nombre de tentatives est dépassé.rebalance est essentiellement un protocole qui stipule comment tous les consommateurs d'un groupe de consommateurs peuvent parvenir à un accord pour attribuer chaque partition du sujet d'abonnement. Par exemple, il y a 20 consommateurs dans un certain groupe et celui-ci s'abonne à un sujet comportant 100 partitions. Dans des circonstances normales, Kafka alloue en moyenne 5 partitions à chaque consommateur. Ce processus d'allocation est appelé rééquilibrage.
Quand rééquilibrer ?
C'est aussi une question qui est souvent évoquée. Il existe trois conditions de déclenchement pour le rééquilibrage :
Comment allouer les partitions au sein du groupe ?
Kafka propose deux stratégies d'allocation par défaut : Range et Round-Robin. Bien entendu, Kafka adopte une stratégie d'allocation enfichable et vous pouvez créer votre propre allocateur pour mettre en œuvre différentes stratégies d'allocation.
/bin
Répertoire, gérer le cluster kafka, gérer le sujet, produire et consommer du kafkaDans les systèmes de données distribués, les partitions sont généralement utilisées pour améliorer la capacité de traitement du système et assurer la haute disponibilité des données via des répliques. Le partitionnement multiple signifie la possibilité de traiter simultanément parmi ces multiples copies, une seule est la copie leader et les autres sont les copies suiveuses. Seule la copie leader peut fournir des services au monde extérieur. Plusieurs copies suiveuses sont généralement stockées dans des courtiers différents de la copie leader. Grâce à ce mécanisme, une haute disponibilité est atteinte. Lorsqu'une machine raccroche, les autres copies suiveuses peuvent rapidement « revenir à la normale » et commencer à fournir des services au monde extérieur.
Pourquoi la copie suiveuse ne fournit-elle pas de service de lecture ?
Ce problème est essentiellement un compromis entre performances et cohérence. Imaginez, que se passerait-il si la copie suiveuse fournissait également des services au monde extérieur ? Tout d’abord, les performances seront définitivement améliorées. Mais en même temps, toute une série de problèmes vont surgir. Semblable à la lecture fantôme et à la lecture sale dans les transactions de base de données. Par exemple, si vous écrivez une donnée dans le sujet Kafka a, le consommateur b consomme les données du sujet a, mais constate qu'il ne peut pas les consommer car le dernier message n'a pas été écrit sur la copie de partition lue par le consommateur b. À ce moment-là, un autre consommateur c peut consommer les dernières données car il consomme la copie principale. Kafka utilise la gestion de WH et Offset pour déterminer quelles données le consommateur peut consommer et les données actuellement écrites.
Seul le leader peut fournir des services de lecture externes, donc comment élire le leader
kafka placera les répliques synchronisées avec la réplique leader dans le jeu de répliques ISR. Bien entendu, la copie leader existe toujours dans l'ensemble de copies ISR. Dans certains cas particuliers, il n'y a même qu'une seule copie du leader dans la copie ISR. Lorsque le leader échoue, Kakfa détecte cette situation par l'intermédiaire du gardien de zoo, sélectionne une nouvelle copie dans la copie ISR pour devenir le leader et fournit des services au monde extérieur. Mais cela pose un autre problème : comme mentionné précédemment, il est possible qu'il n'y ait que le leader dans le jeu de répliques ISR. Lorsque la réplique leader meurt, l'ensemble ISR sera vide. À ce stade, si le paramètre unclean.leader.election.enable est défini sur true, Kafka sélectionnera une réplique pour devenir le leader en mode asynchrone, c'est-à-dire une réplique qui ne fait pas partie du jeu de répliques ISR.
L'existence d'une copie entraînera des problèmes de synchronisation de copie
Kafka maintient une liste de répliques disponibles (ISR) dans toutes les répliques allouées (AR) Lorsque le producteur envoie un message au courtier, il gérera la synchronisation des données entre la fleur et le leader en fonction du service ack
配置来确定需要等待几个副本已经同步了消息才相应成功,Broker 内部会ReplicaManager
.
Comment Kafka assure-t-il la haute disponibilité ?
Assurer la haute disponibilité des données via des répliques, un accusé de réception du producteur, une nouvelle tentative, l'élection automatique du leader, l'auto-équilibrage du consommateur
La sémantique de livraison de Kafka ?
La sémantique de livraison a généralement
at least once
、at most once
和exactly once
. Kafka implémente les deux premiers via la configuration ack.
Que fait Replica ?
Atteindre une haute disponibilité des données
Que sont l'AR et l'ISR ?
AR : répliques attribuées. AR est l'ensemble de réplicas alloués lors de la création de la partition après la création du sujet. Le nombre de réplicas est déterminé par le facteur de réplication. ISR : réplicas synchronisés. Un concept particulièrement important dans Kafka fait référence à l'ensemble des répliques en AR qui sont synchronisées avec le Leader. La réplique dans l'AR peut ne pas être dans l'ISR, mais la réplique Leader est naturellement incluse dans l'ISR. Concernant l'ISR, une autre question courante lors d'un entretien est de savoir comment déterminer si une copie doit appartenir à un ISR. Le jugement actuel est basé sur la question de savoir si le temps pendant lequel le LEO du réplica suiveur est en retard par rapport au LEO du leader dépasse la valeur du paramètre côté courtier replique.lag.time.max.ms. En cas de dépassement, la réplique est supprimée de l'ISR.
Que sont Leader et Fleur ?
Que signifie HW dans Kafka ?
Filigrane élevée. Il s'agit d'un champ important qui contrôle la portée du message que le consommateur peut lire. Un consommateur ordinaire ne peut « voir » que tous les messages sur la réplique Leader entre Log Start Offset et HW (exclusif). Les messages au-dessus du niveau de l’eau sont invisibles pour les consommateurs.
Quel traitement Kafka a-t-il effectué pour garantir des performances supérieures ?
Concurrence de partition, lecture et écriture séquentielles sur le disque, compression du cache de pages, sérialisation hautes performances (binaire), gestion des décalages sans verrouillage du mappage mémoire, modèle Java NIO
Cet article n'entre pas dans l'implémentation Les détails et l'analyse du code source de Kafka, mais Kafka est en effet un excellent système open source. De nombreuses conceptions architecturales et conceptions de code source élégantes méritent d'être apprises. Il est fortement recommandé aux étudiants intéressés d'avoir une compréhension plus approfondie de ce système open source. les capacités de conception architecturale, les capacités de codage et l’optimisation des performances seront d’une grande aide.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!