La première leçon de combat rapide kafka-Kafka et explication détaillée des principes de base

1. Présentation de Kafka

• Kafka est un système de messagerie de publication-abonnement distribué qui peut traiter rapidement des flux de données à haut débit et distribuer des données à plusieurs consommateurs en temps réel. Le système de messagerie Kafka se compose de plusieurs courtiers (serveurs), qui peuvent être répartis sur plusieurs centres de données pour fournir une haute disponibilité et une tolérance aux pannes.
• L'architecture de base de Kafka se compose de producteurs, de consommateurs et de sujets. Les producteurs peuvent publier des données dans des rubriques spécifiées, et les consommateurs peuvent s'abonner à ces rubriques et en consommer les données. Dans le même temps, Kafka prend également en charge le traitement et la conversion des flux de données, et le calcul de flux peut être effectué via l'API Kafka Streams dans le pipeline, comme le filtrage, la conversion, l'agrégation, etc.
• Kafka utilise des techniques efficaces de stockage et de gestion des données qui peuvent facilement gérer des volumes de données de plusieurs To. Ses avantages incluent un débit élevé, une faible latence, l'évolutivité, la persistance et la tolérance aux pannes, entre autres.
• Kafka est largement utilisé dans les applications d'entreprise, notamment le traitement de flux en temps réel, l'agrégation de journaux, la surveillance et l'analyse de données. Dans le même temps, Kafka peut également être intégré à d'autres outils de Big Data, tels que Hadoop, Spark et Storm, pour créer un écosystème complet de traitement des données.

1. Le rôle du MQ

MQ : MessageQueue, file d'attente de messages. La file d'attente est une structure de données premier entré premier sorti FIFO. Les messages sont des données transmises à travers les processus. Un système MQ typique enverra les messages des producteurs à MQ pour les mettre en file d'attente, puis les remettra aux consommateurs de messages dans un certain ordre pour traitement.
Le rôle de MQ comporte principalement les trois aspects suivants :

Écrêtage de découplage asynchrone

2. Pourquoi utiliser Kafka

Un scénario d'application typique d'agrégation de journaux :

Le scénario commercial détermine les caractéristiques du produit.

1. Le débit de données est très important : il est nécessaire de collecter rapidement des journaux massifs à partir de différents canaux

2. Tolérance élevée aux pannes du cluster : permet à un petit nombre de nœuds du cluster de tomber en panne

3. La fonction n'a pas besoin d'être trop compliquée : Kafka est conçu avec un débit élevé, une faible latence et une évolutivité, en se concentrant sur la livraison des messages plutôt que sur le traitement des messages. Par conséquent, Kafka ne prend pas en charge les fonctions avancées telles que les files d'attente de lettres mortes et les messages séquentiels.

4. Une petite quantité de données est autorisée : Kafka lui-même optimise constamment les problèmes de sécurité des données. À l'heure actuelle, on peut fondamentalement considérer que Kafka ne peut pas perdre de données.

2. Compétence rapide de Kafka

1. Environnement expérimental

Préparation de trois machines virtuelles 192.168.85.200~202, prêtes à construire un cluster de trois machines.

Les trois machines sont préinstallées avec le système d'exploitation CentOS7. Configurez respectivement les noms de machine master, node1, node2.

vi /etc/hosts

Ensuite, vous devez désactiver le pare-feu (il est recommandé de le désactiver dans l'environnement expérimental).

firewall-cmd --state   查看防火墙状态
systemctl stop firewalld.service   关闭防火墙

Ensuite, JAVA doit être installé sur les trois machines.

​ Téléchargez kafka et sélectionnez la dernière version 3.2.0. Adresse de téléchargement : https://kafka.apache.org/downloads Sélectionnez kafka_2.13-3.4.0.tgz pour télécharger.

Concernant la version de Kafka, la précédente 2.13 est la version du langage Scala utilisée pour développer Kafka, et la dernière 3.4.0 est la version de l'application Kafka.
Scala est un langage qui s'exécute sur la machine virtuelle JVM. Au moment de l'exécution, il vous suffit d'installer le JDK, et la version de Scala que vous choisissez ne fait aucune différence. Mais si vous souhaitez déboguer le code source, vous devez sélectionner la version Scala correspondante. Parce que la version du langage Scala n'est pas rétrocompatible.

Télécharger Zookeeper, l'adresse de téléchargement est https://zookeeper.apache.org/releases.html, la version de Zookeeper n'est pas obligatoire, ici on choisit la nouvelle version 3.6.1.

Le programme d'installation de kafka est fourni avec Zookeeper et vous pouvez afficher le package jar du client zookeeper dans le répertoire libs du package d'installation de kafka. Cependant, dans des circonstances normales, afin de faciliter la maintenance de l'application, nous utiliserons Zookeeper déployé séparément au lieu du Zookeeper fourni avec Kafka.

Une fois le téléchargement terminé, téléchargez les deux kits d'outils sur les trois serveurs, décompressez-les et placez-les respectivement dans les répertoires /app/kafka et /app/zookeeper. Et configurez le chemin du répertoire bin sous le répertoire de déploiement vers la variable d'environnement path.

2. Expérience de service autonome

Le package d'installation de Kafka téléchargé ne nécessite aucune configuration, vous pouvez directement cliquer pour l'exécuter. C'est généralement la première étape pour apprendre rapidement à connaître Kafka.

1. Zookeeper doit être démarré avant de démarrer Kafka. ** Le Zookeeper fourni avec Kafka est utilisé ici. Le script de démarrage se trouve dans le répertoire bin.

#解压
tar -zxvf kafka_2.13-3.4.0.tgz
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test  

Vous pouvez voir sur nohup.out que zookeeper démarrera par défaut sur le port 2181. Consultez un processus QuorumPeerMain via la commande jps pour confirmer que le service a démarré avec succès.

2. Commencer Kafka

nohup bin/kafka-server-start.sh config/server.properties &

Une fois le démarrage terminé, utilisez la commande jps pour afficher un processus kafka afin de confirmer que le service a démarré avec succès. Le service démarrera sur le port 9092 par défaut.

3. Le mécanisme de fonctionnement de base
   de Kafka est que l'expéditeur du message peut envoyer le message au sujet spécifié sur Kafka, et le consommateur du message peut consommer le message du sujet spécifié.
   

Tout d'abord, vous pouvez utiliser le script client fourni par Kafka pour créer un sujet

#创建Topic
bin/kafka-topics.sh --create --topic test --bootstrap-server localhost:9092
#查看Topic
bin/kafka-topics.sh --describe --topic test --bootstrap-server localhost:9092

Ensuite, démarrez un message côté expéditeur. Envoyez un message à un sujet nommé test.

bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

Une fois que le symbole > apparaît sur la ligne de commande, entrez quelques caractères à volonté. Ctrl+C Quitte la ligne de commande. Ceci termine l'opération d'envoi de messages à Kafka.

Démarrez ensuite un consommateur de messages pour recevoir les messages de la rubrique nommée test.

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test

Ceci complète une interaction de base. Parmi eux, les producteurs et les consommateurs n'ont pas besoin de démarrer en même temps. Des données peuvent être échangées entre eux, mais ils ne dépendent pas les uns des autres. Sans producteurs, les consommateurs peuvent encore travailler normalement, et inversement, sans consommateurs, les producteurs peuvent encore travailler normalement. Cela reflète également le découplage entre producteurs et consommateurs.

4. Autres modes de consommation

Auparavant, nous avons démarré un simple producteur de messages et un consommateur de messages via les scripts de producteur et de consommateur fournis par kafka.En fait, kafka fournit également une multitude de méthodes de consommation de messages.
Spécifier la progression de la consommation
Le consommateur de console démarré par kafka-console.consumer.sh affichera le contenu obtenu sur la ligne de commande. Si vous souhaitez consommer le message envoyé auparavant, vous pouvez le spécifier en ajoutant le paramètre --from-begining.

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic test

Si vous avez besoin d'une consommation plus précise des messages, vous pouvez même spécifier à partir de quel message commencer à consommer.

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --partition 0 --offset 4 --topic test

Cela signifie lire à partir du quatrième message sur la partition n° 0. Que sont la partition et le décalage, vous pouvez utiliser la commande suivante pour afficher.

Consommation de groupe
Pour chaque consommateur, un groupe de consommateurs peut être spécifié. Le même message dans Kafka ne peut être consommé que par un certain consommateur appartenant au même groupe de consommateurs. D'autres consommateurs qui n'appartiennent pas au même groupe de consommateurs peuvent également consommer ce message.
Dans le script kafka-console-consumer.sh, le groupe de consommateurs auquel il appartient peut être spécifié via –consumer-property group.id=testGroup. Par exemple, trois groupes de consommateurs peuvent être démarrés pour vérifier le mécanisme de consommation de groupe :

#Deux instances de consommateur appartiennent au même groupe de consommateurs
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --consumer-property group.id=testGrroup --topic test
bin/kafka-console-consumer .sh --bootstrap-server localhost:9092
--consumer-property group.id=testGrroup --topic test
#Cette instance de consommateur appartient à un autre groupe de consommateurs bin/kafka-console-consumer.sh --bootstrap-server localhost: 9092 - -consumer-property group.id=testGrroup2 --test de sujet

Afficher le décalage du groupe de consommateurs

Ensuite, vous pouvez également utiliser kafka-consumer-groups.sh pour observer la situation des groupes de consommateurs. Notamment leur progression de consommation.

查看消费者组的偏移量
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group testGroup

3. Comprendre le mécanisme de messagerie de Kakfa

D'après les expériences précédentes, nous pouvons voir que l'expéditeur et le consommateur de messages de Kafka communiquent entre eux via un concept logique tel que Topic. Mais en fait, tous les messages sont stockés dans une structure de données telle que Partition côté serveur

Dans le système technique de Kafka, les concepts suivants doivent être familiarisés avec :

• Client Client : Y compris les producteurs de messages et les consommateurs de messages.
• Groupe de consommateurs : chaque consommateur peut spécifier un groupe de consommateurs auquel il appartient, et les consommateurs du même groupe de consommateurs forment ensemble un groupe de consommateurs logique. Chaque message sera consommé par plusieurs groupes de consommateurs intéressés, mais au sein de chaque groupe de consommateurs, un message ne sera consommé qu'une seule fois.
• Server Broker : Un serveur Kafka est un Broker.
• Topic : Il s'agit d'un concept logique, un Topic est considéré comme un groupe de messages ayant la même signification métier. Les clients produisent ou consomment des sujets qui les intéressent en liant Topic.
• Partition Partition : Le sujet n'est qu'un concept logique et la partition est le composant qui stocke réellement les messages. Chaque partition est une structure de file d'attente. Tous les messages sont stockés dans ces partitions de partition dans l'ordre FIFO premier entré, premier sorti.

4. Service de cluster Kafka

Pourquoi utiliser un cluster ?
En service autonome, Kafka a déjà des performances très élevées. TPS peut atteindre le niveau du million. Cependant, lorsqu'il est utilisé dans un travail réel, Kafka construit sur une seule machine aura de grandes limitations.
​ D'une part : trop de messages doivent être enregistrés séparément. Kafka est conçu pour les messages massifs. Il y aura beaucoup de messages sous un sujet, et il est difficile pour les services autonomes de survivre. Ces messages doivent être divisés en différentes partitions et distribués à plusieurs courtiers différents. De cette manière, chaque Broker n'a besoin de sauvegarder qu'une partie des données. Le nombre de ces partitions est appelé le nombre de partitions.
D'autre part : le service est instable et les données se perdent facilement. Sous un service autonome, si le service tombe en panne, les données seront perdues. Afin d'assurer la sécurité des données, il est nécessaire de configurer une ou plusieurs sauvegardes pour chaque partition afin de s'assurer que les données ne sont pas perdues. En mode cluster de Kafka, chaque partition possède une ou plusieurs sauvegardes. Kafka utilisera un cluster Zookeeper unifié comme centre d'élection pour élire un chef de nœud maître pour chaque partition, et les autres nœuds sont des suiveurs de nœud esclave. Le nœud maître est chargé de répondre aux demandes commerciales spécifiques des clients et d'enregistrer les messages. Le nœud esclave est responsable de la synchronisation des données du nœud maître. Lorsque le nœud maître tombe en panne, Kafka élit un nœud esclave pour devenir le nouveau nœud maître.
​ Enfin : les informations du courtier dans le cluster Kafka, y compris les informations sur l'élection de la partition, seront stockées dans le cluster Zookeeper déployé en plus, afin que le cluster Kafka ne soit pas interrompu en raison du plantage de certains services du courtier.

L'architecture de cluster de Kafka ressemble à peu près à ceci :

Tout d'abord, déployez un cluster Kafka basé sur Zookeeper. Parmi eux, dans la partie centre électoral, Zookeeper est un mécanisme électoral à consensus majoritaire, qui permet à un petit nombre de nœuds du cluster de tomber en panne. Par conséquent, lors de la création d'un cluster, des nœuds impairs tels que 3, 5 et 7 sont généralement utilisés pour optimiser la haute disponibilité du cluster. Dans les expériences ultérieures, nous déploierons Zookeeper et Kafka sur les trois serveurs.
1. Déployer le cluster Zookeeper
Ici, le Zookeeper précédemment téléchargé est utilisé pour déployer le cluster. Zookeeper est un mécanisme d'élection par consensus majoritaire qui permet à une minorité de nœuds du cluster d'échouer. Par conséquent, lors de la construction d'un cluster, un nombre impair de nœuds est généralement utilisé pour maximiser la haute disponibilité du cluster. Dans le processus de mise en œuvre ultérieur, nous déploierons Zookeeper sur les trois serveurs.
Ici, le Zookeeper précédemment téléchargé est utilisé pour déployer le cluster. Zookeeper est un mécanisme d'élection par consensus majoritaire qui permet à une minorité de nœuds du cluster d'échouer. Par conséquent, lors de la construction d'un cluster, un nombre impair de nœuds est généralement utilisé pour maximiser la haute disponibilité du cluster. Dans le processus de mise en œuvre ultérieur, nous déploierons Zookeeper sur les trois serveurs.
Entrez ensuite dans le répertoire conf et modifiez le fichier de configuration. Dans le répertoire conf, un fichier zoo_sample.cfg est fourni, qui est un exemple de fichier. Nous n'avons qu'à copier ce fichier dans zoo.cfg (cp zoo_sample.cfg zoo.cfg) et y modifier la configuration de la clé. Parmi eux, les principaux paramètres de modification sont les suivants :

Répertoire de données local de #Zookeeper, la valeur par défaut est /tmp/zookeeper. Ceci est le répertoire temporaire de Linux et sera supprimé à tout moment.
dataDir=/app/zookeeper/data #
Port de service de Zookeeper
clientPort=2181
#Configuration du nœud du cluster
server.1=192.168.85.200:2888:3888
server.2=192.168.85.201:2888:3888
server.3=192.168.85.202 : 2888 :3888

Parmi eux, clientPort 2181 est un port de service ouvert aux clients. Et créez myid dans /app/zookeeper/data, correspondant au serveur de zookeeper.*

Dans la partie configuration du cluster, le x dans server.x est le myid du nœud dans le cluster. Ce dernier port 2888 est le port utilisé pour la transmission de données au sein du cluster. 3888 est le port utilisé pour l'élection au sein du cluster.

Ensuite, distribuez l'intégralité du répertoire de l'application Zookeeper aux deux autres machines. Vous pouvez démarrer le service Zookeeper sur les trois machines.

bin/zkServer.sh --config conf start

Vérifiez le statut, le zoopper du serveur node2 est le chef de groupe

bin/zkServer.sh status

2. Déployer le cluster Kafka
Le service Kafka n'a pas besoin d'être élu, il n'y a donc aucune suggestion pour un nombre impair de services.

La manière de déployer Kafka est similaire à celle de déployer Zookeeper, qui consiste à décompresser, configurer et démarrer des services.

​ Décompressez d'abord Kafka dans le répertoire /app/kafka.

Entrez ensuite dans le répertoire de configuration et modifiez server.properties. Il y a beaucoup d'éléments de configuration dans ce fichier de configuration, et quelques configurations sur lesquelles il convient de se concentrer sont répertoriées ci-dessous.

Le numéro globalement unique de #broker ne peut pas être répété, il ne peut s'agir que d'un nombre.
broker.id=0
#Adresse du fichier de données. La même valeur par défaut est donnée au répertoire /tmp.
log.dirs=/app/kafka/logs
#Le nombre par défaut de partitions pour chaque sujet
num.partitions=1
#adresse du service zookeeper
zookeeper.connect=master:2181,node1:2181,node2:2181

Le broker.id doit être différent sur chaque serveur. Lors de la distribution sur d'autres serveurs, veillez à le modifier.

Plusieurs services Kafka enregistrés sur des nœuds du même cluster zookeeper formeront automatiquement un cluster.

Les commentaires dans le fichier de configuration sont très détaillés, vous pouvez y prêter attention. Voici les configurations de base les plus importantes dans le fichier server.properties

commencer l'essai

bin/kafka-server-start.sh -daemon config/server.properties

-daemon signifie démarrer le service kafka en arrière-plan, de sorte que la fenêtre de commande actuelle ne soit pas occupée.

Le processus de Kafka peut être visualisé via la commande jps.

5. Comprendre le sujet, la partition et le courtier du serveur

Ensuite, vous pouvez comparer les services autonomes précédents pour comprendre rapidement les principaux sujets, partitions et courtiers du cluster Kafka.

./kafka-topics.sh --bootstrap-server master:9092 --create --replication-factor 2 --partitions 4 --topic disTopic Created topic disTopic.

./kafka-topics.sh --bootstrap-server master:9092 --describe --topic disTopic

1. –create crée un cluster, vous pouvez spécifier des paramètres supplémentaires. La plupart des paramètres peuvent spécifier des valeurs par défaut dans le fichier de configuration.

• Le paramètre partitions indique le nombre de partitions, et les messages sous ce sujet seront stockés dans ces différentes partitions. Le disTopic créé dans l'exemple spécifie quatre partitions, ce qui signifie que les messages sous ce sujet seront divisés en quatre parties.
• Le facteur de réplication indique le nombre de sauvegardes de chaque partition. Le disTopic créé dans l'exemple spécifie deux sauvegardes pour chaque partition.

2. –describe Afficher les informations du sujet.

• Le paramètre partition répertorie quatre partitions, suivies de numéros de partition pour identifier ces partitions.
• Leader indique lequel est le nœud Leader dans ce groupe de partitions. Le nœud leader est le nœud maître chargé de répondre aux demandes des clients. On peut voir à partir d'ici que chaque partition de Kafka se verra attribuer un leader, ce qui signifie que chaque partition a différents nœuds chargés de répondre aux demandes des clients. De cette façon, les demandes du client peuvent être réparties autant que possible.
• Le paramètre Replicas indique sur quels Brokers sont allouées les multiples sauvegardes de cette partition. Aussi connu sous le nom d'AR. Les 0, 1 et 2 correspondent ici au broker.id spécifié lors de la configuration du cluster. Cependant, ce que répertorie les répliques n'est qu'une allocation logique et ne se soucie pas de savoir si les données sont réellement allouées en fonction de cela. Même après l'arrêt de certains services de nœud, l'ID du nœud sera toujours répertorié dans les répliques.
• Le paramètre ISR indique l'allocation réelle de la partition. Il s'agit d'un sous-ensemble d'AR et ne répertorie que les nœuds Broker qui sont actuellement actifs et peuvent synchroniser les données normalement.

Ensuite, nous pouvons également vérifier la distribution de la partition sous Sujet. Sur Broker, le plus étroitement lié à l'actualité est en fait Partition. Lors de la configuration du cluster Kafka auparavant, un attribut log.dirs était spécifié, pointant vers un répertoire de journaux sur un serveur. En entrant dans ce répertoire, vous pouvez voir l'état réel des données portant sur chaque courtier.

De l'ensemble du processus, nous pouvons voir que dans Kafka, Topic est une unité logique de collecte de données. Les données sous le même sujet sont en fait stockées dans la partition de partition, et la partition est l'unité physique de stockage de données. Le courtier est le support physique de la partition, et ces partitions de partition seront distribuées aux différentes machines du courtier aussi uniformément que possible. Le décalage qui a été touché avant est le décalage de chaque message sur la partition

​ Pourquoi Kafka conçoit-il ainsi la relation entre Topic, Partition et Broker ?
1. La conception de Kafka doit prendre en charge des quantités massives de données, et une telle quantité de données ne peut pas être stockée dans un seul Broker. Ensuite, divisez-le en plusieurs partitions, et chaque courtier ne stocke qu'une partie des données. Cela augmente considérablement le débit du cluster.

2. Chaque partition conserve une partie de la copie du message. Si elle est placée sur un courtier, elle est sujette à un point de défaillance unique. Par conséquent, un nœud suiveur est conçu pour chaque partition afin d'effectuer une sauvegarde des données afin d'assurer la sécurité des données. De plus, la conception de la partition multi-sauvegarde améliore également la simultanéité lors de la lecture des messages.
3. Parmi les multiples partitions du même sujet, une partition sera générée en tant que leader. Cette Partition Leader sera chargée de répondre aux demandes des clients et de distribuer les données aux autres Partitions.

6. Résumé du chapitre : la structure globale du cluster Kafka

1. Le sujet est un concept logique. Le producteur et le consommateur mènent une communication commerciale via le sujet.

2. Le sujet ne stocke pas de données et les données sous le sujet sont divisées en plusieurs groupes de partitions, qui sont distribuées aussi uniformément que possible à chaque courtier. Chaque ensemble de partitions contient des messages pour la partie suivante du sujet. Chaque partition contient une partition principale et plusieurs partitions suiveuses pour la sauvegarde. Le nombre de partitions dans chaque groupe est appelé le facteur de réplique du facteur de sauvegarde.

3. Le producteur envoie le message à la partition correspondante, puis le consommateur utilise le décalage de décalage sur la partition pour enregistrer la progression du groupe de consommateurs auquel il appartient qui consomme le message sur la partition actuelle.

4. Le message envoyé par le producteur à un sujet sera envoyé par Kafka à tous les groupes de consommateurs abonnés au sujet pour traitement. Mais au sein de chaque groupe de consommateurs, une seule instance de consommateur traitera ce message.

5. Enfin, Kafka's Broker forme un cluster via Zookeeper. Ensuite, parmi ces courtiers, un courtier qui agit en tant que contrôleur doit être élu. La tâche principale de ce contrôleur est d'être responsable de l'attribution des sujets et de la gestion du suivi. Dans notre cluster expérimental, ce contrôleur est en fait généré via ZooKeeper.