Ερχόμενοι σε ένα προϊόν που αναπτύσσεται για περισσότερο από μια δεκαετία, δεν είναι καθόλου περίεργο να βρίσκουμε ξεπερασμένες τεχνολογίες σε αυτό. Τι γίνεται όμως αν σε έξι μήνες πρέπει να κρατήσετε το φορτίο 10 φορές υψηλότερο και το κόστος των πτώσεων θα αυξηθεί εκατοντάδες φορές; Σε αυτήν την περίπτωση, χρειάζεστε έναν cool Engineer Highload. Αλλά ελλείψει υπηρέτριας, μου ανέθεσαν τη λύση του προβλήματος. Στο πρώτο μέρος του άρθρου θα σας πω πώς περάσαμε από το Redis στο Redis-cluster και στο δεύτερο μέρος θα δώσω συμβουλές για το πώς να ξεκινήσετε να χρησιμοποιείτε το σύμπλεγμα και τι να προσέχετε όταν το χρησιμοποιείτε.

Επιλογή τεχνολογίας

Είναι τόσο κακό; ξεχωριστό Redis (standalone redis) σε διαμόρφωση 1 master και N slaves; Γιατί το αποκαλώ ξεπερασμένη τεχνολογία;

Όχι, ο Ρέντις δεν είναι τόσο κακός... Ωστόσο, υπάρχουν κάποιες ελλείψεις που δεν μπορούν να αγνοηθούν.

• Πρώτον, το Redis δεν υποστηρίζει μηχανισμούς αποκατάστασης καταστροφής μετά από αποτυχία κύριας. Για να λύσουμε αυτό το πρόβλημα, χρησιμοποιήσαμε μια διαμόρφωση με αυτόματη μεταφορά VIP σε νέο κύριο, αλλάζοντας τον ρόλο ενός από τους slaves και αλλάζοντας τα υπόλοιπα. Αυτός ο μηχανισμός λειτούργησε, αλλά δεν θα μπορούσε να ονομαστεί αξιόπιστη λύση. Πρώτον, εμφανίστηκαν ψευδείς συναγερμοί και δεύτερον, ήταν μιας χρήσης και μετά τη λειτουργία απαιτήθηκαν χειροκίνητες ενέργειες για τη φόρτιση του ελατηρίου.

• Δεύτερον, η ύπαρξη μόνο ενός πλοίαρχου οδήγησε στο πρόβλημα του θρυμματισμού. Έπρεπε να δημιουργήσουμε πολλά ανεξάρτητα συμπλέγματα "1 master και N slaves", στη συνέχεια να διανείμουμε με μη αυτόματο τρόπο τις βάσεις δεδομένων μεταξύ αυτών των μηχανών και να ελπίζουμε ότι αύριο μία από τις βάσεις δεδομένων δεν θα διογκωθεί τόσο πολύ που θα πρέπει να μετακινηθεί σε ξεχωριστή παρουσία.

Ποιες είναι οι επιλογές;

• Η πιο ακριβή και πλουσιότερη λύση είναι η Redis-Enterprise. Αυτή είναι μια ολοκληρωμένη λύση με πλήρη τεχνική υποστήριξη. Παρά το γεγονός ότι φαίνεται ιδανικό από τεχνικής απόψεως, δεν μας ταίριαζε για ιδεολογικούς λόγους.
• Redis-cluster. Έξω από το κουτί υπάρχει υποστήριξη για master failover και sharding. Η διεπαφή δεν διαφέρει σχεδόν από την κανονική έκδοση. Φαίνεται πολλά υποσχόμενο, θα μιλήσουμε για τις παγίδες αργότερα.
• Tarantool, Memcache, Aerospike και άλλα. Όλα αυτά τα εργαλεία κάνουν σχεδόν το ίδιο πράγμα. Όμως το καθένα έχει τις δικές του ελλείψεις. Αποφασίσαμε να μην βάλουμε όλα τα αυγά μας σε ένα καλάθι. Χρησιμοποιούμε το Memcache και το Tarantool για άλλες εργασίες και, κοιτάζοντας μπροστά, θα πω ότι στην πρακτική μας υπήρχαν περισσότερα προβλήματα με αυτά.

Προδιαγραφές χρήσης

Ας ρίξουμε μια ματιά στα προβλήματα που έχουμε επιλύσει ιστορικά με το Redis και ποια λειτουργικότητα χρησιμοποιήσαμε:

• Προσωρινή αποθήκευση πριν από αιτήματα για απομακρυσμένες υπηρεσίες όπως το 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• Προσωρινή μνήμη πριν από την MYSQL | PHP
  

  GET SET MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• Ο κύριος χώρος αποθήκευσης για την υπηρεσία εργασίας με συνεδρίες και συντεταγμένες προγραμμάτων οδήγησης | Golang
  

  GET SET MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

Όπως μπορείτε να δείτε, όχι ανώτερα μαθηματικά. Ποια είναι λοιπόν η δυσκολία; Ας δούμε κάθε μέθοδο ξεχωριστά.

Μέθοδος
Περιγραφή
Χαρακτηριστικά του Redis-cluster
Λύση

ΕΤΟΙΜΑΣΟΥ
Πλήκτρο εγγραφής/ανάγνωσης

MGET MSET
Γράψτε/διάβαστε πολλά πλήκτρα
Τα κλειδιά θα βρίσκονται σε διαφορετικούς κόμβους. Οι έτοιμες βιβλιοθήκες μπορούν να εκτελούν πολλαπλές λειτουργίες μόνο εντός ενός κόμβου
Αντικαταστήστε το MGET με έναν αγωγό λειτουργιών N GET

ΕΠΙΛΟΓΗ ΒΔ
Επιλέξτε τη βάση με την οποία θα δουλέψουμε
Δεν υποστηρίζει πολλαπλές βάσεις δεδομένων
Βάλτε τα πάντα σε μια βάση δεδομένων. Προσθέστε προθέματα στα πλήκτρα

SCAN
Μεταβείτε σε όλα τα κλειδιά στη βάση δεδομένων
Δεδομένου ότι έχουμε μία βάση δεδομένων, η διερεύνηση όλων των κλειδιών στο σύμπλεγμα είναι πολύ ακριβή
Διατηρήστε ένα αμετάβλητο σε ένα κλειδί και κάντε ένα HSCAN σε αυτό το κλειδί. Ή αρνηθείτε εντελώς

GEO
Λειτουργίες με γεωκλειδί
Το geokey δεν είναι θρυμματισμένο

ΚΛΕΙΔΙ ΚΑΤΑ ΣΧΕΔΙΟ
Αναζήτηση κλειδιού με μοτίβο
Εφόσον έχουμε μία βάση δεδομένων, θα κάνουμε αναζήτηση σε όλα τα κλειδιά του συμπλέγματος. Πολύ ακριβό
Απορρίψτε ή διατηρήστε το αμετάβλητο, όπως στην περίπτωση του SCAN

Redis vs Redis-cluster

Τι χάνουμε και τι κερδίζουμε όταν μεταβαίνουμε σε ένα σύμπλεγμα;

• Μειονεκτήματα: χάνουμε τη λειτουργικότητα πολλών βάσεων δεδομένων.
  • Αν θέλουμε να αποθηκεύσουμε λογικά άσχετα δεδομένα σε ένα σύμπλεγμα, θα πρέπει να κάνουμε δεκανίκια με τη μορφή προθεμάτων.
  • Χάνουμε όλες τις «βασικές» λειτουργίες, όπως SCAN, DBSIZE, CLEAR DB, κ.λπ.
  • Οι πολλαπλές λειτουργίες έχουν γίνει πολύ πιο δύσκολο να εφαρμοστούν επειδή μπορεί να απαιτούν πρόσβαση σε αρκετούς κόμβους.
• Συμπληρώματα:
  • Ανοχή σφαλμάτων με τη μορφή master failover.
  • Sharding από την πλευρά του Redis.
  • Μεταφέρετε δεδομένα μεταξύ κόμβων ατομικά και χωρίς χρόνο διακοπής λειτουργίας.
  • Προσθέστε και αναδιανείμετε χωρητικότητα και φορτία χωρίς διακοπές λειτουργίας.

Θα συμπέρανα ότι εάν δεν χρειάζεται να παρέχετε υψηλό επίπεδο ανοχής σφαλμάτων, τότε η μετάβαση σε ένα σύμπλεγμα δεν αξίζει τον κόπο, γιατί μπορεί να είναι μια μη τετριμμένη εργασία. Αλλά αν αρχικά επιλέξετε μεταξύ μιας ξεχωριστής έκδοσης και μιας έκδοσης συμπλέγματος, τότε θα πρέπει να επιλέξετε ένα σύμπλεγμα, καθώς δεν είναι χειρότερο και, επιπλέον, θα σας απαλλάξει από κάποιους πονοκεφάλους

Προετοιμασία για μετακίνηση

Ας ξεκινήσουμε με τις απαιτήσεις μετακίνησης:

• Θα πρέπει να είναι χωρίς ραφή. Μια πλήρης διακοπή της υπηρεσίας για 5 λεπτά δεν μας ταιριάζει.
• Θα πρέπει να είναι όσο το δυνατόν πιο ασφαλής και σταδιακή. Θέλω να έχω τον έλεγχο της κατάστασης. Δεν θέλουμε να πετάξουμε τα πάντα με τη μία και να προσευχόμαστε για το κουμπί επαναφοράς.
• Ελάχιστη απώλεια δεδομένων κατά τη μετακίνηση. Κατανοούμε ότι θα είναι πολύ δύσκολο να μετακινηθεί κανείς ατομικά, επομένως επιτρέπουμε κάποιο αποσυγχρονισμό μεταξύ δεδομένων σε κανονικό και ομαδοποιημένο Redis.

Συντήρηση συμπλέγματος

Λίγο πριν τη μετακόμιση, θα πρέπει να σκεφτούμε αν μπορούμε να υποστηρίξουμε το σύμπλεγμα:

• Διαγράμματα. Χρησιμοποιούμε το Prometheus και το Grafana για να απεικονίσουμε το φορτίο της CPU, τη χρήση μνήμης, τον αριθμό των πελατών, τον αριθμό των λειτουργιών GET, SET, AUTH κ.λπ.
• Εξειδίκευση. Φανταστείτε ότι αύριο θα έχετε ένα τεράστιο σύμπλεγμα υπό την ευθύνη σας. Αν χαλάσει, κανείς εκτός από εσάς δεν μπορεί να το φτιάξει. Αν αρχίσει να επιβραδύνει, όλοι θα τρέξουν προς το μέρος σας. Εάν χρειάζεται να προσθέσετε πόρους ή να αναδιανείμετε το φορτίο, επιστρέψτε σε εσάς. Για να μην γκριζάρετε στα 25, καλό είναι να προβλεφθούν αυτές οι περιπτώσεις και να ελέγξετε εκ των προτέρων πώς θα συμπεριφέρεται η τεχνολογία σε ορισμένες ενέργειες. Ας μιλήσουμε για αυτό με περισσότερες λεπτομέρειες στην ενότητα "Εξειδίκευση".
• Παρακολούθηση και ειδοποιήσεις. Όταν ένα σύμπλεγμα καταρρέει, θέλετε να είστε οι πρώτοι που θα το μάθετε. Εδώ περιοριστήκαμε σε μια ειδοποίηση ότι όλοι οι κόμβοι επιστρέφουν τις ίδιες πληροφορίες σχετικά με την κατάσταση του συμπλέγματος (ναι, συμβαίνει διαφορετικά). Και άλλα προβλήματα μπορούν να παρατηρηθούν πιο γρήγορα με ειδοποιήσεις από τις υπηρεσίες πελατών Redis.

Μετεγκατάσταση

Πώς θα κινηθούμε:

• Πρώτα απ 'όλα, πρέπει να προετοιμάσετε μια βιβλιοθήκη για να εργαστείτε με το σύμπλεγμα. Πήραμε το go-redis ως βάση για την έκδοση Go και το αλλάξαμε λίγο για να ταιριάζει στον εαυτό μας. Εφαρμόσαμε Multi-methods μέσω αγωγών και διορθώσαμε επίσης ελαφρώς τους κανόνες για την επανάληψη των αιτημάτων. Η έκδοση PHP είχε περισσότερα προβλήματα, αλλά τελικά καταλήξαμε στο php-redis. Πρόσφατα εισήγαγαν την υποστήριξη συμπλέγματος και φαίνεται καλό κατά τη γνώμη μας.
• Στη συνέχεια, πρέπει να αναπτύξετε το ίδιο το σύμπλεγμα. Αυτό γίνεται κυριολεκτικά σε δύο εντολές που βασίζονται στο αρχείο διαμόρφωσης. Θα συζητήσουμε τη ρύθμιση με περισσότερες λεπτομέρειες παρακάτω.
• Για σταδιακή μετακίνηση χρησιμοποιούμε στεγνή λειτουργία. Δεδομένου ότι έχουμε δύο εκδόσεις της βιβλιοθήκης με την ίδια διεπαφή (μία για την κανονική έκδοση, η άλλη για το σύμπλεγμα), δεν κοστίζει τίποτα η δημιουργία ενός περιτυλίγματος που θα λειτουργεί με μια ξεχωριστή έκδοση και παράλληλα θα αντιγράφει όλα τα αιτήματα στο σύμπλεγμα, συγκρίνετε τις απαντήσεις και γράψτε τις αποκλίσεις στα αρχεία καταγραφής (στην περίπτωσή μας στο NewRelic). Έτσι, ακόμα κι αν η έκδοση συμπλέγματος χαλάσει κατά την κυκλοφορία, η παραγωγή μας δεν θα επηρεαστεί.
• Έχοντας ανοίξει το σύμπλεγμα σε ξηρή λειτουργία, μπορούμε να δούμε ήρεμα το γράφημα των αποκλίσεων απόκρισης. Εάν το ποσοστό σφάλματος κινείται αργά αλλά σταθερά προς κάποια μικρή σταθερά, τότε όλα είναι καλά. Γιατί εξακολουθούν να υπάρχουν αποκλίσεις; Επειδή η εγγραφή σε ξεχωριστή έκδοση πραγματοποιείται λίγο νωρίτερα από ό,τι στο σύμπλεγμα και λόγω μικρούστερησης, τα δεδομένα ενδέχεται να αποκλίνουν. Το μόνο που μένει είναι να δούμε τα αρχεία καταγραφής ασυμφωνιών και αν όλα εξηγούνται από τη μη ατομικότητα του αρχείου, τότε μπορούμε να προχωρήσουμε.
• Τώρα μπορείτε να αλλάξετε τη λειτουργία στεγνώματος προς την αντίθετη κατεύθυνση. Θα γράψουμε και θα διαβάσουμε από το σύμπλεγμα και θα το αντιγράψουμε σε ξεχωριστή έκδοση. Για τι? Την επόμενη εβδομάδα θα ήθελα να παρακολουθήσω τη δουλειά του cluster. Εάν ξαφνικά αποδειχθεί ότι υπάρχουν προβλήματα στο φορτίο αιχμής ή δεν λάβαμε κάτι υπόψη, έχουμε πάντα μια επείγουσα επαναφορά στον παλιό κώδικα και τα τρέχοντα δεδομένα χάρη στη λειτουργία ξηρού.
• Το μόνο που μένει είναι να απενεργοποιήσετε τη λειτουργία ξηρού και να αποσυναρμολογήσετε την ξεχωριστή έκδοση.

Εξειδίκευση

Πρώτον, εν συντομία για το σχεδιασμό συμπλέγματος.

Πρώτα απ 'όλα, το Redis είναι ένα κατάστημα βασικής αξίας. Ως κλειδιά χρησιμοποιούνται αυθαίρετες χορδές. Αριθμοί, συμβολοσειρές και ολόκληρες δομές μπορούν να χρησιμοποιηθούν ως τιμές. Υπάρχουν πολλά από τα τελευταία, αλλά για την κατανόηση της γενικής δομής αυτό δεν είναι σημαντικό για εμάς.
Το επόμενο επίπεδο αφαίρεσης μετά τα κλειδιά είναι οι κουλοχέρηδες (SLOTS). Κάθε κλειδί ανήκει σε μία από τις 16 θέσεις. Μπορεί να υπάρχει οποιοσδήποτε αριθμός κλειδιών μέσα σε κάθε υποδοχή. Έτσι, όλα τα κλειδιά χωρίζονται σε 383 διαχωρισμένα σετ.

Στη συνέχεια, πρέπει να υπάρχουν N κύριοι κόμβοι στο σύμπλεγμα. Κάθε κόμβος μπορεί να θεωρηθεί ως ένα ξεχωριστό παράδειγμα Redis που γνωρίζει τα πάντα για άλλους κόμβους μέσα στο σύμπλεγμα. Κάθε κύριος κόμβος περιέχει έναν αριθμό θυρίδων. Κάθε υποδοχή ανήκει σε έναν μόνο κύριο κόμβο. Όλες οι υποδοχές πρέπει να κατανέμονται μεταξύ των κόμβων. Εάν ορισμένες υποδοχές δεν έχουν εκχωρηθεί, τότε τα κλειδιά που είναι αποθηκευμένα σε αυτές δεν θα είναι προσβάσιμα. Είναι λογικό να εκτελείται κάθε κύριος κόμβος σε ξεχωριστό λογικό ή φυσικό μηχάνημα. Αξίζει επίσης να θυμάστε ότι κάθε κόμβος εκτελείται μόνο σε έναν πυρήνα και εάν θέλετε να εκτελέσετε πολλές περιπτώσεις Redis στον ίδιο λογικό μηχάνημα, βεβαιωθείτε ότι εκτελούνται σε διαφορετικούς πυρήνες (δεν το έχουμε δοκιμάσει αυτό, αλλά θεωρητικά θα πρέπει να λειτουργεί) . Ουσιαστικά, οι κύριοι κόμβοι παρέχουν τακτικό διαμοιρασμό, και περισσότεροι κύριοι κόμβοι επιτρέπουν την κλιμάκωση των αιτημάτων εγγραφής και ανάγνωσης.

Αφού κατανεμηθούν όλα τα κλειδιά μεταξύ των υποδοχών και οι υποδοχές διασκορπιστούν στους κύριους κόμβους, ένας αυθαίρετος αριθμός υποτελών κόμβων μπορεί να προστεθεί σε κάθε κύριο κόμβο. Μέσα σε κάθε τέτοιο σύνδεσμο master-slave, η κανονική αναπαραγωγή θα λειτουργήσει. Απαιτούνται slaves για την κλιμάκωση των αιτημάτων ανάγνωσης και για failover σε περίπτωση αποτυχίας master.

Τώρα ας μιλήσουμε για επεμβάσεις που θα ήταν καλύτερα να μπορούμε να κάνουμε.

Θα έχουμε πρόσβαση στο σύστημα μέσω του Redis-CLI. Επειδή το Redis δεν έχει ένα μόνο σημείο εισόδου, μπορείτε να εκτελέσετε τις ακόλουθες λειτουργίες σε οποιονδήποτε από τους κόμβους. Σε κάθε σημείο ξεχωριστά εφιστώ την προσοχή στη δυνατότητα εκτέλεσης της λειτουργίας υπό φορτίο.

• Το πρώτο και πιο σημαντικό πράγμα που χρειαζόμαστε είναι η λειτουργία των κόμβων συμπλέγματος. Επιστρέφει την κατάσταση του συμπλέγματος, εμφανίζει μια λίστα κόμβων, τους ρόλους τους, την κατανομή θυρίδων κ.λπ. Μπορείτε να λάβετε περισσότερες πληροφορίες χρησιμοποιώντας πληροφορίες συμπλέγματος και υποδοχές συμπλέγματος.
• Θα ήταν ωραίο να μπορούμε να προσθέτουμε και να αφαιρούμε κόμβους. Για το σκοπό αυτό υπάρχουν λειτουργίες συνάντησης και λήθης συμπλέγματος. Λάβετε υπόψη ότι η λήθη συμπλέγματος πρέπει να εφαρμόζεται σε ΚΑΘΕ κόμβο, τόσο σε κύρια όσο και σε αντίγραφα. Και το cluster meet χρειάζεται να καλείται μόνο σε έναν κόμβο. Αυτή η διαφορά μπορεί να είναι ανησυχητική, επομένως είναι καλύτερο να την μάθετε πριν ξεκινήσετε ζωντανά με το σύμπλεγμα σας. Η προσθήκη κόμβου γίνεται με ασφάλεια στη μάχη και δεν επηρεάζει με κανέναν τρόπο τη λειτουργία του cluster (κάτι που είναι λογικό). Εάν πρόκειται να αφαιρέσετε έναν κόμβο από το σύμπλεγμα, θα πρέπει να βεβαιωθείτε ότι δεν υπάρχουν υποδοχές σε αυτόν (διαφορετικά κινδυνεύετε να χάσετε την πρόσβαση σε όλα τα κλειδιά αυτού του κόμβου). Επίσης, μην διαγράψετε έναν κύριο που έχει σκλάβους, διαφορετικά θα εκτελεστεί μια περιττή ψηφοφορία για νέο κύριο. Εάν οι κόμβοι δεν έχουν πλέον υποδοχές, τότε αυτό είναι ένα μικρό πρόβλημα, αλλά γιατί χρειαζόμαστε επιπλέον επιλογές εάν μπορούμε πρώτα να διαγράψουμε τους slaves.
• Εάν πρέπει να ανταλλάξετε με δύναμη τις θέσεις master και slave, τότε η εντολή failover του συμπλέγματος θα κάνει. Όταν το καλείτε στη μάχη, πρέπει να καταλάβετε ότι ο πλοίαρχος δεν θα είναι διαθέσιμος κατά τη διάρκεια της επιχείρησης. Συνήθως ο διακόπτης γίνεται σε λιγότερο από ένα δευτερόλεπτο, αλλά δεν είναι ατομικός. Μπορείτε να περιμένετε ότι ορισμένα αιτήματα προς τον κύριο θα αποτύχουν κατά τη διάρκεια αυτής της περιόδου.
• Πριν αφαιρέσετε έναν κόμβο από το σύμπλεγμα, δεν θα πρέπει να υπάρχουν υποδοχές σε αυτόν. Είναι καλύτερα να τα αναδιανείμετε χρησιμοποιώντας την εντολή reshard συμπλέγματος. Οι κουλοχέρηδες θα μεταφερθούν από το ένα master στο άλλο. Η όλη λειτουργία μπορεί να διαρκέσει αρκετά λεπτά, εξαρτάται από τον όγκο των δεδομένων που μεταφέρονται, αλλά η διαδικασία μεταφοράς είναι ασφαλής και δεν επηρεάζει με κανέναν τρόπο τη λειτουργία του συμπλέγματος. Έτσι, όλα τα δεδομένα μπορούν να μεταφερθούν από τον έναν κόμβο στον άλλο απευθείας υπό φόρτωση και χωρίς να ανησυχείτε για τη διαθεσιμότητά τους. Ωστόσο, υπάρχουν και λεπτές αποχρώσεις. Πρώτον, η μεταφορά δεδομένων σχετίζεται με ένα συγκεκριμένο φορτίο στους κόμβους παραλήπτη και αποστολέα. Εάν ο κόμβος παραλήπτη είναι ήδη πολύ φορτωμένος στον επεξεργαστή, τότε δεν θα πρέπει να τον φορτώσετε με λήψη νέων δεδομένων. Δεύτερον, μόλις δεν μείνει ούτε μία υποδοχή στον κύριο αποστολέα, όλοι οι slaves του θα πάνε αμέσως στον κύριο στον οποίο μεταφέρθηκαν αυτές οι θέσεις. Και το πρόβλημα είναι ότι όλοι αυτοί οι σκλάβοι θα θέλουν να συγχρονίσουν δεδομένα ταυτόχρονα. Και θα είστε τυχεροί αν είναι μερικός και όχι πλήρης συγχρονισμός. Λάβετε αυτό υπόψη και συνδυάστε τις λειτουργίες μεταφοράς κουλοχέρηδων και απενεργοποίησης/μεταφοράς σκλάβων. Ή ελπίζετε ότι έχετε επαρκή περιθώρια ασφάλειας.
• Τι πρέπει να κάνετε εάν, κατά τη διάρκεια της μεταφοράς, διαπιστώσετε ότι κάπου χάσατε τους κουλοχέρηδες σας; Ελπίζω αυτό το πρόβλημα να μην σας επηρεάσει, αλλά αν σας επηρεάσει, υπάρχει μια λειτουργία επιδιόρθωσης συμπλέγματος. Τουλάχιστον, θα διασκορπίσει τις υποδοχές στους κόμβους με τυχαία σειρά. Συνιστώ να ελέγξετε τη λειτουργία του αφαιρώντας πρώτα τον κόμβο με κατανεμημένες υποδοχές από το σύμπλεγμα. Δεδομένου ότι τα δεδομένα σε μη κατανεμημένες κουλοχέρηδες δεν είναι ήδη διαθέσιμα, είναι πολύ αργά να ανησυχείτε για προβλήματα με τη διαθεσιμότητα αυτών των υποδοχών. Με τη σειρά της, η λειτουργία δεν θα επηρεάσει τις κατανεμημένες κουλοχέρηδες.
• Μια άλλη χρήσιμη λειτουργία είναι η οθόνη. Σας επιτρέπει να βλέπετε σε πραγματικό χρόνο ολόκληρη τη λίστα των αιτημάτων που πηγαίνουν στον κόμβο. Επιπλέον, μπορείτε να το πιάσετε και να μάθετε αν υπάρχει η απαραίτητη κίνηση.

Αξίζει επίσης να αναφέρουμε τη διαδικασία master failover. Εν ολίγοις, υπάρχει και, κατά τη γνώμη μου, λειτουργεί εξαιρετικά. Ωστόσο, μην νομίζετε ότι εάν αποσυνδέσετε το καλώδιο τροφοδοσίας σε ένα μηχάνημα με κύριο κόμβο, το Redis θα αλλάξει αμέσως και οι πελάτες δεν θα παρατηρήσουν την απώλεια. Στην πρακτική μου, η εναλλαγή γίνεται σε λίγα δευτερόλεπτα. Κατά τη διάρκεια αυτού του χρονικού διαστήματος, ορισμένα από τα δεδομένα δεν θα είναι διαθέσιμα: ανιχνεύεται η μη διαθεσιμότητα του πλοιάρχου, οι κόμβοι ψηφίζουν για νέο, οι υποτελείς εναλλάσσονται, τα δεδομένα συγχρονίζονται. Ο καλύτερος τρόπος για να βεβαιωθείτε μόνοι σας ότι το πρόγραμμα λειτουργεί είναι να διεξάγετε τοπικές ασκήσεις. Σηκώστε το σύμπλεγμα στον φορητό υπολογιστή σας, δώστε του ένα ελάχιστο φορτίο, προσομοιώστε μια συντριβή (για παράδειγμα, μπλοκάροντας τις θύρες) και αξιολογήστε την ταχύτητα μεταγωγής. Κατά τη γνώμη μου, μόνο αφού παίξετε με αυτόν τον τρόπο για μια ή δύο μέρες μπορείτε να είστε σίγουροι για τη λειτουργία της τεχνολογίας. Λοιπόν, ή ελπίζουμε ότι το λογισμικό που χρησιμοποιεί το μισό Διαδίκτυο μάλλον λειτουργεί.

Διαμόρφωση

Συχνά, η διαμόρφωση είναι το πρώτο πράγμα που χρειάζεστε για να ξεκινήσετε να εργάζεστε με το εργαλείο. Και όταν όλα λειτουργούν, δεν θέλετε καν να αγγίξετε τη διαμόρφωση. Χρειάζεται κάποια προσπάθεια για να αναγκάσετε τον εαυτό σας να επιστρέψει στις ρυθμίσεις και να τις περάσει προσεκτικά. Στη μνήμη μου, είχαμε τουλάχιστον δύο σοβαρές αστοχίες λόγω απροσεξίας στη διαμόρφωση. Δώστε ιδιαίτερη προσοχή στα ακόλουθα σημεία:

• timeout 0
  Χρόνος μετά τον οποίο κλείνουν οι ανενεργές συνδέσεις (σε δευτερόλεπτα). 0 - μην κλείνεις
  Δεν ήταν κάθε βιβλιοθήκη μας σε θέση να κλείσει σωστά τις συνδέσεις. Με την απενεργοποίηση αυτής της ρύθμισης, κινδυνεύουμε να φτάσουμε στο όριο του αριθμού των πελατών. Από την άλλη, εάν υπάρχει τέτοιο πρόβλημα, τότε ο αυτόματος τερματισμός των χαμένων συνδέσεων θα το κρύψει και μπορεί να μην το παρατηρήσουμε. Επιπλέον, δεν πρέπει να ενεργοποιήσετε αυτήν τη ρύθμιση όταν χρησιμοποιείτε συνεχείς συνδέσεις.
• Αποθήκευση xy & παράρτημα ναι
  Αποθήκευση στιγμιότυπου RDB.
  Θα συζητήσουμε τα θέματα RDB/AOF λεπτομερώς παρακάτω.
• stop-writes-on-bgsave-error no & slave-serve-stale-data ναι
  Εάν είναι ενεργοποιημένο, εάν το στιγμιότυπο RDB διακοπεί, ο κύριος θα σταματήσει να δέχεται αιτήματα αλλαγής. Εάν χαθεί η σύνδεση με τον κύριο, ο slave μπορεί να συνεχίσει να ανταποκρίνεται σε αιτήματα (ναι). Ή θα σταματήσει να ανταποκρίνεται (όχι)
  Δεν είμαστε ευχαριστημένοι με την κατάσταση στην οποία ο Ρέντις μετατρέπεται σε κολοκύθα.
• repl-ping-slave-period 5
  Μετά από αυτό το χρονικό διάστημα, θα αρχίσουμε να ανησυχούμε ότι το master έχει χαλάσει και είναι καιρός να πραγματοποιήσουμε τη διαδικασία failover.
  Θα πρέπει να βρείτε με μη αυτόματο τρόπο μια ισορροπία μεταξύ ψευδώς θετικών και ενεργοποίησης ενός failover. Στην πρακτική μας αυτό είναι 5 δευτερόλεπτα.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Μπορούμε να αποθηκεύσουμε τόσα πολλά δεδομένα σε ένα buffer για ένα αποτυχημένο αντίγραφο. Εάν το buffer εξαντληθεί, θα πρέπει να συγχρονίσετε πλήρως.
  Η πρακτική υποδηλώνει ότι είναι καλύτερο να ορίσετε υψηλότερη τιμή. Υπάρχουν πολλοί λόγοι για τους οποίους ένα αντίγραφο μπορεί να αρχίσει να καθυστερεί. Εάν καθυστερεί, τότε πιθανότατα ο κύριος σας δυσκολεύεται ήδη να αντεπεξέλθει και ο πλήρης συγχρονισμός θα είναι η σταγόνα που ξεχείλισε το ποτήρι.
• μέγιστος πελάτης 10000
  Μέγιστος αριθμός εφάπαξ πελατών.
  Σύμφωνα με την εμπειρία μας, είναι καλύτερο να ορίσουμε μια υψηλότερη τιμή. Το Redis χειρίζεται 10 συνδέσεις μια χαρά. Απλώς βεβαιωθείτε ότι υπάρχουν αρκετές πρίζες στο σύστημα.
• maxmemory-policy volatile-ttl
  Ο κανόνας με τον οποίο διαγράφονται τα κλειδιά όταν συμπληρωθεί το διαθέσιμο όριο μνήμης.
  Αυτό που είναι σημαντικό εδώ δεν είναι ο ίδιος ο κανόνας, αλλά η κατανόηση του πώς θα συμβεί αυτό. Το Redis μπορεί να επαινεθεί για την ικανότητά του να λειτουργεί κανονικά όταν επιτευχθεί το όριο μνήμης.

Προβλήματα RDB και AOF

Αν και το ίδιο το Redis αποθηκεύει όλες τις πληροφορίες στη μνήμη RAM, υπάρχει επίσης ένας μηχανισμός αποθήκευσης δεδομένων στο δίσκο. Πιο συγκεκριμένα, τρεις μηχανισμοί:

• RDB-snapshot - ένα πλήρες στιγμιότυπο όλων των δεδομένων. Ρυθμίστε χρησιμοποιώντας τη διαμόρφωση SAVE XY και γράφει "Αποθήκευση πλήρους στιγμιότυπου όλων των δεδομένων κάθε X δευτερόλεπτα, εάν έχουν αλλάξει τουλάχιστον τα πλήκτρα Y".
• Αρχείο μόνο προσάρτησης - μια λίστα λειτουργιών με τη σειρά που εκτελούνται. Προσθέτει νέες εισερχόμενες λειτουργίες στο αρχείο κάθε X δευτερόλεπτα ή κάθε λειτουργία Y.
• Το RDB και το AOF είναι συνδυασμός των δύο προηγούμενων.

Όλες οι μέθοδοι έχουν τα πλεονεκτήματα και τα μειονεκτήματά τους, δεν θα τις απαριθμήσω όλες, απλώς θα επιστήσω την προσοχή σε σημεία που, κατά τη γνώμη μου, δεν είναι προφανή.

Πρώτον, η αποθήκευση ενός στιγμιότυπου RDB απαιτεί κλήση FORK. Εάν υπάρχουν πολλά δεδομένα, αυτό μπορεί να κρεμάσει όλα τα Redis για μια περίοδο μερικών χιλιοστών του δευτερολέπτου έως ένα δευτερόλεπτο. Επιπλέον, το σύστημα πρέπει να εκχωρήσει μνήμη για ένα τέτοιο στιγμιότυπο, γεγονός που οδηγεί στην ανάγκη διατήρησης διπλής τροφοδοσίας RAM στο λογικό μηχάνημα: εάν έχουν εκχωρηθεί 8 GB για το Redis, τότε θα πρέπει να είναι διαθέσιμα 16 GB στην εικονική μηχανή με το.

Δεύτερον, υπάρχουν προβλήματα με τον μερικό συγχρονισμό. Στη λειτουργία AOF, όταν το slave επανασυνδέεται, αντί για μερικό συγχρονισμό, μπορεί να πραγματοποιηθεί πλήρης συγχρονισμός. Γιατί συμβαίνει αυτό, δεν μπορούσα να καταλάβω. Αξίζει όμως να το θυμάστε αυτό.

Αυτά τα δύο σημεία μας κάνουν ήδη να σκεφτούμε αν χρειαζόμαστε πραγματικά αυτά τα δεδομένα στο δίσκο, εάν όλα έχουν ήδη αντιγραφεί από σκλάβους. Τα δεδομένα μπορούν να χαθούν μόνο εάν αποτύχουν όλοι οι σκλάβοι και αυτό είναι ένα πρόβλημα επιπέδου "φωτιά στο DC". Ως συμβιβασμός, μπορείτε να προτείνετε την αποθήκευση δεδομένων μόνο σε σκλάβους, αλλά σε αυτήν την περίπτωση πρέπει να βεβαιωθείτε ότι αυτοί οι σκλάβοι δεν θα γίνουν ποτέ κύριοι κατά την ανάκτηση από καταστροφή (για αυτό υπάρχει μια ρύθμιση προτεραιότητας υποτελών στη διαμόρφωσή τους). Για τον εαυτό μας, σε κάθε συγκεκριμένη περίπτωση σκεφτόμαστε αν είναι απαραίτητο να αποθηκεύσουμε δεδομένα στο δίσκο και τις περισσότερες φορές η απάντηση είναι "όχι".

Συμπέρασμα

Εν κατακλείδι, ελπίζω ότι μπόρεσα να δώσω μια γενική ιδέα για το πώς λειτουργεί το redis-cluster για όσους δεν το έχουν ακούσει καθόλου, και επίσης επέστησα την προσοχή σε ορισμένα μη προφανή σημεία για όσους το χρησιμοποιούν για πολύ καιρό.
Ευχαριστώ για τον χρόνο σας και, όπως πάντα, τα σχόλια για το θέμα είναι ευπρόσδεκτα.

Πηγή: www.habr.com