Guide de démarrage de ZooKeeper

Guide de démarrage de ZooKeeper


Démarrer: coordonner les programmes distribués via le gardien de zoo

Ce document contient des informations d'aide pour vous familiariser rapidement avec zookeeper. Cet article s'adresse principalement aux développeurs qui souhaitent essayer d'utiliser zookeeper au début. Il contient quelques exemples simples, utilisant un seul serveur zookeeper, quelques commandes pour confirmer que le serveur est en cours d'exécution et un exemple de programme simple. À la fin de l'article, pour plus de commodité, il y a aussi du contenu qui considère des exemples relativement compliqués. Par exemple, déployez en mode de réplication pour optimiser les journaux de transactions. Mais si vous souhaitez l'appliquer à des projets commerciaux. Veuillez consulter le Guide de l'administrateur ZooKeeper

conditions préalables

Reportez-vous à la configuration système requise dans le manuel de gestion

Télécharger

Téléchargez la version stable de Zookeeper depuis le site miroir Apache .

Fonctionnement autonome

Le démarrage du serveur zookeeper en mode autonome est simple. Le service zookeeper est contenu dans un seul fichier jar, de sorte que le processus d'installation inclut la configuration de la configuration.

Une fois que vous avez téléchargé la version stable de Zookeeper, vous pouvez la décompresser et entrer dans son répertoire racine.

Pour démarrer zookeeper, vous avez d'abord besoin d'un fichier de configuration. Voici un exemple, vous pouvez le créer dans conf / zoo.cfg :

tickTime=2000 
dataDir=/var/lib/zookeeper
clientPort=2181

Vous pouvez nommer ce fichier comme vous le souhaitez, mais pour la clarté de la description, nous l'appellerons conf / zoo.cfg. Définissez la valeur de dataDir sur un répertoire existant (initialement vide). Ce qui suit est une introduction à la signification de chaque champ:


L'unité de temps utilisée par tickTime zookeeper est la milliseconde. Cette heure est comme le temps de battement de cœur du gardien de zoo, et la plage de temporisation de l'unité de session minimale est deux fois cette fois.

Le
répertoire dataDir est l'emplacement où les instantanés de base de données en mémoire sont stockés. Sauf indication contraire de votre part, les journaux des transactions qui mettent à jour la base de données se trouvent également à cet emplacement.


port d'écoute de connexion client clientPort .

Maintenant que vous avez créé ce fichier de configuration, vous pouvez démarrer Zookeeper:

bin/zkServer.sh start

La journalisation de ZooKeeper se fait via log4j - veuillez vous référer au manuel du développeur pour plus d' explications sur la journalisation . Vous verrez que les informations du journal sont envoyées à la console et / ou au fichier journal selon la configuration de log4j.

Le gardien de zoo de démarrage décrit ici est en mode singleton. Il n'y a pas de réplication ici, donc si le processus de gardien de zoo échoue, le service se bloquera. Le démarrage en mode singleton est bon pour l'environnement de développement. Si vous souhaitez démarrer Zookeeper en mode de réplication, veuillez consulter Exécution de ZooKeeper répliqué .

Gérer le stockage ZooKeeper

Pour le service zookeeper qui s'exécute dans l'environnement de production pendant une longue période, le stockage doit être géré en plus (dataDir et logs). Pour plus de détails à ce sujet, veuillez consulter la maintenance

Connectez-vous à ZooKeeper

bin/zkCli.sh -server 127.0.0.1:2181

Grâce à cette commande, vous pouvez utiliser Zookeeper d'une manière simple similaire aux opérations sur les fichiers.

Une fois que vous êtes connecté, vous pouvez voir quelque chose de similaire à ce qui suit:

Connecting to localhost:2181
log4j:WARN No appenders could be found for logger (org.apache.zookeeper.ZooKeeper).
log4j:WARN Please initialize the log4j system properly.
Welcome to ZooKeeper!
JLine support is enabled
[zkshell: 0]

Si zookeeper est déjà en cours d'exécution, vous pouvez vous connecter via les options suivantes

Exécutez à partir du shell, tapez help pour obtenir une liste de commandes que le client peut exécuter, comme suit:

[zkshell: 0] help
ZooKeeper host:port cmd args
        get path [watch]
        ls path [watch]
        set path data [version]
        delquota [-n|-b] path
        quit
        printwatches on|off
        create path data acl
        stat path [watch]
        listquota path
        history
        setAcl path acl
        getAcl path
        sync path
        redo cmdno
        addauth scheme auth
        delete path [version]
        deleteall path
        setquota -n|-b val path

Vous pouvez essayer quelques commandes simples pour comprendre cette ligne de commande simple. Commencez par comprendre cette liste de commandes, telles que ls, comme suit:
[zkshell: 8] ls /
[zookeeper]

Ensuite, créez un nouveau znode en exécutant create / zk_test my_data. Cela créera un nouveau znode et l'associera à la chaîne de données "my_data" . Vous pouvez voir les résultats suivants:

[zkshell: 9] create /zk_test my_data
Created /zk_test

Exécutez la commande ls / pour voir la situation actuelle du répertoire:

[zkshell: 11] ls /
[zookeeper, zk_test]

Notez que ce répertoire zk_test a été créé.

Ensuite, vous pouvez confirmer les données associées à ce nœud en exécutant la commande get, comme suit:

[zkshell: 12] get /zk_test
my_data
cZxid = 5
ctime = Fri Jun 05 13:57:06 PDT 2009
mZxid = 5
mtime = Fri Jun 05 13:57:06 PDT 2009
pZxid = 5
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0
dataLength = 7
numChildren = 0

Nous pouvons également modifier les données associées à zk_test via la commande set, comme suit:

[zkshell: 14] set /zk_test junk
cZxid = 5
ctime = Fri Jun 05 13:57:06 PDT 2009
mZxid = 6
mtime = Fri Jun 05 14:01:52 PDT 2009
pZxid = 5
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0
dataLength = 4
numChildren = 0
[zkshell: 15] get /zk_test
junk
cZxid = 5
ctime = Fri Jun 05 13:57:06 PDT 2009
mZxid = 6
mtime = Fri Jun 05 14:01:52 PDT 2009
pZxid = 5
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0
dataLength = 4
numChildren = 0

(Notez que nous avons exécuté la commande get après avoir défini les données de zk_test, et les données ont changé).
Enfin, supprimez le nœud zk_test en supprimant:

[zkshell: 16] delete /zk_test
[zkshell: 17] ls /
[zookeeper]
[zkshell: 18]

Pour plus d'informations, veuillez consulter le Guide du programmeur .

Programmation de ZooKeeper

ZooKeeper a des liaisons pour Java et C. Ils sont finalement équivalents. La liaison C a deux variantes: mono-thread et multi-thread. Ils ne diffèrent que par la manière dont la boucle de message est implémentée. Pour plus d'informations, reportez-vous aux exemples de programmation dans le manuel de programmation Zookeeper pour des exemples de codes utilisant différentes API.

Exécutez zookeeper en mode de réplication

Lancer zookeeper en mode singleton est très pratique pour le développement de tests d'évaluation. Mais dans un environnement de production, vous devez exécuter en mode réplication. Le groupe de serveurs répliqués dans la même application est appelé quorum . En mode réplication, tous les serveurs ont le même fichier de configuration en quorum.

Remarque: en mode de réplication, au moins trois serveurs sont requis et il est fortement recommandé d'utiliser un nombre impair de serveurs. Si vous n'avez que deux serveurs, vous serez piégé lorsqu'un serveur tombe en panne et qu'il n'y a pas assez de machines pour générer un quorum pouvant obtenir un vote majoritaire. Deux serveurs héritent de la faible stabilité inhérente à un seul serveur, car cela entraînera deux points de défaillance uniques.

Chaque serveur zookeeper a le même fichier de configuration. Ce fichier est similaire au fichier de configuration utilisé dans le mode singleton décrit ci-dessus, à l'exception d'une petite différence, comme suit:

tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888

Le nouvel attribut, initLimit est utilisé pour définir le délai d'expiration du gardien de zoo pour se connecter au chef. L'attribut syncLimit limite le délai d' expiration d' un leader.
Pour ces deux délais, vous pouvez également spécifier l'unité de temps de tickTime à mesurer. Par exemple, initLimit est de 5 ticks, et chaque tick est de 2000 millisecondes, soit 10 secondes.
L'attribut server.X répertorie la composition du service zookeeper. Lorsque le serveur démarre, recherchez de quel serveur il s'agit en recherchant le fichier myid dans le répertoire data. Ce fichier contient le numéro de serveur encodé en ASCII.
Enfin, faites attention aux deux numéros de port après chaque nom de serveur: "2888" et "3888". Établissez une connexion les uns avec les autres via cette forme de port. Une telle connexion est nécessaire pour la communication, par exemple, lors de la mise à jour séquentielle des données. Surtout lorsque le serveur zookeeper utilise ce port pour connecter les adeptes au leader. Lorsqu'un nouveau leader est né, les abonnés ouvriront le protocole TCP pour se connecter au leader via ce numéro de port. Comme l'élection du chef par défaut utilise également le protocole tcp, nous devons exiger un autre port pour l'élection du chef. Il s'agit du deuxième numéro de port du serveur d'attributs.

Remarque: Si vous souhaitez tester plusieurs services zookeeper sur une machine, vous devez indiquer le nom de cluster unique localhost et ces ports d'élection de leader (par exemple, 2888: 3888, 2889: 3889, 2890: 3890 dans l'exemple suivant). Il est également nécessaire d'isoler chaque répertoire dataDir et différents numéros de port. (Dans cet exemple d'exécution en mode réplication, chaque exécution sur une seule machine a un fichier de configuration)
Veuillez noter que la configuration de plusieurs serveurs sur un seul ordinateur ne créera aucune redondance. Si quelque chose se produit et entraîne une panne de la machine, tous les serveurs de gardien de zoo se déconnectent. La redondance complète nécessite que chaque serveur ait sa propre machine. Il doit s'agir d'un serveur physique totalement indépendant. Plusieurs machines virtuelles sur le même hôte physique sont toujours vulnérables à la défaillance complète de l'hôte.

Autres optimisations

D'autres paramètres de configuration peuvent améliorer les performances:
-Afin de réduire les délais et les mises à jour rapides, il est important de disposer d'un répertoire dédié au journal des transactions. Le fichier journal des transactions par défaut est assemblé avec l' instantané de données et le fichier myid . Le paramètre dataLogDir peut spécifier un autre emplacement pour stocker le journal des transactions.


Je suppose que tu aimes

Origine blog.csdn.net/killingbow/article/details/53113966
conseillé
Classement