Cluster zookeeper et cluster kafka [distribués]

Cluster Zookeeper + cluster Kafka

1. Présentation de Zookeeper

1.1 Définition du gardien de zoo

Zookeeper est un projet Apache distribué open source qui fournit des services de coordination pour les frameworks distribués.

1.2 Mécanisme de travail du gardien de zoo

Zookeeper est compris du point de vue des modèles de conception : il s'agit d'un cadre de gestion de services distribués conçu sur la base du modèle d'observateur. Il est responsable du stockage et de la gestion des données qui intéressent tout le monde, puis accepte l'enregistrement des observateurs. Une fois l'état de ces changements de données, Zookeeper sera chargé d'informer les observateurs enregistrés auprès de Zookeeper de réagir en conséquence. C'est-à-dire Zookeeper = système de fichiers + mécanisme de notification.

1.3 Fonctionnalités du gardien de zoo

1. Zookeeper : un leader (Leader), un groupe de plusieurs suiveurs (Follower).
2. Tant que plus de la moitié des nœuds du cluster Zookeeper survivent, le cluster Zookeeper peut fonctionner normalement. Zookeeper convient donc à l'installation d'un nombre impair de serveurs.
3. Cohérence globale des données : chaque serveur enregistre une copie des mêmes données, et les données sont cohérentes quel que soit le serveur auquel le client se connecte.
4. Les demandes de mise à jour sont exécutées séquentiellement, et les demandes de mise à jour d'un même Client sont exécutées séquentiellement dans l'ordre dans lequel elles sont envoyées, c'est-à-dire premier entré premier sorti.
5. Atomicité de la mise à jour des données, une mise à jour des données réussit ou échoue.
6. En temps réel, dans un certain intervalle de temps, le Client peut lire les dernières données.

1.4 Structure des données Zookeeper

La structure du modèle de données ZooKeeper est très similaire au système de fichiers Linux, qui peut être considéré comme un arbre dans son ensemble, et chaque nœud est appelé un ZNode. Chaque ZNode peut stocker 1 Mo de données par défaut, et chaque ZNode peut être identifié de manière unique par son chemin.

1.5 Scénarios d'application Zookeeper

Les services fournis incluent : service de nommage unifié, gestion unifiée de la configuration, gestion unifiée des clusters, nœuds de serveur dynamiques en ligne et hors ligne, équilibrage de charge logicielle, etc.

• Service de nommage unifié
  Dans un environnement distribué, il est souvent nécessaire de nommer uniformément les applications/services pour une identification facile. Par exemple : l'adresse IP n'est pas facile à retenir, mais le nom de domaine est facile à retenir.

• Gestion de configuration unifiée
  (1) Dans un environnement distribué, la synchronisation des fichiers de configuration est très courante. Il est généralement nécessaire que dans un cluster, les informations de configuration de tous les nœuds soient cohérentes, comme le cluster Kafka. Une fois le fichier de configuration modifié, on espère qu'il pourra être rapidement synchronisé avec chaque nœud.
  (2) La gestion de la configuration peut être mise en œuvre par ZooKeeper. Les informations de configuration peuvent être écrites sur un Znode sur ZooKeeper. Chaque serveur client écoute ce Znode. Une fois les données dans Znode modifiées, ZooKeeper notifiera chaque serveur client.

• Gestion unifiée des clusters
  (1) Dans un environnement distribué, il est nécessaire de connaître l'état de chaque nœud en temps réel. Certains ajustements peuvent être effectués en fonction de l'état en temps réel des nœuds.
  (2) ZooKeeper peut réaliser une surveillance en temps réel des changements d'état des nœuds. Les informations de nœud peuvent être écrites dans un ZNode sur ZooKeeper. L'écoute de ce ZNode peut obtenir ses changements d'état en temps réel.

• Le serveur passe dynamiquement en ligne et hors ligne
  Le client peut voir les changements du serveur en ligne et hors ligne en temps réel.

• L'équilibrage de charge souple
  enregistre le nombre de visites de chaque serveur dans Zookeeper et laisse le serveur avec le moins de visites gérer les dernières demandes des clients.

1.6 Mécanisme d'élection des gardiens de zoo

• Démarrer le mécanisme d'élection pour la première fois
  (1) Le serveur 1 démarre et initie une élection. Le serveur 1 vote pour lui-même. A ce moment, le serveur 1 a un vote, moins de la moitié (3 votes), l'élection ne peut pas être complétée, et le statut du serveur 1 reste EN RECHERCHE ; (2) Le serveur 2 est démarré et une
  autre élection est initiée. Les serveurs 1 et 2 émettent leurs propres votes et échangent des informations de vote : à ce moment, le serveur 1 trouve que le myid du serveur 2 est plus grand que celui pour lequel il a actuellement voté (serveur 1) et modifie le vote pour recommander le serveur 2. À ce moment, le serveur 1 a 0 vote et le serveur 2 en a 2. S'il n'y a pas plus de la moitié des résultats, l'élection ne peut pas être terminée et le statut des serveurs 1 et 2 reste RECHERCHE. (3) Le serveur 3
  démarre et organise une élection. À ce stade, les serveurs 1 et 2 changeront leurs votes pour le serveur 3. Le résultat de ce vote : le serveur 1 a 0 vote, le serveur 2 a 0 vote et le serveur 3 a 3 votes. A ce moment, le serveur 3 a plus de la moitié des voix et le serveur 3 est élu leader. Les serveurs 1 et 2 changent leur statut en FOLLOWING, et le serveur 3 change leur statut en LEADING ;
  (4) Le serveur 4 démarre et initie une élection. À ce stade, les serveurs 1, 2 et 3 ne sont plus dans l'état LOOKING et les informations sur le bulletin de vote ne seront pas modifiées. Le résultat de l'échange d'informations sur les bulletins de vote : le serveur 3 a 3 votes et le serveur 4 a 1 vote. À ce moment, le serveur 4 obéit à la majorité, change les informations de vote sur le serveur 3 et change le statut en SUIVANT ; (5) le serveur 5 démarre et agit comme un jeune frère comme 4.

• Le mécanisme d'élection n'est pas démarré pour la première fois
  (1) Lorsqu'un serveur du cluster ZooKeeper rencontre l'une des deux situations suivantes, il commencera à entrer dans l'élection du Leader :
  1) Le serveur est initialisé et démarré.
  2) La connexion au leader ne peut pas être maintenue pendant que le serveur est en cours d'exécution.

(2) Lorsqu'une machine entre dans le processus d'élection du leader, le cluster actuel peut également être dans les deux états suivants :
1) Il y a déjà un leader dans le cluster.
Dans le cas où un leader existe déjà, lorsque la machine essaie d'élire un leader, elle sera informée des informations de leader du serveur actuel. Pour cette machine, il lui suffit d'établir une connexion avec la machine leader et d'effectuer une synchronisation d'état .

2) Il n'y a effectivement pas de Leader dans le cluster.
Supposons que ZooKeeper se compose de 5 serveurs, les SID sont 1, 2, 3, 4 et 5, et les ZXID sont 8, 8, 8, 7 et 7, et le serveur avec le SID 3 est le leader. À un moment donné, les serveurs 3 et 5 échouent, donc une élection de chef commence.
Règles du chef d'élection :
1. Celui avec la plus grande EPOCH gagne directement
2. Celui avec la même EPOCH et le plus grand identifiant de transaction gagne
3. Celui avec le même identifiant de transaction et le plus grand identifiant de serveur gagne

SID : identifiant du serveur. Il est utilisé pour identifier de manière unique une machine dans un cluster ZooKeeper. Chaque machine ne peut pas être répétée et est cohérente avec myid.
ZXID : identifiant de la transaction. ZXID est un ID de transaction utilisé pour identifier un changement d'état du serveur. A un certain moment, la valeur ZXID de chaque machine du cluster peut ne pas être exactement la même, ce qui est lié à la vitesse de la logique de traitement du serveur ZooKeeper pour la "requête de mise à jour" du client.
Epoque : Le nom de code pour chaque terme Leader. La valeur de l'horloge logique dans le même tour de processus de vote est la même lorsqu'il n'y a pas de Leader. Ce nombre augmente à chaque vote

2. Déployer le cluster Zookeeper

2.1 Déploiement de l'environnement

//准备 3 台服务器做 Zookeeper 集群
192.168.80.10
192.168.80.11
192.168.80.12

2.2 Désactiver le pare-feu

1.安装前准备
//关闭防火墙
systemctl stop firewalld
systemctl disable firewalld
setenforce 0

2.3 Installer JDK Téléchargez le package d'installation et installez Zookeeper

//安装 JDK
yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel
java -version

//下载安装包
官方下载地址：https://archive.apache.org/dist/zookeeper/

cd /opt
wget https://archive.apache.org/dist/zookeeper/zookeeper-3.5.7/apache-zookeeper-3.5.7-bin.tar.gz


2.安装 Zookeeper
cd /opt
tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz
mv apache-zookeeper-3.5.7-bin /usr/local/zookeeper-3.5.7

2.4 Modifier le fichier de configuration

cd /usr/local/zookeeper-3.5.7/conf/
cp zoo_sample.cfg zoo.cfg

vim zoo.cfg
tickTime=2000   #通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
initLimit=10    #Leader和Follower初始连接时能容忍的最多心跳数（tickTime的数量），这里表示为10*2s
syncLimit=5     #Leader和Follower之间同步通信的超时时间，这里表示如果超过5*2s，Leader认为Follwer死掉，并从服务器列表中删除Follwer
dataDir=/usr/local/zookeeper-3.5.7/data      ●修改，指定保存Zookeeper中的数据的目录，目录需要单独创建
dataLogDir=/usr/local/zookeeper-3.5.7/logs   ●添加，指定存放日志的目录，目录需要单独创建
clientPort=2181   #客户端连接端口
#添加集群信息
server.1=192.168.80.10:3188:3288
server.2=192.168.80.11:3188:3288
server.3=192.168.80.12:3188:3288

server.A=B:C:D
●A est un nombre, indiquant de quel numéro de serveur il s'agit. En mode cluster, vous devez créer un fichier myid dans le répertoire spécifié par dataDir dans zoo.cfg. Il y a une donnée dans ce fichier qui est la valeur de A. Lorsque Zookeeper démarre, lisez ce fichier, récupérez les données qu'il contient et la configuration dans zoo.cfg Comparez les informations pour déterminer de quel serveur il s'agit.
● B est l'adresse de ce serveur.
●C est le port par lequel le Follower de ce serveur échange des informations avec le serveur Leader du cluster.
●D signifie qu'au cas où le serveur leader du cluster raccroche, un port est nécessaire pour réélire un nouveau leader, et ce port est le port utilisé pour la communication entre les serveurs lors de l'élection.

2.5 Copier la configuration sur d'autres serveurs

//拷贝配置好的 Zookeeper 配置文件到其他机器上
scp /usr/local/zookeeper-3.5.7/conf/zoo.cfg 192.168.80.11:/usr/local/zookeeper-3.5.7/conf/
scp /usr/local/zookeeper-3.5.7/conf/zoo.cfg 192.168.80.12:/usr/local/zookeeper-3.5.7/conf/

//在每个节点上创建数据目录和日志目录
mkdir /usr/local/zookeeper-3.5.7/data
mkdir /usr/local/zookeeper-3.5.7/logs

//在每个节点的dataDir指定的目录下创建一个 myid 的文件
echo 1 > /usr/local/zookeeper-3.5.7/data/myid
echo 2 > /usr/local/zookeeper-3.5.7/data/myid
echo 3 > /usr/local/zookeeper-3.5.7/data/myid

2.6 Configurer le script de démarrage de Zookeeper

//配置 Zookeeper 启动脚本
vim /etc/init.d/zookeeper
#!/bin/bash
#chkconfig: 2345 20 90
#description:Zookeeper Service Control Script
ZK_HOME='/usr/local/zookeeper-3.5.7'
case $1 in
start)
	echo "---------- zookeeper 启动 ------------"
	$ZK_HOME/bin/zkServer.sh start
;;
stop)
	echo "---------- zookeeper 停止 ------------"
	$ZK_HOME/bin/zkServer.sh stop
;;
restart)
	echo "---------- zookeeper 重启 ------------"
	$ZK_HOME/bin/zkServer.sh restart
;;
status)
	echo "---------- zookeeper 状态 ------------"
	$ZK_HOME/bin/zkServer.sh status
;;
*)
    echo "Usage: $0 {start|stop|restart|status}"
esac

//	设置开机自启
chmod +x /etc/init.d/zookeeper
chkconfig --add zookeeper

//分别启动 Zookeeper
service zookeeper start

//查看当前状态
service zookeeper status

3. Présentation de Kafka

3.1 Pourquoi la file d'attente des messages - (MQ)

• La raison principale est que dans un environnement à forte concurrence, les demandes synchrones sont trop tardives pour être traitées et les demandes se bloquent souvent. Par exemple, un grand nombre de requêtes accèdent simultanément à la base de données, entraînant des verrous de lignes et des verrous de tables. Au final, trop de threads de requêtes s'accumuleront, ce qui déclenchera trop d'erreurs de connexion et provoquera un effet d'avalanche.
• Nous utilisons des files d'attente de messages pour alléger la pression sur le système en traitant les demandes de manière asynchrone. Les files d'attente de messages sont souvent utilisées dans des scénarios tels que le traitement asynchrone, l'écrêtement des pics de trafic, le découplage d'applications et la communication de messages.

Actuellement, les middleware MQ les plus courants incluent ActiveMQ, RabbitMQ, RocketMQ, Kafka, etc.

3.2 Avantages de l'utilisation des files d'attente de messages

(1) Le découplage
vous permet d'étendre ou de modifier indépendamment le traitement des deux côtés, tant qu'ils respectent les mêmes contraintes d'interface.

(2) Récupération
Lorsqu'une partie du système tombe en panne, cela n'affectera pas l'ensemble du système. La file d'attente de messages réduit le couplage entre les processus, de sorte que même si un processus qui traite les messages raccroche, les messages ajoutés à la file d'attente peuvent toujours être traités après la récupération du système.

(3) La mise en mémoire tampon
permet de contrôler et d'optimiser la vitesse du flux de données dans le système et de résoudre l'incohérence de la vitesse de traitement des messages de production et des messages de consommation.

(4) Flexibilité et capacité de traitement de pointe
Dans le cas d'une forte augmentation du trafic, l'application doit continuer à fonctionner, mais un tel trafic en rafale n'est pas courant. C'est sans aucun doute un énorme gaspillage d'investir des ressources en attente à tout moment pour gérer un tel accès de pointe. L'utilisation de files d'attente de messages peut permettre aux composants clés de résister à une pression d'accès soudaine sans tomber complètement en panne en raison de demandes de surcharge soudaines.

(5) Communication asynchrone
Dans de nombreux cas, les utilisateurs ne veulent pas ou n'ont pas besoin de traiter les messages immédiatement. Les files d'attente de messages fournissent un mécanisme de traitement asynchrone qui permet aux utilisateurs de placer un message dans une file d'attente sans le traiter immédiatement. Mettez autant de messages que vous le souhaitez dans la file d'attente et traitez-les si nécessaire.

3.3 Deux modes de file d'attente de messages

(1) Mode point à point (un à un, le consommateur extrait activement les données et le message est effacé une fois le message reçu) Le producteur de message produit un message et l'envoie à la file d'attente de messages,
puis le consommateur de messages le retire de la file d'attente de messages et consomme le message. Une fois le message consommé, il n'y a plus de stockage dans la file d'attente de messages, il est donc impossible pour le consommateur de messages de consommer le message qui a déjà été consommé. La file d'attente de messages prend en charge plusieurs consommateurs, mais pour un message, un seul consommateur peut le consommer.

(2) Mode publication / abonnement (un à plusieurs, également appelé mode observateur, le message ne sera pas effacé une fois que le consommateur aura consommé les données), le producteur du message (publier
) publie le message sur le sujet, et il existe plusieurs consommateurs de message (subscribe ) pour consommer le message. Contrairement à la méthode peer-to-peer, les messages publiés sur un sujet seront consommés par tous les abonnés.
Le mode publication/abonnement définit une relation de dépendance un à plusieurs entre les objets, de sorte que chaque fois que l'état d'un objet (objet cible) change, tous les objets (objets observateurs) qui en dépendent seront notifiés et automatiquement mis à jour.

3.4 définition de kafka

Kafka est une file d'attente de messages distribuée basée sur la publication/l'abonnement (MQ, Message Queue), qui est principalement utilisée dans le calcul en temps réel et la collecte de journaux dans le domaine du Big Data.

3.5 présentation de Kafka

Kafka a été développé à l'origine par Linkedin. Il s'agit d'un middleware de messagerie distribué, prenant en charge les partitions et basé sur une réplique, basé sur la coordination Zookeeper. Sa principale caractéristique est qu'il peut traiter de grandes quantités de données en temps réel. Pour répondre à divers scénarios de demande, tels que le système de traitement par lots basé sur hadoop, le système en temps réel à faible latence, le moteur de traitement de streaming Spark / Flink, le journal d'accès nginx, le service de messagerie, etc., écrit en langage scala, Linkedin y a contribué en 2010 The Apache Foundation et est
devenu un projet open source de premier plan.

3.6 Caractéristiques de Kafka

• Kafka à haut débit et à faible latence
  peut traiter des centaines de milliers de messages par seconde, et sa latence est aussi faible que quelques millisecondes. Chaque sujet peut être divisé en plusieurs partitions, et le groupe de consommateurs effectue des opérations de consommation sur les partitions pour améliorer les capacités d'équilibrage de charge et de consommation.

• 
  Le cluster Kafka prend en charge l'expansion à chaud

• Persistance et fiabilité
  Les messages sont conservés sur les disques locaux et la sauvegarde des données est prise en charge pour éviter la perte de données

• La tolérance aux pannes
  permet aux nœuds du cluster de tomber en panne (dans le cas de copies multiples, si le nombre de copies est n, n-1 nœuds sont autorisés à tomber en panne)

• Haute simultanéité
  Prend en charge des milliers de clients pour lire et écrire en même temps

3.7 architecture du système kafka

(1) Courtier
Un serveur kafka est un courtier. Un cluster se compose de plusieurs courtiers. Un courtier peut accueillir plusieurs sujets.

(2) Le sujet
peut être compris comme une file d'attente, et les producteurs et les consommateurs sont confrontés au même sujet.
Semblable au nom de table de la base de données ou à l'index de l'ES,
les messages des différents sujets sont stockés séparément

(3) Partition
Afin d'atteindre l'évolutivité, un sujet très volumineux peut être distribué à plusieurs courtiers (c'est-à-dire des serveurs), un sujet peut être divisé en une ou plusieurs partitions, et chaque partition est une file d'attente ordonnée. Kafka garantit uniquement que les enregistrements de la partition sont en ordre, mais ne garantit pas l'ordre des différentes partitions dans le sujet.

Chaque sujet a au moins une partition. Lorsque le producteur génère des données, il sélectionne une partition en fonction de la stratégie d'allocation, puis ajoute le message à la fin de la file d'attente de la partition spécifiée.
##Règles de routage des données de partition :
1．Si patition est spécifié, utilisez-le directement ;
2. 3. Si aucune patition n'est spécifiée mais qu'une clé est spécifiée (équivalent à un attribut dans le message), une patition est sélectionnée en effectuant un hachage modulo sur la valeur de la clé ; 3
．La patition et la clé ne sont pas spécifiées, et une patition est sélectionnée par interrogation.

Chaque message aura un numéro auto-incrémenté, qui est utilisé pour identifier le décalage du message, et la séquence d'identification commence à partir de 0.

Les données de chaque partition sont stockées à l'aide de plusieurs fichiers de segments.

Si le sujet comporte plusieurs partitions, l'ordre des données ne peut pas être garanti lors de la consommation de données. Dans le scénario où l'ordre de consommation des messages est strictement garanti (comme les ventes flash de produits et la saisie d'enveloppes rouges), le nombre de partitions doit être défini sur 1.

• Broker stocke les données de sujet. Si un sujet a N partitions et que le cluster a N courtiers, chaque courtier stocke une partition du sujet.
• Si un sujet a N partitions et que le cluster a (N+M) courtiers, alors il y a N courtiers qui stockent une partition du sujet, et les M courtiers restants ne stockent pas les données de partition du sujet.
• Si un sujet a N partitions et que le nombre de courtiers dans le cluster est inférieur à N, alors un courtier stocke une ou plusieurs partitions du sujet. Dans l'environnement de production réel, essayez d'éviter cette situation, qui peut facilement entraîner un déséquilibre des données dans le cluster Kafka.

3.8 Raisons du partitionnement

• Il est pratique de se développer dans le cluster.Chaque partition peut être ajustée pour s'adapter à la machine sur laquelle elle se trouve, et un sujet peut être composé de plusieurs partitions, de sorte que l'ensemble du cluster peut s'adapter aux données de toute taille ;
• La simultanéité peut être améliorée car elle peut être lue et écrite en unités de partition.

(4)
Copie de réplique. Afin de s'assurer qu'en cas de défaillance d'un nœud du cluster, les données de partition sur le nœud ne seront pas perdues et Kafka pourra continuer à fonctionner. Kafka fournit un mécanisme de copie. Chaque partition d'un sujet a plusieurs répliques, un leader et plusieurs partisans.

(5)
Chaque partition du leader a plusieurs copies, et un seul d'entre eux est le leader. Le leader est actuellement responsable de la lecture et de l'écriture des données.

(6) Suiveur Le
suiveur suit le leader, toutes les demandes d'écriture sont acheminées via le leader, les modifications de données seront diffusées à tous les suiveurs, et le suiveur et le leader maintiennent la synchronisation des données. Le suiveur est uniquement responsable de la sauvegarde, pas de la lecture et de l'écriture des données.
Si le Leader échoue, un nouveau Leader est élu parmi les Followers.
Lorsque le suiveur se bloque, se bloque ou est trop lent à se synchroniser, le leader supprimera le suiveur de la liste ISR (un ensemble de suiveurs maintenu par le leader qui est synchronisé avec le leader) et créera un nouveau suiveur.

(7) Producteur
Le producteur est l'éditeur des données, ce rôle publie le message push vers le sujet de Kafka.
Une fois que le courtier a reçu le message envoyé par le producteur, le courtier ajoute le message au fichier de segment actuellement utilisé pour ajouter des données.
Le message envoyé par le producteur est stocké dans une partition, et le producteur peut également spécifier la partition du stockage des données.

(8) Les consommateurs
peuvent extraire des données du courtier. Les consommateurs peuvent consommer des données provenant de plusieurs sujets.

(9) Groupe de consommateurs (CG)
Le groupe de consommateurs se compose de plusieurs consommateurs.
Tous les consommateurs appartiennent à un groupe de consommateurs, c'est-à-dire qu'un groupe de consommateurs est un abonné logique. Un nom de groupe peut être spécifié pour chaque consommateur, et si aucun nom de groupe n'est spécifié, il appartient au groupe par défaut.
La collecte de plusieurs consommateurs ensemble pour traiter les données d'un certain sujet peut améliorer la capacité de consommation des données plus rapidement.
Chaque consommateur du groupe de consommateurs est responsable de la consommation des données de différentes partitions. Une partition ne peut être consommée que par un seul consommateur du groupe pour éviter que les données ne soient lues à plusieurs reprises.
Les groupes de consommateurs ne s'influencent pas les uns les autres.

(10) offset
peut identifier de manière unique un message.
Le décalage détermine l'emplacement des données lues et il n'y aura pas de problèmes de sécurité des threads. Le consommateur utilise le décalage pour déterminer le message à lire la prochaine fois (c'est-à-dire l'emplacement de consommation).
Une fois le message consommé, il n'est pas supprimé immédiatement, de sorte que plusieurs entreprises peuvent réutiliser les messages Kafka.
Un certain service peut également atteindre l'objectif de relire les messages en modifiant le décalage, qui est contrôlé par l'utilisateur.
Le message sera éventuellement supprimé et le cycle de vie par défaut est de 1 semaine (7*24 heures).

(11) Zookeeper
Kafka utilise Zookeeper pour stocker les méta-informations du cluster.

Étant donné que le consommateur peut subir des pannes telles que des pannes de courant et des temps d'arrêt pendant le processus de consommation, après le rétablissement du consommateur, il doit continuer à consommer à partir de l'emplacement avant la panne.Par conséquent, le consommateur doit enregistrer quel décalage il consomme en temps réel, afin qu'il puisse continuer à consommer après la récupération de la panne.
Avant la version 0.9 de Kafka, le consommateur enregistrait le décalage dans Zookeeper par défaut ; à partir de la version 0.9, le consommateur enregistrait le décalage dans un sujet Kafka intégré par défaut, qui est __consumer_offsets.

C'est-à-dire que le rôle de zookeeper est que lorsque le producteur envoie des données au cluster kafka, il est nécessaire de savoir où se trouvent les nœuds du cluster kafka, et ceux-ci sont tous trouvés via zookeeper. L'élément de données consommé par le consommateur doit également être pris en charge par zookeeper. Le décalage est obtenu à partir de zookeeper et l'offset enregistre l'endroit où les dernières données consommées ont été consommées, de sorte que le prochain élément de données puisse être consommé ensuite.

Résumer

Zookeeper   分布式系统管理框架，主要用来解决分布式集群中应用系统的一致性问题    相当于各种分布式应用服务的 注册中心 + 文件系统 + 通知机制
本质： 用于注册各种各种分布式应用，存储和管理各种分布式应用服务的元数据，如果应用服务状态发生改变会通知客户端

Zookeeper 选举机制
第一次选举：比较服务器节点的myid，谁myid大就获取比它小的服务器节点的选票，当选票超过节点服务器数量的半数则当选为leader，其它节点为follower，即使后面再有其它myid更大的节点加入到集群也不会影响之前的选举结果。

非第一次选举：如果是非leader节点故障，替换的新节点继续当follower，与leader对接并同步数据
              如果是leader节点故障，则需要重新选举新leader，先比较每个节点的Epoch（参加选举的次数），选最大的当leader
			                                                若Epoch有相同的节点，则再比较ZXID（写操作的事务ID），选ZXID最大的当leader
															若ZXID也有相同的节点，则再比较SID（等同于myid），选SID最大的当leader
															
															
中间件   消息队列型（MQ）  ActiveMQ、RabbitMQ、RocketMQ、Kafka、Pulsar、Redis
         Web应用型（代理服务器）  Nginx、Haproxy、LVS、Tomcat、php
	
	
消息队列的作用：应用解耦、异步处理、流量削峰、缓冲
		 
消息队列的模式：
点对点模式 ：一对一，消费者消费消息后会删除消息
发布/订阅模式（观察者模式）：一对多，消费者消费后不会删除消息
		 
Kafka架构
broker    kafka服务器节点
producer  生产者，发布消息到topic
consumer  消费者    
consumer group   消费者组，是消息的实际订阅者，一个消费者组包含一个或多个消费者（组内成员不能重复消费同一个partition数据）  

producer -> topic消息队列 -> partition分区 -> replica副本（leader负责数据读写、follower只负责同步复制leader的数据）

consumer -> offset偏移量（用来记录消费者上一次消费的位置） 

zookeeper 存储kafka集群的元数据信息，生产者和消费者的动作都需要zookeeper的管理和支持。
          比如生产者推送数据到kafka集群需要通过zookeeper去寻找kafka服务器节点的位置，消费者需要从zookeeper获取offset记录的上一次消费的位置继续往后消费
		  
kafka 只能保证 partition分区内的消息顺序，消费时无法保证 partition 之间的顺序。
如需要严格保证消息的消费顺序（商品秒杀、抢红包等场景）要把 partition 数据设置为 1