Γεια σε όλους. Ο Βλάντισλαβ Ροντέν είναι σε επαφή. Αυτή τη στιγμή διδάσκω μαθήματα Αρχιτεκτονικής Λογισμικού και Αρχιτεκτονικής Λογισμικού Υψηλού Στρες στο OTUS. Εν αναμονή της έναρξης μιας νέας ροής πορείας Αποφάσισα να γράψω ένα σύντομο πρωτότυπο υλικό που θέλω να μοιραστώ μαζί σας.
Εισαγωγή
Λόγω του γεγονότος ότι ο σκληρός δίσκος μπορεί να εκτελέσει μόνο περίπου 400-700 λειτουργίες ανά δευτερόλεπτο (πράγμα ασύγκριτο με το τυπικό rps σε ένα σύστημα υψηλού φορτίου), η κλασική βάση δεδομένων δίσκου είναι το σημείο συμφόρησης της αρχιτεκτονικής. Επομένως, είναι απαραίτητο να δοθεί ιδιαίτερη προσοχή στα μοτίβα κλιμάκωσης αυτής της αποθήκευσης.
Επί του παρόντος, υπάρχουν 2 μοτίβα κλίμακας βάσεων δεδομένων: αναπαραγωγή και διαμοιρασμός. Η κοινή χρήση σάς επιτρέπει να κλιμακώσετε τη λειτουργία εγγραφής και, ως αποτέλεσμα, να μειώσετε τα rps ανά εγγραφή ανά διακομιστή στο σύμπλεγμα σας. Η αναπαραγωγή σάς επιτρέπει να κάνετε το ίδιο πράγμα, αλλά με λειτουργίες ανάγνωσης. Σε αυτό το μοτίβο είναι αφιερωμένο αυτό το άρθρο.
Αντιγραφή
Αν κοιτάξετε την αναπαραγωγή σε πολύ υψηλό επίπεδο, είναι ένα απλό πράγμα: είχατε έναν διακομιστή, υπήρχαν δεδομένα σε αυτόν και, στη συνέχεια, αυτός ο διακομιστής δεν μπορούσε πλέον να αντεπεξέλθει στο φόρτο της ανάγνωσης αυτών των δεδομένων. Προσθέτετε μερικούς ακόμη διακομιστές, συγχρονίζετε δεδομένα σε όλους τους διακομιστές και ο χρήστης μπορεί να διαβάσει από οποιονδήποτε διακομιστή στο σύμπλεγμα σας.
Παρά τη φαινομενική απλότητά του, υπάρχουν πολλές επιλογές για την ταξινόμηση διαφόρων υλοποιήσεων αυτού του σχήματος:
- Ανά ρόλους στο σύμπλεγμα (κύριος-κύριος ή κύριος-σκλάβος)
- Με αντικείμενα που αποστέλλονται (βασισμένα σε σειρά, βάσει δηλώσεων ή μεικτά)
- Σύμφωνα με τον μηχανισμό συγχρονισμού κόμβων
Σήμερα θα ασχοληθούμε με το σημείο 3.
Πώς γίνεται μια δέσμευση συναλλαγής;
Αυτό το θέμα δεν σχετίζεται άμεσα με την αναπαραγωγή· μπορεί να γραφτεί ένα ξεχωριστό άρθρο, αλλά επειδή η περαιτέρω ανάγνωση είναι άχρηστη χωρίς να κατανοήσουμε τον μηχανισμό δέσμευσης συναλλαγών, επιτρέψτε μου να σας υπενθυμίσω τα πιο βασικά πράγματα. Μια δέσμευση συναλλαγής πραγματοποιείται σε 3 στάδια:
- Καταγραφή μιας συναλλαγής στο αρχείο καταγραφής της βάσης δεδομένων.
- Χρήση συναλλαγής σε μηχανή βάσης δεδομένων.
- Επιστροφή επιβεβαίωσης στον πελάτη ότι η συναλλαγή εφαρμόστηκε με επιτυχία.
Σε διαφορετικές βάσεις δεδομένων, αυτός ο αλγόριθμος μπορεί να έχει αποχρώσεις: για παράδειγμα, στη μηχανή InnoDB της βάσης δεδομένων MySQL υπάρχουν 2 αρχεία καταγραφής: το ένα για αναπαραγωγή (δυαδικό αρχείο καταγραφής) και το άλλο για τη διατήρηση του ACID (αναίρεση/επανάληψη καταγραφής), ενώ στο PostgreSQL υπάρχει ένα αρχείο καταγραφής που εκτελεί και τις δύο λειτουργίες (εγγραφή καταγραφής μπροστά = WAL). Αλλά αυτό που παρουσιάζεται παραπάνω είναι ακριβώς η γενική ιδέα, η οποία επιτρέπει να μην λαμβάνονται υπόψη τέτοιες αποχρώσεις.
Σύγχρονη (συγχρονισμός) αντιγραφή
Ας προσθέσουμε λογική για να αναπαράγουμε τις ληφθείσες αλλαγές στον αλγόριθμο δέσμευσης συναλλαγών:
- Καταγραφή μιας συναλλαγής στο αρχείο καταγραφής της βάσης δεδομένων.
- Χρήση συναλλαγής σε μηχανή βάσης δεδομένων.
- Αποστολή δεδομένων σε όλα τα αντίγραφα.
- Λήψη επιβεβαίωσης από όλα τα αντίγραφα ότι έχει ολοκληρωθεί μια συναλλαγή σε αυτά.
- Επιστροφή επιβεβαίωσης στον πελάτη ότι η συναλλαγή εφαρμόστηκε με επιτυχία.
Με αυτή την προσέγγιση έχουμε μια σειρά από μειονεκτήματα:
- ο πελάτης περιμένει να εφαρμοστούν οι αλλαγές σε όλα τα αντίγραφα.
- Καθώς ο αριθμός των κόμβων στο σύμπλεγμα αυξάνεται, μειώνουμε την πιθανότητα επιτυχούς λειτουργίας της εγγραφής.
Αν όλα είναι λίγο πολύ ξεκάθαρα με το 1ο σημείο, τότε αξίζει να εξηγηθούν οι λόγοι για το 2ο σημείο. Εάν κατά τη διάρκεια της σύγχρονης αναπαραγωγής δεν λάβουμε απάντηση από τουλάχιστον έναν κόμβο, επαναφέρουμε τη συναλλαγή. Έτσι, αυξάνοντας τον αριθμό των κόμβων στο σύμπλεγμα, αυξάνετε την πιθανότητα να αποτύχει μια λειτουργία εγγραφής.
Μπορούμε να περιμένουμε επιβεβαίωση μόνο από ένα συγκεκριμένο ποσοστό κόμβων, για παράδειγμα, από το 51% (απαρτία); Ναι, μπορούμε, αλλά στην κλασική έκδοση, απαιτείται επιβεβαίωση από όλους τους κόμβους, γιατί έτσι μπορούμε να εξασφαλίσουμε πλήρη συνέπεια δεδομένων στο σύμπλεγμα, κάτι που είναι αναμφισβήτητο πλεονέκτημα αυτού του τύπου αναπαραγωγής.
Ασύγχρονη (ασύγχρονη) αντιγραφή
Ας τροποποιήσουμε τον προηγούμενο αλγόριθμο. Θα στείλουμε δεδομένα στα αντίγραφα "κάποια στιγμή αργότερα" και "κάποια στιγμή" οι αλλαγές θα εφαρμοστούν στα αντίγραφα:
- Καταγραφή μιας συναλλαγής στο αρχείο καταγραφής της βάσης δεδομένων.
- Χρήση συναλλαγής σε μηχανή βάσης δεδομένων.
- Επιστροφή επιβεβαίωσης στον πελάτη ότι η συναλλαγή εφαρμόστηκε με επιτυχία.
- Αποστολή δεδομένων σε αντίγραφα και εφαρμογή αλλαγών σε αυτά.
Αυτή η προσέγγιση οδηγεί στο γεγονός ότι το σύμπλεγμα λειτουργεί γρήγορα, επειδή δεν αφήνουμε τον πελάτη να περιμένει τα δεδομένα να φτάσουν στα αντίγραφα και ακόμη και να δεσμευτούν.
Αλλά η προϋπόθεση της απόρριψης δεδομένων σε αντίγραφα «κάποια στιγμή αργότερα» μπορεί να οδηγήσει στην απώλεια μιας συναλλαγής και στην απώλεια μιας συναλλαγής που επιβεβαιώθηκε από τον χρήστη, επειδή εάν τα δεδομένα δεν είχαν χρόνο να αναπαραχθούν, μια επιβεβαίωση στον πελάτη σχετικά με την επιτυχία της λειτουργίας στάλθηκε και ο κόμβος στον οποίο έφτασαν οι αλλαγές συνετρίβη σκληρός δίσκος, χάνουμε τη συναλλαγή, γεγονός που μπορεί να οδηγήσει σε πολύ δυσάρεστες συνέπειες.
Ημισυγχρονισμένη αναπαραγωγή
Τελικά φτάνουμε στην ημισύγχρονη αντιγραφή. Αυτός ο τύπος αντιγραφής δεν είναι πολύ γνωστός ή πολύ κοινός, αλλά παρουσιάζει σημαντικό ενδιαφέρον επειδή μπορεί να συνδυάσει τα πλεονεκτήματα τόσο της σύγχρονης όσο και της ασύγχρονης αναπαραγωγής.
Ας προσπαθήσουμε να συνδυάσουμε τις 2 προηγούμενες προσεγγίσεις. Δεν θα κρατήσουμε τον πελάτη για πολύ, αλλά θα απαιτήσουμε την αναπαραγωγή των δεδομένων:
- Καταγραφή μιας συναλλαγής στο αρχείο καταγραφής της βάσης δεδομένων.
- Χρήση συναλλαγής σε μηχανή βάσης δεδομένων.
- Αποστολή δεδομένων σε αντίγραφα.
- Λήψη επιβεβαίωσης από το αντίγραφο ότι οι αλλαγές έχουν ληφθεί (θα εφαρμοστούν "κάποια στιγμή αργότερα").
- Επιστροφή επιβεβαίωσης στον πελάτη ότι η συναλλαγή εφαρμόστηκε με επιτυχία.
Λάβετε υπόψη ότι με αυτόν τον αλγόριθμο, η απώλεια συναλλαγής συμβαίνει μόνο εάν αποτύχουν τόσο ο κόμβος που λαμβάνει τις αλλαγές όσο και ο κόμβος αντιγραφής. Η πιθανότητα μιας τέτοιας αποτυχίας θεωρείται χαμηλή και αυτοί οι κίνδυνοι γίνονται αποδεκτοί.
Αλλά με αυτήν την προσέγγιση υπάρχει ένας πιθανός κίνδυνος φαντομικών αναγνώσεων. Ας φανταστούμε το εξής σενάριο: στο βήμα 4, δεν λάβαμε επιβεβαίωση από κανένα αντίγραφο. Πρέπει να επαναφέρουμε αυτήν τη συναλλαγή και να μην επιστρέψουμε επιβεβαίωση στον πελάτη. Εφόσον τα δεδομένα εφαρμόστηκαν στο βήμα 2, υπάρχει ένα χρονικό κενό μεταξύ του τέλους του βήματος 2 και της επαναφοράς της συναλλαγής, κατά το οποίο οι παράλληλες συναλλαγές μπορούν να δουν αλλαγές που δεν θα έπρεπε να υπάρχουν στη βάση δεδομένων.
Ημισυγχρονισμένη αναπαραγωγή χωρίς απώλεια
Αν σκεφτείτε λίγο, μπορείτε απλώς να αντιστρέψετε τα βήματα του αλγορίθμου και να διορθώσετε το πρόβλημα των φανταστικών αναγνώσεων σε αυτό το σενάριο:
- Καταγραφή μιας συναλλαγής στο αρχείο καταγραφής της βάσης δεδομένων.
- Αποστολή αντιγράφων δεδομένων.
- Λήψη επιβεβαίωσης από το αντίγραφο ότι οι αλλαγές έχουν ληφθεί (θα εφαρμοστούν "κάποια στιγμή αργότερα").
- Χρήση συναλλαγής σε μηχανή βάσης δεδομένων.
- Επιστροφή επιβεβαίωσης στον πελάτη ότι η συναλλαγή εφαρμόστηκε με επιτυχία.
Τώρα πραγματοποιούμε αλλαγές μόνο εάν έχουν αντιγραφεί.
Παραγωγή
Όπως πάντα, δεν υπάρχουν ιδανικές λύσεις· υπάρχει ένα σύνολο λύσεων, καθεμία από τις οποίες έχει τα δικά της πλεονεκτήματα και μειονεκτήματα και είναι κατάλληλη για την επίλυση διαφορετικών κατηγοριών προβλημάτων. Αυτό ισχύει απολύτως για την επιλογή ενός μηχανισμού για το συγχρονισμό δεδομένων σε μια αναπαραγόμενη βάση δεδομένων. Το σύνολο των πλεονεκτημάτων που έχει η ημισύγχρονη αντιγραφή είναι αρκετά συμπαγές και ενδιαφέρον που μπορεί να θεωρηθεί άξιο προσοχής, παρά το χαμηλό επιπολασμό του.
Αυτό είναι όλο. Θα σε δώ στο !
Πηγή: www.habr.com