Σας προτείνω να διαβάσετε τη μεταγραφή της διάλεξης "Hadoop. ZooKeeper" από τη σειρά "Μέθοδοι για κατανεμημένη επεξεργασία μεγάλων όγκων δεδομένων στο Hadoop"
Τι είναι το ZooKeeper, η θέση του στο οικοσύστημα Hadoop. Αναλήθειες για τους κατανεμημένους υπολογιστές. Διάγραμμα ενός τυπικού κατανεμημένου συστήματος. Δυσκολία στον συντονισμό των κατανεμημένων συστημάτων. Τυπικά προβλήματα συντονισμού. Οι αρχές πίσω από το σχεδιασμό του ZooKeeper. Μοντέλο δεδομένων ZooKeeper. σημαίες znode. Συνεδρίες. Client API. Πρωτόγονα (διαμόρφωση, συμμετοχή στην ομάδα, απλά λουκέτα, εκλογή αρχηγού, κλείδωμα χωρίς αποτέλεσμα αγέλης). Αρχιτεκτονική ZooKeeper. ZooKeeper DB. ΖΑΒ. Διαχειριστής αιτημάτων.
Σήμερα θα μιλήσουμε για το ZooKeeper. Αυτό το πράγμα είναι πολύ χρήσιμο. Όπως κάθε προϊόν Apache Hadoop, έχει λογότυπο. Απεικονίζει έναν άνδρα.
Πριν από αυτό, μιλήσαμε κυρίως για το πώς μπορούν να υποβληθούν σε επεξεργασία δεδομένα εκεί, πώς να τα αποθηκεύσουμε, δηλαδή πώς να τα χρησιμοποιήσουμε και να εργαστούμε με αυτά με κάποιο τρόπο. Και σήμερα θα ήθελα να μιλήσω λίγο για τη δημιουργία κατανεμημένων εφαρμογών. Και το ZooKeeper είναι ένα από εκείνα τα πράγματα που σας επιτρέπουν να απλοποιήσετε αυτό το θέμα. Αυτό είναι ένα είδος υπηρεσίας που προορίζεται για κάποιου είδους συντονισμό της αλληλεπίδρασης των διαδικασιών σε κατανεμημένα συστήματα, σε κατανεμημένες εφαρμογές.
Η ανάγκη για τέτοιες εφαρμογές γίνεται ολοένα και μεγαλύτερη κάθε μέρα, αυτό είναι το θέμα της πορείας μας. Από τη μία πλευρά, το MapReduce και αυτό το έτοιμο πλαίσιο σάς επιτρέπει να εξομαλύνετε αυτή την πολυπλοκότητα και να απαλλάξετε τον προγραμματιστή από τη σύνταξη πρωτόγονων όπως η αλληλεπίδραση και ο συντονισμός των διαδικασιών. Αλλά από την άλλη, κανείς δεν εγγυάται ότι αυτό δεν θα χρειαστεί να γίνει ούτως ή άλλως. Το MapReduce ή άλλα έτοιμα πλαίσια δεν αντικαθιστούν πάντα πλήρως ορισμένες περιπτώσεις που δεν μπορούν να υλοποιηθούν χρησιμοποιώντας αυτό. Συμπεριλαμβανομένου του ίδιου του MapReduce και πολλών άλλων έργων Apache, στην πραγματικότητα είναι επίσης κατανεμημένες εφαρμογές. Και για να διευκολύνουν το γράψιμο, έγραψαν το ZooKeeper.
Όπως όλες οι εφαρμογές που σχετίζονται με το Hadoop, αναπτύχθηκε από την Yahoo! Είναι πλέον και επίσημη εφαρμογή Apache. Δεν έχει αναπτυχθεί τόσο ενεργά όσο το HBase. Αν πάτε στο JIRA HBase, τότε κάθε μέρα υπάρχουν ένα σωρό αναφορές σφαλμάτων, ένα σωρό προτάσεις για να βελτιστοποιήσετε κάτι, δηλαδή η ζωή στο έργο συνεχίζεται συνεχώς. Και το ZooKeeper, αφενός, είναι ένα σχετικά απλό προϊόν, και αφετέρου, αυτό εξασφαλίζει την αξιοπιστία του. Και είναι αρκετά εύκολο στη χρήση, γι' αυτό και έχει γίνει πρότυπο σε εφαρμογές στο οικοσύστημα Hadoop. Έτσι σκέφτηκα ότι θα ήταν χρήσιμο να το αναθεωρήσω για να καταλάβω πώς λειτουργεί και πώς να το χρησιμοποιήσετε.
Αυτή είναι μια εικόνα από κάποια διάλεξη που είχαμε. Μπορούμε να πούμε ότι είναι ορθογώνιο σε όλα όσα έχουμε εξετάσει μέχρι τώρα. Και όλα όσα υποδεικνύονται εδώ, στον έναν ή τον άλλο βαθμό, λειτουργούν με το ZooKeeper, δηλαδή είναι μια υπηρεσία που χρησιμοποιεί όλα αυτά τα προϊόντα. Ούτε το HDFS ούτε το MapReduce γράφουν τις δικές τους παρόμοιες υπηρεσίες που θα λειτουργούσαν ειδικά για αυτούς. Αντίστοιχα, χρησιμοποιείται το ZooKeeper. Και αυτό απλοποιεί την ανάπτυξη και ορισμένα πράγματα που σχετίζονται με λάθη.
Από πού προέρχονται όλα αυτά; Φαίνεται ότι ξεκινήσαμε δύο εφαρμογές παράλληλα σε διαφορετικούς υπολογιστές, τις συνδέσαμε με μια συμβολοσειρά ή σε ένα πλέγμα και όλα λειτουργούν. Αλλά το πρόβλημα είναι ότι το Δίκτυο είναι αναξιόπιστο και αν μυρίσετε την κίνηση ή κοιτάξετε τι συμβαίνει εκεί σε χαμηλό επίπεδο, πώς αλληλεπιδρούν οι πελάτες στο Δίκτυο, μπορείτε συχνά να δείτε ότι ορισμένα πακέτα χάνονται ή αποστέλλονται ξανά. Δεν είναι τυχαίο ότι εφευρέθηκαν πρωτόκολλα TCP, τα οποία σας επιτρέπουν να δημιουργήσετε μια συγκεκριμένη περίοδο λειτουργίας και να εγγυηθείτε την παράδοση μηνυμάτων. Αλλά σε κάθε περίπτωση, ακόμη και το TCP δεν μπορεί πάντα να σας σώσει. Όλα έχουν τάιμ άουτ. Το δίκτυο μπορεί απλά να πέσει για λίγο. Μπορεί απλώς να αναβοσβήνει. Και όλα αυτά οδηγούν στο γεγονός ότι δεν μπορείτε να βασιστείτε στο ότι το Δίκτυο είναι αξιόπιστο. Αυτή είναι η κύρια διαφορά από τη σύνταξη παράλληλων εφαρμογών που εκτελούνται σε έναν υπολογιστή ή σε έναν υπερυπολογιστή, όπου δεν υπάρχει Δίκτυο, όπου υπάρχει ένας πιο αξιόπιστος δίαυλος ανταλλαγής δεδομένων στη μνήμη. Και αυτή είναι μια θεμελιώδης διαφορά.
Μεταξύ άλλων, κατά τη χρήση του Δικτύου, υπάρχει πάντα μια ορισμένη καθυστέρηση. Το έχει και ο δίσκος, αλλά το Δίκτυο έχει περισσότερα. Η καθυστέρηση είναι κάποιος χρόνος καθυστέρησης, ο οποίος μπορεί να είναι είτε μικρός είτε αρκετά σημαντικός.
Η τοπολογία του δικτύου αλλάζει. Τι είναι η τοπολογία - αυτή είναι η τοποθέτηση του εξοπλισμού του δικτύου μας. Υπάρχουν κέντρα δεδομένων, υπάρχουν ράφια που στέκονται εκεί, υπάρχουν κεριά. Όλα αυτά μπορούν να επανασυνδεθούν, να μετακινηθούν κ.λπ. Όλα αυτά πρέπει επίσης να ληφθούν υπόψη. Τα ονόματα IP αλλάζουν, αλλάζει η δρομολόγηση μέσω της οποίας ταξιδεύει η επισκεψιμότητά μας. Αυτό πρέπει επίσης να ληφθεί υπόψη.
Το δίκτυο μπορεί επίσης να αλλάξει ως προς τον εξοπλισμό. Από την πράξη, μπορώ να πω ότι στους μηχανικούς δικτύου μας αρέσει πολύ να ενημερώνουν περιοδικά κάτι στα κεριά. Ξαφνικά βγήκε ένα νέο υλικολογισμικό και δεν τους ενδιέφερε ιδιαίτερα κάποιο σύμπλεγμα Hadoop. Έχουν τη δική τους δουλειά. Για αυτούς, το κύριο πράγμα είναι ότι το Δίκτυο λειτουργεί. Αντίστοιχα, θέλουν να ανεβάσουν ξανά κάτι εκεί, να κάνουν ένα φλας στο υλικό τους και το υλικό αλλάζει επίσης περιοδικά. Όλα αυτά με κάποιο τρόπο πρέπει να ληφθούν υπόψη. Όλα αυτά επηρεάζουν την κατανεμημένη εφαρμογή μας.
Συνήθως οι άνθρωποι που αρχίζουν να εργάζονται με μεγάλες ποσότητες δεδομένων για κάποιο λόγο πιστεύουν ότι το Διαδίκτυο είναι απεριόριστο. Εάν υπάρχει ένα αρχείο πολλών terabyte εκεί, τότε μπορείτε να το μεταφέρετε στον διακομιστή ή στον υπολογιστή σας και να το ανοίξετε χρησιμοποιώντας πως και δες. Υπάρχει ένα άλλο σφάλμα ζωτικότητα κοιτάξτε τα κούτσουρα. Μην το κάνετε ποτέ αυτό γιατί είναι κακό. Επειδή το Vim προσπαθεί να αποθηκεύσει τα πάντα στην προσωρινή μνήμη, να φορτώσει τα πάντα στη μνήμη, ειδικά όταν αρχίζουμε να κινούμαστε μέσα από αυτό το αρχείο καταγραφής και να ψάχνουμε για κάτι. Αυτά είναι πράγματα που ξεχνιούνται, αλλά αξίζει να τα εξετάσουμε.
Είναι πιο εύκολο να γράψετε ένα πρόγραμμα που εκτελείται σε έναν υπολογιστή με έναν επεξεργαστή.
Όταν το σύστημά μας μεγαλώνει, θέλουμε να τα παραλληλίσουμε όλα και να τα παραλληλίσουμε όχι μόνο σε έναν υπολογιστή, αλλά και σε ένα σύμπλεγμα. Τίθεται το ερώτημα: πώς να συντονιστεί αυτό το θέμα; Οι εφαρμογές μας μπορεί να μην αλληλεπιδρούν καν μεταξύ τους, αλλά εκτελέσαμε πολλές διεργασίες παράλληλα σε πολλούς διακομιστές. Και πώς να παρακολουθούν ότι όλα πάνε καλά για αυτούς; Για παράδειγμα, στέλνουν κάτι μέσω Διαδικτύου. Πρέπει να γράψουν για την κατάστασή τους κάπου, για παράδειγμα, σε κάποιο είδος βάσης δεδομένων ή αρχείο καταγραφής, μετά να συγκεντρώσουν αυτό το αρχείο καταγραφής και μετά να το αναλύσουν κάπου. Επιπλέον, πρέπει να λάβουμε υπόψη ότι η διαδικασία δούλευε και λειτουργούσε, ξαφνικά εμφανίστηκε κάποιο σφάλμα ή συνετρίβη, τότε πόσο γρήγορα θα το μάθουμε;
Είναι σαφές ότι όλα αυτά μπορούν να παρακολουθηθούν γρήγορα. Αυτό είναι επίσης καλό, αλλά η παρακολούθηση είναι ένα περιορισμένο πράγμα που σας επιτρέπει να παρακολουθείτε ορισμένα πράγματα στο υψηλότερο επίπεδο.
Όταν θέλουμε οι διαδικασίες μας να αρχίσουν να αλληλεπιδρούν μεταξύ τους, για παράδειγμα, να στέλνουν η μία στην άλλη κάποια δεδομένα, τότε τίθεται επίσης το ερώτημα - πώς θα συμβεί αυτό; Θα υπάρξει κάποια συνθήκη αγώνα, θα αντικατασταθούν μεταξύ τους, θα φτάσουν σωστά τα δεδομένα, θα χαθεί κάτι στην πορεία; Πρέπει να αναπτύξουμε κάποιο είδος πρωτοκόλλου κ.λπ.
Ο συντονισμός όλων αυτών των διαδικασιών δεν είναι κάτι ασήμαντο. Και αναγκάζει τον προγραμματιστή να κατέβει σε ακόμα χαμηλότερο επίπεδο και να γράψει συστήματα είτε από την αρχή είτε όχι από την αρχή, αλλά αυτό δεν είναι τόσο απλό.
Εάν καταλήξετε σε έναν κρυπτογραφικό αλγόριθμο ή ακόμα και τον εφαρμόσετε, τότε πετάξτε τον αμέσως, γιατί πιθανότατα δεν θα σας κάνει καλό. Πιθανότατα θα περιέχει ένα σωρό λάθη που ξεχάσατε να παρέχετε. Μην το χρησιμοποιείτε ποτέ για κάτι σοβαρό γιατί πιθανότατα θα είναι ασταθές. Γιατί όλοι οι αλγόριθμοι που υπάρχουν έχουν δοκιμαστεί από το χρόνο για πάρα πολύ καιρό. Παρατηρείται από την κοινότητα. Αυτό είναι ένα ξεχωριστό θέμα. Και εδώ είναι το ίδιο. Εάν είναι δυνατό να μην εφαρμόσετε μόνοι σας κάποιο είδος συγχρονισμού διεργασιών, τότε είναι καλύτερα να μην το κάνετε αυτό, γιατί είναι αρκετά περίπλοκο και σας οδηγεί στο ασταθές μονοπάτι της συνεχούς αναζήτησης σφαλμάτων.
Σήμερα μιλάμε για το ZooKeeper. Αφενός, είναι ένα πλαίσιο, αφετέρου, είναι μια υπηρεσία που διευκολύνει τη ζωή του προγραμματιστή και απλοποιεί την εφαρμογή της λογικής και τον συντονισμό των διαδικασιών μας όσο το δυνατόν περισσότερο.
Ας θυμηθούμε πώς μπορεί να μοιάζει ένα τυπικό κατανεμημένο σύστημα. Αυτό είναι που μιλήσαμε - HDFS, HBase. Υπάρχει μια διαδικασία Master που διαχειρίζεται τους εργάτες και τις υποτελείς διαδικασίες. Είναι υπεύθυνος για το συντονισμό και τη διανομή εργασιών, την επανεκκίνηση των εργαζομένων, την έναρξη νέων και τη διανομή του φορτίου.
Ένα πιο προηγμένο πράγμα είναι η Υπηρεσία Συντονισμού, δηλαδή η μεταφορά της ίδιας της εργασίας συντονισμού σε μια ξεχωριστή διαδικασία, καθώς και η εκτέλεση κάποιου είδους αντιγράφων ασφαλείας ή αναμονής Master παράλληλα, επειδή το Master μπορεί να αποτύχει. Και αν πέσει ο Δάσκαλος, τότε το σύστημά μας δεν θα λειτουργήσει. Εκτελούμε αντίγραφα ασφαλείας. Ορισμένες δηλώνουν ότι το Master πρέπει να αναπαραχθεί σε αντίγραφο ασφαλείας. Αυτό μπορεί επίσης να ανατεθεί στην Υπηρεσία Συντονισμού. Αλλά σε αυτό το διάγραμμα, ο ίδιος ο Δάσκαλος είναι υπεύθυνος για τον συντονισμό των εργαζομένων εδώ η υπηρεσία συντονίζει τις δραστηριότητες αναπαραγωγής δεδομένων.
Μια πιο προηγμένη επιλογή είναι όταν όλος ο συντονισμός γίνεται από την υπηρεσία μας, όπως γίνεται συνήθως. Αναλαμβάνει την ευθύνη να διασφαλίσει ότι όλα λειτουργούν. Και αν κάτι δεν λειτουργεί, το μαθαίνουμε και προσπαθούμε να ξεπεράσουμε αυτήν την κατάσταση. Σε κάθε περίπτωση, μας μένει ένας Master που κατά κάποιο τρόπο αλληλεπιδρά με σκλάβους και μπορεί να στείλει δεδομένα, πληροφορίες, μηνύματα κ.λπ. μέσω κάποιας υπηρεσίας.
Υπάρχει ένα ακόμη πιο προηγμένο σχήμα, όταν δεν έχουμε Master, όλοι οι κόμβοι είναι master slaves, διαφορετικοί στη συμπεριφορά τους. Αλλά εξακολουθούν να χρειάζονται αλληλεπίδραση μεταξύ τους, επομένως απομένει κάποια υπηρεσία για τον συντονισμό αυτών των ενεργειών. Πιθανώς, η Κασσάνδρα, που λειτουργεί με αυτήν την αρχή, ταιριάζει σε αυτό το σχήμα.
Είναι δύσκολο να πούμε ποιο από αυτά τα σχήματα λειτουργεί καλύτερα. Το καθένα έχει τα δικά του πλεονεκτήματα και μειονεκτήματα.
Και δεν χρειάζεται να φοβάστε κάποια πράγματα με τον Δάσκαλο, γιατί, όπως δείχνει η πρακτική, δεν είναι τόσο επιρρεπής στο να υπηρετεί συνεχώς. Το κύριο πράγμα εδώ είναι να επιλέξετε τη σωστή λύση για τη φιλοξενία αυτής της υπηρεσίας σε έναν ξεχωριστό ισχυρό κόμβο, έτσι ώστε να έχει αρκετούς πόρους, ώστε αν είναι δυνατόν, οι χρήστες να μην έχουν πρόσβαση εκεί, ώστε να μην σκοτώσουν κατά λάθος αυτή τη διαδικασία. Αλλά ταυτόχρονα, σε ένα τέτοιο σχήμα είναι πολύ πιο εύκολο να διαχειριστείτε τους εργαζόμενους από τη διαδικασία Master, δηλαδή αυτό το σχήμα είναι απλούστερο από την άποψη της εφαρμογής.
Και αυτό το σχήμα (παραπάνω) είναι πιθανώς πιο περίπλοκο, αλλά πιο αξιόπιστο.
Το κύριο πρόβλημα είναι μερικές αποτυχίες. Για παράδειγμα, όταν στέλνουμε ένα μήνυμα μέσω του Δικτύου, συμβαίνει κάποιο είδος ατυχήματος και αυτός που έστειλε το μήνυμα δεν θα γνωρίζει εάν το μήνυμά του ελήφθη και τι συνέβη από την πλευρά του παραλήπτη, δεν θα γνωρίζει εάν το μήνυμα υποβλήθηκε σε επεξεργασία σωστά , δηλαδή δεν θα λάβει καμία επιβεβαίωση.
Κατά συνέπεια, πρέπει να επεξεργαστούμε αυτήν την κατάσταση. Και το πιο απλό είναι να στείλουμε ξανά αυτό το μήνυμα και να περιμένουμε μέχρι να λάβουμε απάντηση. Σε αυτή την περίπτωση, δεν λαμβάνεται υπόψη εάν έχει αλλάξει η κατάσταση του δέκτη. Ενδέχεται να στείλουμε ένα μήνυμα και να προσθέσουμε τα ίδια δεδομένα δύο φορές.
Το ZooKeeper προσφέρει τρόπους αντιμετώπισης τέτοιων αρνήσεων, γεγονός που κάνει τη ζωή μας πιο εύκολη.
Όπως αναφέρθηκε λίγο νωρίτερα, αυτό μοιάζει με τη σύνταξη προγραμμάτων πολλαπλών νημάτων, αλλά η κύρια διαφορά είναι ότι σε κατανεμημένες εφαρμογές που χτίζουμε σε διαφορετικά μηχανήματα, ο μόνος τρόπος επικοινωνίας είναι το Δίκτυο. Ουσιαστικά, αυτή είναι μια κοινή αρχιτεκτονική του τίποτα. Κάθε διεργασία ή υπηρεσία που εκτελείται σε ένα μηχάνημα έχει τη δική της μνήμη, τον δικό της δίσκο, τον δικό της επεξεργαστή, τον οποίο δεν μοιράζεται με κανέναν.
Εάν γράψουμε ένα πρόγραμμα πολλαπλών νημάτων σε έναν υπολογιστή, τότε μπορούμε να χρησιμοποιήσουμε κοινόχρηστη μνήμη για την ανταλλαγή δεδομένων. Έχουμε έναν διακόπτη περιβάλλοντος εκεί, οι διαδικασίες μπορούν να αλλάξουν. Αυτό επηρεάζει την απόδοση. Από τη μία, δεν υπάρχει κάτι τέτοιο στο πρόγραμμα σε ένα σύμπλεγμα, αλλά υπάρχουν προβλήματα με το Δίκτυο.
Κατά συνέπεια, τα κύρια προβλήματα που προκύπτουν κατά την εγγραφή κατανεμημένων συστημάτων είναι η διαμόρφωση. Γράφουμε κάποιου είδους αίτηση. Αν είναι απλό, τότε κωδικοποιούμε όλα τα είδη αριθμών στον κώδικα, αλλά αυτό είναι άβολο, γιατί αν αποφασίσουμε ότι αντί για χρονικό όριο μισού δευτερολέπτου θέλουμε ένα χρονικό όριο ενός δευτερολέπτου, τότε πρέπει να μεταγλωττίσουμε ξανά την εφαρμογή και ξεδιπλώστε τα πάντα ξανά. Είναι ένα πράγμα όταν είναι σε ένα μηχάνημα, όταν μπορείτε απλώς να το επανεκκινήσετε, αλλά όταν έχουμε πολλά μηχανήματα, πρέπει να αντιγράφουμε συνεχώς τα πάντα. Πρέπει να προσπαθήσουμε να κάνουμε την εφαρμογή διαμορφώσιμη.
Εδώ μιλάμε για στατική διαμόρφωση για διεργασίες συστήματος. Αυτό δεν είναι εξ ολοκλήρου, ίσως από την άποψη του λειτουργικού συστήματος, μπορεί να είναι μια στατική διαμόρφωση για τις διεργασίες μας, δηλαδή πρόκειται για μια διαμόρφωση που δεν μπορεί απλά να ληφθεί και να ενημερωθεί.
Υπάρχει επίσης μια δυναμική διαμόρφωση. Αυτές είναι οι παράμετροι που θέλουμε να αλλάξουμε εν κινήσει, ώστε να συλλέγονται εκεί.
Ποιο είναι το πρόβλημα εδώ; Ενημερώσαμε τις ρυθμίσεις παραμέτρων, τις παρουσιάσαμε, και τι; Το πρόβλημα μπορεί να είναι ότι από τη μια μεριά κυκλοφόρησε το config, αλλά ξεχάσαμε το νέο πράγμα, το config παρέμεινε εκεί. Δεύτερον, ενώ κυκλοφορούσαμε, η διαμόρφωση ενημερώθηκε σε ορισμένα σημεία, αλλά όχι σε άλλα. Και μερικές διεργασίες της εφαρμογής μας που εκτελούνται σε ένα μηχάνημα επανεκκινήθηκαν με μια νέα διαμόρφωση και κάπου με μια παλιά. Αυτό μπορεί να έχει ως αποτέλεσμα η κατανεμημένη εφαρμογή μας να είναι ασυνεπής από άποψη διαμόρφωσης. Αυτό το πρόβλημα είναι κοινό. Για μια δυναμική διαμόρφωση, είναι πιο συναφής επειδή υπονοεί ότι μπορεί να αλλάξει αμέσως.
Ένα άλλο πρόβλημα είναι η συμμετοχή στην ομάδα. Έχουμε πάντα κάποιο σύνολο εργατών, πάντα θέλουμε να ξέρουμε ποιος από αυτούς είναι ζωντανός, ποιος από αυτούς είναι νεκρός. Εάν υπάρχει Master, τότε πρέπει να καταλάβει ποιοι εργαζόμενοι μπορούν να ανακατευθυνθούν σε πελάτες ώστε να εκτελούν υπολογισμούς ή να εργάζονται με δεδομένα και ποιοι όχι. Ένα πρόβλημα που προκύπτει συνεχώς είναι ότι πρέπει να γνωρίζουμε ποιος εργάζεται στο cluster μας.
Ένα άλλο τυπικό πρόβλημα είναι οι εκλογές αρχηγών, όταν θέλουμε να μάθουμε ποιος είναι επικεφαλής. Ένα παράδειγμα είναι η αναπαραγωγή, όταν έχουμε κάποια διεργασία που λαμβάνει λειτουργίες εγγραφής και στη συνέχεια τις αναπαράγει μεταξύ άλλων διεργασιών. Αυτός θα είναι ο αρχηγός, όλοι οι άλλοι θα τον υπακούουν, θα τον ακολουθούν. Είναι απαραίτητο να επιλέξετε μια διαδικασία ώστε να είναι ξεκάθαρη για όλους, ώστε να μην αποδειχθεί ότι επιλέγονται δύο αρχηγοί.
Υπάρχει επίσης αμοιβαία αποκλειστική πρόσβαση. Το πρόβλημα εδώ είναι πιο σύνθετο. Υπάρχει ένα τέτοιο πράγμα όπως το mutex, όταν γράφετε προγράμματα πολλαπλών νημάτων και θέλετε η πρόσβαση σε κάποιον πόρο, για παράδειγμα, ένα κελί μνήμης, να περιορίζεται και να εκτελείται μόνο από ένα νήμα. Εδώ ο πόρος θα μπορούσε να είναι κάτι πιο αφηρημένο. Και διαφορετικές εφαρμογές από διαφορετικούς κόμβους του Δικτύου μας θα πρέπει να έχουν αποκλειστική πρόσβαση μόνο σε έναν δεδομένο πόρο και όχι για να μπορούν όλοι να τον αλλάξουν ή να γράψουν κάτι εκεί. Αυτές είναι οι λεγόμενες κλειδαριές.
Το ZooKeeper σάς επιτρέπει να λύσετε όλα αυτά τα προβλήματα στον ένα ή τον άλλο βαθμό. Και θα δείξω με παραδείγματα πώς σας επιτρέπει να το κάνετε αυτό.
Δεν υπάρχουν πρωτόγονοι αποκλεισμού. Όταν αρχίζουμε να χρησιμοποιούμε κάτι, αυτό το πρωτόγονο δεν θα περιμένει να συμβεί κάποιο γεγονός. Πιθανότατα, αυτό το πράγμα θα λειτουργεί ασύγχρονα, επιτρέποντας έτσι στις διαδικασίες να μην κολλάνε ενώ περιμένουν κάτι. Αυτό είναι πολύ χρήσιμο πράγμα.
Όλα τα αιτήματα πελατών υποβάλλονται σε επεξεργασία με τη σειρά της γενικής ουράς.
Και οι πελάτες έχουν την ευκαιρία να λαμβάνουν ειδοποίηση για αλλαγές σε κάποια κατάσταση, για αλλαγές στα δεδομένα, προτού ο πελάτης δει ο ίδιος τα αλλαγμένα δεδομένα.
Το ZooKeeper μπορεί να λειτουργήσει σε δύο λειτουργίες. Η πρώτη είναι αυτόνομη, σε έναν μόνο κόμβο. Αυτό είναι βολικό για δοκιμές. Μπορεί επίσης να λειτουργήσει σε λειτουργία συμπλέγματος, σε οποιονδήποτε αριθμό κόμβων. διακομιστέςΑν έχουμε ένα σύμπλεγμα 100 μηχανημάτων, δεν χρειάζεται απαραίτητα να εκτελείται σε 100 μηχανήματα. Αρκεί να διαθέσουμε μερικά μηχανήματα όπου μπορεί να εκτελεστεί το ZooKeeper. Και τηρεί την αρχή της υψηλής διαθεσιμότητας. Το ZooKeeper αποθηκεύει ένα πλήρες αντίγραφο των δεδομένων σε κάθε εκτελούμενη παρουσία. Θα εξηγήσω πώς το κάνει αυτό αργότερα. Δεν κατακερματίζει ούτε διαμερίζει τα δεδομένα. Από τη μία πλευρά, αυτό είναι ένα μειονέκτημα επειδή δεν μπορούμε να αποθηκεύσουμε πολλά, αλλά από την άλλη πλευρά, είναι περιττό. Δεν έχει σχεδιαστεί για αυτό. Δεν είναι βάση δεδομένων.
Τα δεδομένα μπορούν να αποθηκευτούν στην κρυφή μνήμη στην πλευρά του πελάτη. Αυτή είναι μια τυπική αρχή, ώστε να μην διακόπτουμε την υπηρεσία και να μην τη φορτώνουμε με τα ίδια αιτήματα. Ένας έξυπνος πελάτης συνήθως το γνωρίζει αυτό και το αποθηκεύει στην κρυφή μνήμη.
Για παράδειγμα, κάτι έχει αλλάξει εδώ. Υπάρχει κάποιο είδος εφαρμογής. Εκλέχθηκε νέος αρχηγός, ο οποίος είναι υπεύθυνος, για παράδειγμα, για την επεξεργασία των λειτουργιών εγγραφής. Και θέλουμε να αναπαράγουμε τα δεδομένα. Μια λύση είναι να το βάλεις σε βρόχο. Και συνεχώς αμφισβητούμε την υπηρεσία μας - έχει αλλάξει κάτι; Η δεύτερη επιλογή είναι πιο βέλτιστη. Αυτός είναι ένας μηχανισμός ρολογιού που σας επιτρέπει να ειδοποιείτε τους πελάτες ότι κάτι έχει αλλάξει. Αυτή είναι μια λιγότερο δαπανηρή μέθοδος από άποψη πόρων και πιο βολική για τους πελάτες.
Πελάτης είναι ο χρήστης που χρησιμοποιεί το ZooKeeper.
Ο διακομιστής είναι η ίδια η διαδικασία ZooKeeper.
Το Znode είναι το βασικό στοιχείο στο ZooKeeper. Όλα τα znodes αποθηκεύονται στη μνήμη από το ZooKeeper και οργανώνονται με τη μορφή ιεραρχικού διαγράμματος, σε μορφή δέντρου.
Υπάρχουν δύο είδη λειτουργιών. Το πρώτο είναι ενημέρωση/εγγραφή, όταν κάποια λειτουργία αλλάζει την κατάσταση του δέντρου μας. Το δέντρο είναι κοινό.
Και είναι πιθανό ο πελάτης να μην ολοκληρώσει ένα αίτημα και να αποσυνδεθεί, αλλά να δημιουργήσει μια περίοδο λειτουργίας μέσω της οποίας αλληλεπιδρά με το ZooKeeper.
Το μοντέλο δεδομένων του ZooKeeper μοιάζει με σύστημα αρχείων. Υπάρχει μια τυπική ρίζα και μετά περάσαμε σαν από τους καταλόγους που περνούν από τη ρίζα. Και μετά ο κατάλογος του πρώτου επιπέδου, δεύτερου επιπέδου. Όλα αυτά είναι znodes.
Κάθε znode μπορεί να αποθηκεύσει ορισμένα δεδομένα, συνήθως όχι πολύ μεγάλα, για παράδειγμα, 10 kilobyte. Και κάθε znode μπορεί να έχει έναν ορισμένο αριθμό παιδιών.
Τα Znodes διατίθενται σε διάφορους τύπους. Μπορούν να δημιουργηθούν. Και κατά τη δημιουργία ενός znode, καθορίζουμε τον τύπο στον οποίο πρέπει να ανήκει.
Υπάρχουν δύο τύποι. Το πρώτο είναι η εφήμερη σημαία. Το Znode ζει μέσα σε μια συνεδρία. Για παράδειγμα, ο πελάτης έχει δημιουργήσει μια περίοδο λειτουργίας. Και όσο αυτή η συνεδρία είναι ζωντανή, θα υπάρχει. Αυτό είναι απαραίτητο για να μην παραχθεί κάτι περιττό. Αυτό είναι επίσης κατάλληλο για στιγμές που είναι σημαντικό για εμάς να αποθηκεύουμε πρωτόγονα δεδομένα σε μια περίοδο λειτουργίας.
Ο δεύτερος τύπος είναι η διαδοχική σημαία. Αυξάνει τον μετρητή στο δρόμο προς το znode. Για παράδειγμα, είχαμε έναν κατάλογο με την εφαρμογή 1_5. Και όταν δημιουργήσαμε τον πρώτο κόμβο, έλαβε p_1, ο δεύτερος - p_2. Και όταν καλούμε αυτή τη μέθοδο κάθε φορά, περνάμε την πλήρη διαδρομή, υποδεικνύοντας μόνο μέρος της διαδρομής, και αυτός ο αριθμός αυξάνεται αυτόματα επειδή υποδεικνύουμε τον τύπο κόμβου - διαδοχικά.
Κανονικό znode. Θα ζει πάντα και θα έχει το όνομα που της λέμε.
Ένα άλλο χρήσιμο πράγμα είναι η σημαία του ρολογιού. Αν το εγκαταστήσουμε, τότε ο πελάτης μπορεί να εγγραφεί σε κάποια συμβάντα για έναν συγκεκριμένο κόμβο. Θα σας δείξω αργότερα με ένα παράδειγμα πώς γίνεται αυτό. Το ίδιο το ZooKeeper ειδοποιεί τον πελάτη ότι τα δεδομένα στον κόμβο έχουν αλλάξει. Ωστόσο, οι ειδοποιήσεις δεν εγγυώνται την άφιξη ορισμένων νέων δεδομένων. Λένε απλώς ότι κάτι έχει αλλάξει, επομένως πρέπει να συγκρίνετε τα δεδομένα αργότερα με ξεχωριστές κλήσεις.
Και όπως είπα ήδη, η σειρά των δεδομένων καθορίζεται από kilobyte. Δεν χρειάζεται να αποθηκεύονται μεγάλα δεδομένα κειμένου εκεί, γιατί δεν είναι βάση δεδομένων, είναι διακομιστής συντονισμού ενεργειών.
Επιτρέψτε μου να σας πω λίγα πράγματα για τις συνεδρίες. Αν έχουμε πολλούς διακομιστές, μπορούμε να μεταβούμε εύκολα από τον έναν διακομιστή στον άλλο. υπηρέτης, χρησιμοποιώντας το αναγνωριστικό περιόδου σύνδεσης. Αυτό είναι αρκετά βολικό.
Κάθε συνεδρία έχει κάποιου είδους timeout. Μια περίοδος λειτουργίας ορίζεται από το εάν ο πελάτης στέλνει οτιδήποτε στον διακομιστή κατά τη διάρκεια αυτής της περιόδου λειτουργίας. Εάν δεν μετέδωσε τίποτα κατά τη διάρκεια του χρονικού ορίου, η συνεδρία πέφτει ή ο πελάτης μπορεί να την κλείσει μόνος του.
Δεν έχει τόσες πολλές δυνατότητες, αλλά μπορείτε να κάνετε διαφορετικά πράγματα με αυτό το API. Αυτή η κλήση που είδαμε να δημιουργείται δημιουργεί ένα znode και παίρνει τρεις παραμέτρους. Αυτή είναι η διαδρομή προς το znode και πρέπει να καθοριστεί πλήρως από τη ρίζα. Και επίσης αυτά είναι μερικά δεδομένα που θέλουμε να μεταφέρουμε εκεί. Και το είδος της σημαίας. Και μετά τη δημιουργία επιστρέφει τη διαδρομή προς το znode.
Δεύτερον, μπορείτε να το διαγράψετε. Το κόλπο εδώ είναι ότι η δεύτερη παράμετρος, εκτός από τη διαδρομή προς το znode, μπορεί να καθορίσει την έκδοση. Κατά συνέπεια, αυτό το znode θα διαγραφεί εάν η έκδοσή του που μεταφέραμε είναι ισοδύναμη με αυτή που υπάρχει στην πραγματικότητα.
Εάν δεν θέλουμε να ελέγξουμε αυτήν την έκδοση, τότε απλώς περνάμε το όρισμα "-1".
Τρίτον, ελέγχει την ύπαρξη znode. Επιστρέφει true εάν υπάρχει ο κόμβος, false διαφορετικά.
Και στη συνέχεια εμφανίζεται το ρολόι σημαίας, το οποίο σας επιτρέπει να παρακολουθείτε αυτόν τον κόμβο.
Μπορείτε να ορίσετε αυτήν τη σημαία ακόμη και σε έναν ανύπαρκτο κόμβο και να λάβετε μια ειδοποίηση όταν εμφανιστεί. Αυτό μπορεί επίσης να είναι χρήσιμο.
Υπάρχουν μερικές ακόμη προκλήσεις getData. Είναι σαφές ότι μπορούμε να λάβουμε δεδομένα μέσω znode. Μπορείτε επίσης να χρησιμοποιήσετε το ρολόι σημαίας. Σε αυτήν την περίπτωση, δεν θα εγκατασταθεί εάν δεν υπάρχει κόμβος. Επομένως, πρέπει να καταλάβετε ότι υπάρχει και στη συνέχεια να λάβετε δεδομένα.
Υπάρχει επίσης SetData. Εδώ περνάμε την έκδοση. Και αν το μεταδώσουμε, τα δεδομένα για το znode μιας συγκεκριμένης έκδοσης θα ενημερωθούν.
Μπορείτε επίσης να καθορίσετε "-1" για να εξαιρέσετε αυτόν τον έλεγχο.
Μια άλλη χρήσιμη μέθοδος είναι getChildren. Μπορούμε επίσης να λάβουμε μια λίστα με όλα τα znode που ανήκουν σε αυτό. Μπορούμε να το παρακολουθήσουμε ρυθμίζοντας το ρολόι σημαίας.
Και μέθοδος συγχρονισμό επιτρέπει την αποστολή όλων των αλλαγών ταυτόχρονα, διασφαλίζοντας έτσι ότι έχουν αποθηκευτεί και ότι όλα τα δεδομένα έχουν αλλάξει πλήρως.
Εάν σχεδιάσουμε αναλογίες με τον συμβατικό προγραμματισμό, τότε όταν χρησιμοποιείτε μεθόδους όπως η εγγραφή, που γράφουν κάτι στο δίσκο, και αφού σας επιστρέψει μια απάντηση, δεν υπάρχει καμία εγγύηση ότι έχετε γράψει τα δεδομένα στο δίσκο. Και ακόμη και όταν το λειτουργικό σύστημα είναι βέβαιο ότι όλα έχουν γραφτεί, υπάρχουν μηχανισμοί στον ίδιο τον δίσκο όπου η διαδικασία περνά μέσα από στρώματα buffer και μόνο μετά από αυτό τα δεδομένα τοποθετούνται στο δίσκο.
Χρησιμοποιούνται κυρίως ασύγχρονες κλήσεις. Αυτό επιτρέπει στον πελάτη να εργάζεται παράλληλα με διαφορετικά αιτήματα. Μπορείτε να χρησιμοποιήσετε τη σύγχρονη προσέγγιση, αλλά είναι λιγότερο παραγωγική.
Οι δύο λειτουργίες για τις οποίες μιλήσαμε είναι η ενημέρωση/εγγραφή, που αλλάζουν δεδομένα. Αυτά είναι δημιουργία, setData, συγχρονισμός, διαγραφή. Και το read is exists, getData, getChildren.
Τώρα μερικά παραδείγματα για το πώς μπορείτε να δημιουργήσετε πρωτόγονα για εργασία σε ένα κατανεμημένο σύστημα. Για παράδειγμα, σχετίζεται με τη διαμόρφωση κάποιου πράγματος. Ένας νέος εργαζόμενος εμφανίστηκε. Προσθέσαμε το μηχάνημα και ξεκινήσαμε τη διαδικασία. Και υπάρχουν οι ακόλουθες τρεις ερωτήσεις. Πώς ζητά τη διαμόρφωση του ZooKeeper; Και αν θέλουμε να αλλάξουμε τη διαμόρφωση, πώς την αλλάξουμε; Και αφού το αλλάξαμε, πώς το παίρνουν αυτοί οι εργάτες που είχαμε;
Το ZooKeeper το κάνει σχετικά εύκολο. Για παράδειγμα, υπάρχει το δέντρο znode μας. Υπάρχει ένας κόμβος για την εφαρμογή μας εδώ, δημιουργούμε έναν επιπλέον κόμβο σε αυτόν, ο οποίος περιέχει δεδομένα από τη διαμόρφωση. Αυτές μπορεί να είναι ή να μην είναι ξεχωριστές παράμετροι. Δεδομένου ότι το μέγεθος είναι μικρό, το μέγεθος της διαμόρφωσης είναι συνήθως επίσης μικρό, επομένως είναι πολύ πιθανό να το αποθηκεύσετε εδώ.
Χρησιμοποιείτε τη μέθοδο getData για να λάβετε τη διαμόρφωση για τον εργαζόμενο από τον κόμβο. Ορίστηκε σε true. Εάν για κάποιο λόγο δεν υπάρχει αυτός ο κόμβος, θα ενημερωθούμε σχετικά όταν εμφανιστεί, ή όταν αλλάξει. Αν θέλουμε να ξέρουμε ότι κάτι έχει αλλάξει, τότε το ορίζουμε σε true. Και αν αλλάξουν τα δεδομένα σε αυτόν τον κόμβο, θα το γνωρίζουμε.
SetData. Ορίζουμε τα δεδομένα, ορίζουμε "-1", δηλαδή δεν ελέγχουμε την έκδοση, υποθέτουμε ότι έχουμε πάντα μία διαμόρφωση, δεν χρειάζεται να αποθηκεύσουμε πολλές διαμορφώσεις. Εάν χρειάζεται να αποθηκεύσετε πολλά, θα χρειαστεί να προσθέσετε ένα άλλο επίπεδο. Εδώ πιστεύουμε ότι υπάρχει μόνο ένα, επομένως ενημερώνουμε μόνο την πιο πρόσφατη, ώστε να μην ελέγχουμε την έκδοση. Αυτή τη στιγμή, όλοι οι πελάτες που έχουν εγγραφεί στο παρελθόν λαμβάνουν μια ειδοποίηση ότι κάτι έχει αλλάξει σε αυτόν τον κόμβο. Και αφού το παραλάβουν, πρέπει επίσης να ζητήσουν ξανά τα στοιχεία. Η ειδοποίηση είναι ότι δεν λαμβάνουν τα ίδια τα δεδομένα, αλλά μόνο ειδοποίηση αλλαγών. Μετά από αυτό πρέπει να ζητήσουν νέα δεδομένα.
Η δεύτερη επιλογή για τη χρήση του πρωτόγονου είναι μέλος της ομάδας. Έχουμε μια κατανεμημένη εφαρμογή, υπάρχουν ένα σωρό εργαζόμενοι και θέλουμε να καταλάβουμε ότι είναι όλοι στη θέση τους. Επομένως, πρέπει να δηλώσουν οι ίδιοι ότι εργάζονται στην αίτησή μας. Και θέλουμε επίσης να μάθουμε, είτε από τη διαδικασία Master είτε κάπου αλλού, για όλους τους ενεργούς εργαζόμενους που έχουμε αυτήν τη στιγμή.
Πώς το κάνουμε αυτό; Για την εφαρμογή, δημιουργούμε έναν κόμβο εργαζομένων και προσθέτουμε ένα υποεπίπεδο εκεί χρησιμοποιώντας τη μέθοδο δημιουργίας. Έχω ένα σφάλμα στη διαφάνεια. Εδώ χρειάζεστε διαδοχική καθορίστε, τότε όλοι οι εργαζόμενοι θα δημιουργηθούν ένας προς έναν. Και η εφαρμογή, ζητώντας όλα τα δεδομένα για τα παιδιά αυτού του κόμβου, λαμβάνει όλους τους ενεργούς εργαζόμενους που υπάρχουν.
Αυτή είναι μια τρομερή εφαρμογή του πώς μπορεί να γίνει αυτό σε κώδικα Java. Ας ξεκινήσουμε από το τέλος, με την κύρια μέθοδο. Αυτή είναι η τάξη μας, ας δημιουργήσουμε τη μέθοδο της. Ως πρώτο όρισμα χρησιμοποιούμε τον κεντρικό υπολογιστή, όπου συνδέουμε, δηλαδή το ορίζουμε ως όρισμα. Και το δεύτερο επιχείρημα είναι το όνομα της ομάδας.
Πώς γίνεται η σύνδεση; Αυτό είναι ένα απλό παράδειγμα του API που χρησιμοποιείται. Όλα είναι σχετικά απλά εδώ. Υπάρχει μια τυπική κατηγορία ZooKeeper. Περνάμε οικοδεσπότες σε αυτό. Και ρυθμίστε το χρονικό όριο, για παράδειγμα, στα 5 δευτερόλεπτα. Και έχουμε ένα μέλος που ονομάζεται connectSignal. Ουσιαστικά, δημιουργούμε μια ομάδα κατά μήκος της διαδρομής μετάδοσης. Δεν γράφουμε δεδομένα εκεί, αν και κάτι θα μπορούσε να είχε γραφτεί. Και ο κόμβος εδώ είναι μόνιμος τύπος. Ουσιαστικά, αυτός είναι ένας συνηθισμένος κανονικός κόμβος που θα υπάρχει όλη την ώρα. Εδώ δημιουργείται η συνεδρία. Αυτή είναι η υλοποίηση του ίδιου του πελάτη. Ο πελάτης μας θα αναφέρει περιοδικά ότι η συνεδρία είναι ζωντανή. Και όταν τελειώνουμε τη συνεδρία, καλούμε κλείσιμο και τέλος, η συνεδρία πέφτει. Αυτό σε περίπτωση που μας πέσει κάτι, ώστε το ZooKeeper να το μάθει και να διακόψει τη συνεδρία.
Πώς να κλειδώσετε έναν πόρο; Εδώ όλα είναι λίγο πιο περίπλοκα. Έχουμε ένα σύνολο εργαζομένων, υπάρχει κάποιος πόρος που θέλουμε να κλειδώσουμε. Για να γίνει αυτό, δημιουργούμε έναν ξεχωριστό κόμβο, για παράδειγμα, που ονομάζεται lock1. Αν μπορούσαμε να το δημιουργήσουμε, τότε είχαμε μια κλειδαριά εδώ. Και αν δεν μπορέσαμε να το δημιουργήσουμε, τότε ο εργάτης προσπαθεί να πάρει το getData από εδώ, και αφού ο κόμβος έχει ήδη δημιουργηθεί, τότε βάζουμε έναν παρατηρητή εδώ και τη στιγμή που αλλάξει η κατάσταση αυτού του κόμβου, θα το γνωρίζουμε. Και μπορούμε να προσπαθήσουμε να έχουμε χρόνο να το αναδημιουργήσουμε. Εάν πήραμε αυτόν τον κόμβο, πήραμε αυτό το κλείδωμα, τότε αφού δεν χρειαζόμαστε πλέον το κλείδωμα, θα το εγκαταλείψουμε, αφού ο κόμβος υπάρχει μόνο εντός της συνεδρίας. Αντίστοιχα, θα εξαφανιστεί. Και ένας άλλος πελάτης, στο πλαίσιο μιας άλλης συνεδρίας, θα μπορεί να πάρει το κλείδωμα σε αυτόν τον κόμβο, ή μάλλον, θα λάβει μια ειδοποίηση ότι κάτι έχει αλλάξει και μπορεί να προσπαθήσει να το κάνει εγκαίρως.
Ένα άλλο παράδειγμα για το πώς μπορείτε να επιλέξετε τον κύριο ηγέτη. Αυτό είναι λίγο πιο περίπλοκο, αλλά και σχετικά απλό. Τι συμβαίνει εδώ? Υπάρχει ένας κύριος κόμβος που συγκεντρώνει όλους τους εργάτες. Προσπαθούμε να πάρουμε δεδομένα για τον ηγέτη. Εάν αυτό συνέβη με επιτυχία, δηλαδή λάβαμε κάποια δεδομένα, τότε ο εργαζόμενός μας αρχίζει να ακολουθεί αυτόν τον ηγέτη. Πιστεύει ότι υπάρχει ήδη αρχηγός.
Εάν ο ηγέτης πέθανε για κάποιο λόγο, για παράδειγμα, έπεσε, τότε προσπαθούμε να δημιουργήσουμε έναν νέο ηγέτη. Και αν τα καταφέρουμε, τότε ο εργάτης μας γίνεται αρχηγός. Και αν κάποιος αυτή τη στιγμή κατάφερε να δημιουργήσει έναν νέο ηγέτη, τότε προσπαθούμε να καταλάβουμε ποιος είναι και μετά να τον ακολουθήσουμε.
Εδώ προκύπτει το λεγόμενο φαινόμενο αγέλης, δηλαδή το φαινόμενο της αγέλης, γιατί όταν πεθάνει ένας ηγέτης, αυτός που είναι πρώτος στο χρόνο θα γίνει αρχηγός.
Όταν καταγράφετε έναν πόρο, μπορείτε να δοκιμάσετε να χρησιμοποιήσετε μια ελαφρώς διαφορετική προσέγγιση, η οποία είναι η εξής. Για παράδειγμα, θέλουμε να πάρουμε μια κλειδαριά, αλλά χωρίς το φαινόμενο hert. Θα συνίσταται στο γεγονός ότι η εφαρμογή μας ζητά λίστες με όλα τα αναγνωριστικά κόμβων για έναν ήδη υπάρχοντα κόμβο με κλείδωμα. Και αν πριν από αυτό ο κόμβος για τον οποίο δημιουργήσαμε μια κλειδαριά είναι ο μικρότερος από το σύνολο που λάβαμε, τότε αυτό σημαίνει ότι έχουμε καταγράψει την κλειδαριά. Ελέγχουμε ότι έχουμε λάβει κλειδαριά. Ως επιταγή, θα υπάρχει η προϋπόθεση ότι το αναγνωριστικό που λάβαμε κατά τη δημιουργία μιας νέας κλειδαριάς είναι ελάχιστο. Και αν το παραλάβαμε, τότε δουλεύουμε περαιτέρω.
Εάν υπάρχει ένα συγκεκριμένο αναγνωριστικό που είναι μικρότερο από το κλείδωμα μας, τότε βάζουμε έναν παρατηρητή σε αυτό το συμβάν και περιμένουμε ειδοποίηση μέχρι να αλλάξει κάτι. Δηλαδή παραλάβαμε αυτή την κλειδαριά. Και μέχρι να πέσει, δεν θα γίνουμε το ελάχιστο αναγνωριστικό και δεν θα λάβουμε το ελάχιστο κλείδωμα, και έτσι θα μπορούμε να συνδεθούμε. Και αν δεν πληρούται αυτή η προϋπόθεση, τότε πάμε αμέσως εδώ και προσπαθούμε να ξαναπάρουμε αυτήν την κλειδαριά, γιατί κάτι μπορεί να άλλαξε σε αυτό το διάστημα.
Από τι αποτελείται το ZooKeeper; Υπάρχουν 4 βασικά πράγματα. Πρόκειται για διαδικασίες επεξεργασίας - Αίτημα. Και επίσης ZooKeeper Atomic Broadcast. Υπάρχει ένα αρχείο καταγραφής δέσμευσης όπου καταγράφονται όλες οι λειτουργίες. Και το ίδιο το Replicated DB στη μνήμη, δηλαδή η ίδια η βάση δεδομένων όπου είναι αποθηκευμένο ολόκληρο αυτό το δέντρο.
Αξίζει να σημειωθεί ότι όλες οι λειτουργίες εγγραφής περνούν από τον επεξεργαστή αιτημάτων. Και οι λειτουργίες ανάγνωσης πηγαίνουν απευθείας στη βάση δεδομένων της μνήμης.
Η ίδια η βάση δεδομένων αναπαράγεται πλήρως. Όλες οι περιπτώσεις του ZooKeeper αποθηκεύουν ένα πλήρες αντίγραφο των δεδομένων.
Για να επαναφέρετε τη βάση δεδομένων μετά από ένα σφάλμα, υπάρχει ένα αρχείο καταγραφής Commit. Η τυπική πρακτική είναι ότι πριν εισέλθουν δεδομένα στη μνήμη, γράφονται εκεί, έτσι ώστε, εάν διακοπεί, αυτό το αρχείο καταγραφής μπορεί να αναπαραχθεί και να αποκατασταθεί η κατάσταση του συστήματος. Επίσης χρησιμοποιούνται περιοδικά στιγμιότυπα της βάσης δεδομένων.
Το ZooKeeper Atomic Broadcast είναι κάτι που χρησιμοποιείται για τη διατήρηση αναπαραγόμενων δεδομένων.
Το ZAB επιλέγει εσωτερικά έναν ηγέτη από την άποψη του κόμβου ZooKeeper. Άλλοι κόμβοι γίνονται οπαδοί της και περιμένουν κάποιες ενέργειες από αυτήν. Εάν λάβουν συμμετοχές, τις προωθούν όλες στον αρχηγό. Πρώτα εκτελεί μια λειτουργία εγγραφής και στη συνέχεια στέλνει ένα μήνυμα για το τι έχει αλλάξει στους ακόλουθούς του. Αυτό, στην πραγματικότητα, πρέπει να εκτελείται ατομικά, δηλαδή η λειτουργία εγγραφής και μετάδοσης του συνόλου πρέπει να γίνεται ατομικά, διασφαλίζοντας έτσι τη συνοχή των δεδομένων.
Επεξεργάζεται μόνο αιτήματα εγγραφής. Το κύριο καθήκον του είναι ότι μετατρέπει τη λειτουργία σε ενημέρωση συναλλαγών. Αυτό είναι ένα αίτημα που δημιουργήθηκε ειδικά.
Και εδώ αξίζει να σημειωθεί ότι η αδυναμία των ενημερώσεων για την ίδια λειτουργία είναι εγγυημένη. Τι είναι? Αυτό το πράγμα, αν εκτελεστεί δύο φορές, θα έχει την ίδια κατάσταση, δηλαδή το ίδιο το αίτημα δεν θα αλλάξει. Και αυτό πρέπει να γίνει έτσι ώστε σε περίπτωση συντριβής, να μπορείτε να επανεκκινήσετε τη λειτουργία, επαναφέροντας έτσι τις αλλαγές που έχουν αποτύχει αυτήν τη στιγμή. Σε αυτήν την περίπτωση, η κατάσταση του συστήματος θα γίνει η ίδια, δηλαδή δεν θα πρέπει να συμβαίνει ότι μια σειρά ίδιων, για παράδειγμα, διεργασιών ενημέρωσης, οδήγησε σε διαφορετικές τελικές καταστάσεις του συστήματος.
Πηγή: www.habr.com
