Γεια σε όλους! Το όνομά μου είναι Sergey Kostanbaev, στο Χρηματιστήριο αναπτύσσω τον πυρήνα του συστήματος συναλλαγών.
Όταν οι ταινίες του Χόλιγουντ δείχνουν το Χρηματιστήριο της Νέας Υόρκης, μοιάζει πάντα με αυτό: πλήθος κόσμου, όλοι φωνάζουν κάτι, κουνάνε χαρτιά, συμβαίνει απόλυτο χάος. Αυτό δεν συνέβη ποτέ εδώ στο Χρηματιστήριο της Μόσχας, επειδή οι συναλλαγές έγιναν ηλεκτρονικά από την αρχή και βασίζονται σε δύο κύριες πλατφόρμες - Spectra (αγορά συναλλάγματος) και ASTS (χρηματιστήριο, χρηματιστήριο και χρηματαγορά). Και σήμερα θέλω να μιλήσω για την εξέλιξη της αρχιτεκτονικής του συστήματος συναλλαγών και εκκαθάρισης ASTS, για διάφορες λύσεις και ευρήματα. Η ιστορία θα είναι μεγάλη, οπότε έπρεπε να τη χωρίσω σε δύο μέρη.
Είμαστε ένα από τα λίγα χρηματιστήρια στον κόσμο που εμπορεύεται περιουσιακά στοιχεία όλων των κατηγοριών και παρέχει ένα πλήρες φάσμα υπηρεσιών ανταλλαγής. Για παράδειγμα, πέρυσι κατατασσόμασταν δεύτερη στον κόσμο όσον αφορά τον όγκο συναλλαγών ομολόγων, 25η θέση μεταξύ όλων των χρηματιστηρίων, 13η θέση σε κεφαλαιοποίηση μεταξύ των δημοσίων χρηματιστηρίων.
Για επαγγελματίες συμμετέχοντες στο εμπόριο, παράμετροι όπως ο χρόνος απόκρισης, η σταθερότητα της κατανομής του χρόνου (jitter) και η αξιοπιστία ολόκληρου του συγκροτήματος είναι κρίσιμες. Αυτήν τη στιγμή επεξεργαζόμαστε δεκάδες εκατομμύρια συναλλαγές την ημέρα. Η επεξεργασία κάθε συναλλαγής από τον πυρήνα του συστήματος διαρκεί δεκάδες μικροδευτερόλεπτα. Φυσικά, οι πάροχοι κινητής τηλεφωνίας την παραμονή της Πρωτοχρονιάς ή οι ίδιες οι μηχανές αναζήτησης έχουν μεγαλύτερο φόρτο εργασίας από τον δικό μας, αλλά όσον αφορά τον φόρτο εργασίας, σε συνδυασμό με τα προαναφερθέντα χαρακτηριστικά, λίγοι μπορούν να συγκριθούν με εμάς, μου φαίνεται. Ταυτόχρονα, είναι σημαντικό για εμάς το σύστημα να μην επιβραδύνει ούτε ένα δευτερόλεπτο, να λειτουργεί απόλυτα σταθερά και όλοι οι χρήστες να βρίσκονται σε ισότιμη βάση.
Λίγη ιστορία
Το 1994, το αυστραλιανό σύστημα ASTS κυκλοφόρησε στο Διατραπεζικό Συναλλάγματος της Μόσχας (MICEX) και από εκείνη τη στιγμή μπορεί να μετρηθεί η ρωσική ιστορία ηλεκτρονικών συναλλαγών. Το 1998, η αρχιτεκτονική ανταλλαγής εκσυγχρονίστηκε για να εισαγάγει τις συναλλαγές μέσω Διαδικτύου. Έκτοτε, η ταχύτητα υλοποίησης νέων λύσεων και αρχιτεκτονικών αλλαγών σε όλα τα συστήματα και τα υποσυστήματα μόλις κερδίζει δυναμική.
Εκείνα τα χρόνια, το σύστημα ανταλλαγής δούλευε σε υλικό υψηλής τεχνολογίας - εξαιρετικά αξιόπιστοι διακομιστές HP Superdome 9000 (χτισμένοι σε), στο οποίο αντιγράφονταν απολύτως τα πάντα: υποσυστήματα εισόδου/εξόδου, δίκτυο, μνήμη RAM (στην πραγματικότητα, υπήρχε μια συστοιχία RAID RAM), επεξεργαστές (με δυνατότητα εναλλαγής). Ήταν δυνατή η αλλαγή οποιουδήποτε στοιχείου διακομιστή χωρίς διακοπή του μηχανήματος. Βασιστήκαμε σε αυτές τις συσκευές και τις θεωρούσαμε σχεδόν ασφαλείς έναντι αστοχίας. Το λειτουργικό σύστημα ήταν ένα σύστημα HP UX παρόμοιο με το Unix.
Αλλά από το 2010 περίπου, έχει εμφανιστεί ένα φαινόμενο που ονομάζεται διαπραγμάτευση υψηλής συχνότητας (HFT), ή διαπραγμάτευση υψηλής συχνότητας - με απλά λόγια, χρηματιστηριακά ρομπότ. Μέσα σε μόλις 2,5 χρόνια, ο φόρτος στους διακομιστές μας έχει αυξηθεί 140 φορές.
Ήταν αδύνατο να αντέξει ένα τέτοιο φορτίο με την παλιά αρχιτεκτονική και τον εξοπλισμό. Ήταν απαραίτητο να προσαρμοστούμε με κάποιο τρόπο.
ΑΡΧΙΚΗ
Τα αιτήματα στο σύστημα ανταλλαγής μπορούν να χωριστούν σε δύο τύπους:
- Συναλλαγές. Εάν θέλετε να αγοράσετε δολάρια, μετοχές ή κάτι άλλο, στέλνετε μια συναλλαγή στο σύστημα συναλλαγών και λαμβάνετε μια απάντηση σχετικά με την επιτυχία.
- Αιτήματα πληροφοριών. Εάν θέλετε να μάθετε την τρέχουσα τιμή, δείτε το βιβλίο παραγγελιών ή τους δείκτες και, στη συνέχεια, στείλτε αιτήματα πληροφοριών.
Σχηματικά, ο πυρήνας του συστήματος μπορεί να χωριστεί σε τρία επίπεδα:
- Το επίπεδο πελάτη, στο οποίο εργάζονται οι μεσίτες και οι πελάτες. Όλοι αλληλεπιδρούν με διακομιστές πρόσβασης.
- Οι διακομιστές πύλης είναι διακομιστές προσωρινής αποθήκευσης που επεξεργάζονται τοπικά όλα τα αιτήματα πληροφοριών. Θέλετε να μάθετε σε ποια τιμή διαπραγματεύονται οι μετοχές της Sberbank αυτήν τη στιγμή; Το αίτημα πηγαίνει στον διακομιστή πρόσβασης.
- Αν όμως θέλετε να αγοράσετε μετοχές, τότε το αίτημα πηγαίνει στον κεντρικό διακομιστή (Trade Engine). Υπάρχει ένας τέτοιος διακομιστής για κάθε τύπο αγοράς, παίζουν ζωτικό ρόλο, είναι για αυτούς που δημιουργήσαμε αυτό το σύστημα.
Ο πυρήνας του συστήματος συναλλαγών είναι μια έξυπνη βάση δεδομένων στη μνήμη, στην οποία όλες οι συναλλαγές είναι συναλλαγές ανταλλαγής. Η βάση ήταν γραμμένη σε C, οι μόνες εξωτερικές εξαρτήσεις ήταν η βιβλιοθήκη libc και δεν υπήρχε καθόλου δυναμική εκχώρηση μνήμης. Για να μειωθεί ο χρόνος επεξεργασίας, το σύστημα ξεκινά με ένα στατικό σύνολο συστοιχιών και με στατική μετεγκατάσταση δεδομένων: πρώτα, όλα τα δεδομένα για την τρέχουσα ημέρα φορτώνονται στη μνήμη και δεν εκτελείται περαιτέρω πρόσβαση στο δίσκο, όλες οι εργασίες εκτελούνται μόνο στη μνήμη. Κατά την εκκίνηση του συστήματος, όλα τα δεδομένα αναφοράς είναι ήδη ταξινομημένα, επομένως η αναζήτηση λειτουργεί πολύ αποτελεσματικά και απαιτεί λίγο χρόνο στο χρόνο εκτέλεσης. Όλοι οι πίνακες είναι κατασκευασμένοι με παρεμβατικές λίστες και δέντρα για δυναμικές δομές δεδομένων, έτσι ώστε να μην απαιτούν εκχώρηση μνήμης κατά το χρόνο εκτέλεσης.
Ας δούμε εν συντομία την ιστορία της ανάπτυξης του συστήματος συναλλαγών και εκκαθάρισης.
Η πρώτη έκδοση της αρχιτεκτονικής του συστήματος συναλλαγών και εκκαθάρισης βασίστηκε στη λεγόμενη αλληλεπίδραση Unix: χρησιμοποιήθηκαν κοινόχρηστη μνήμη, σηματοφόροι και ουρές, και κάθε διεργασία αποτελούνταν από ένα μόνο νήμα. Αυτή η προσέγγιση ήταν ευρέως διαδεδομένη στις αρχές της δεκαετίας του 1990.
Η πρώτη έκδοση του συστήματος περιείχε δύο επίπεδα Gateway και έναν κεντρικό διακομιστή του συστήματος συναλλαγών. Η ροή εργασίας ήταν η εξής:
- Ο πελάτης στέλνει ένα αίτημα, το οποίο φτάνει στο Gateway. Ελέγχει την εγκυρότητα της μορφής (αλλά όχι τα ίδια τα δεδομένα) και απορρίπτει εσφαλμένες συναλλαγές.
- Εάν έχει σταλεί αίτημα πληροφοριών, εκτελείται τοπικά. αν μιλάμε για συναλλαγή, τότε ανακατευθύνεται στον κεντρικό διακομιστή.
- Η μηχανή συναλλαγών επεξεργάζεται στη συνέχεια τη συναλλαγή, τροποποιεί την τοπική μνήμη και στέλνει μια απάντηση στη συναλλαγή και στην ίδια τη συναλλαγή για αναπαραγωγή χρησιμοποιώντας μια ξεχωριστή μηχανή αναπαραγωγής.
- Το Gateway λαμβάνει την απάντηση από τον κεντρικό κόμβο και την προωθεί στον πελάτη.
- Μετά από κάποιο χρονικό διάστημα, το Gateway λαμβάνει τη συναλλαγή μέσω του μηχανισμού αναπαραγωγής και αυτή τη φορά την εκτελεί τοπικά, αλλάζοντας τις δομές δεδομένων του έτσι ώστε τα επόμενα αιτήματα πληροφοριών να εμφανίζουν τα πιο πρόσφατα δεδομένα.
Στην πραγματικότητα, περιγράφει ένα μοντέλο αναπαραγωγής στο οποίο το Gateway αναπαράγει πλήρως τις ενέργειες που εκτελούνται στο σύστημα συναλλαγών. Ένα ξεχωριστό κανάλι αναπαραγωγής εξασφάλιζε ότι οι συναλλαγές εκτελούνταν με την ίδια σειρά σε πολλούς κόμβους πρόσβασης.
Δεδομένου ότι ο κώδικας ήταν μονού νήματος, χρησιμοποιήθηκε ένα κλασικό σχήμα με διχάλα διεργασιών για την εξυπηρέτηση πολλών πελατών. Ωστόσο, ήταν πολύ ακριβό να διαχωριστεί ολόκληρη η βάση δεδομένων, επομένως χρησιμοποιήθηκαν ελαφριές διεργασίες υπηρεσίας που συνέλεγαν πακέτα από συνεδρίες TCP και τα μετέφεραν σε μία ουρά (SystemV Message Queue). Το Gateway και το Trade Engine δούλευαν μόνο με αυτήν την ουρά, παίρνοντας συναλλαγές από εκεί για εκτέλεση. Δεν ήταν πλέον δυνατή η αποστολή απάντησης σε αυτό, επειδή δεν ήταν σαφές ποια διαδικασία υπηρεσίας έπρεπε να την διαβάσει. Καταφύγαμε λοιπόν σε ένα τέχνασμα: κάθε διχαλωμένη διεργασία δημιουργούσε μια ουρά απόκρισης για τον εαυτό της και όταν ένα αίτημα μπήκε στην εισερχόμενη ουρά, αμέσως προστέθηκε σε αυτό μια ετικέτα για την ουρά απόκρισης.
Η συνεχής αντιγραφή μεγάλου όγκου δεδομένων από ουρά σε ουρά δημιουργούσε προβλήματα, ιδιαίτερα τυπικά για αιτήματα πληροφοριών. Επομένως, χρησιμοποιήσαμε ένα άλλο κόλπο: εκτός από την ουρά απόκρισης, κάθε διεργασία δημιουργούσε και κοινόχρηστη μνήμη (SystemV Shared Memory). Τα ίδια τα πακέτα τοποθετήθηκαν σε αυτό και μόνο μια ετικέτα αποθηκεύτηκε στην ουρά, επιτρέποντας σε κάποιον να βρει το αρχικό πακέτο. Αυτό βοήθησε στην αποθήκευση δεδομένων στην κρυφή μνήμη του επεξεργαστή.
Το SystemV IPC περιλαμβάνει βοηθητικά προγράμματα για την προβολή της κατάστασης της ουράς, της μνήμης και των αντικειμένων σηματοφόρου. Το χρησιμοποιήσαμε ενεργά για να κατανοήσουμε τι συνέβαινε στο σύστημα σε μια συγκεκριμένη στιγμή, πού συσσωρεύτηκαν πακέτα, τι μπλοκαρίστηκε κ.λπ.
Πρώτες αναβαθμίσεις
Πρώτα απ 'όλα, απαλλαγήκαμε από την πύλη μιας διαδικασίας. Το σημαντικό μειονέκτημά του ήταν ότι μπορούσε να χειριστεί είτε μία συναλλαγή αναπαραγωγής είτε ένα αίτημα πληροφοριών από έναν πελάτη. Και καθώς το φορτίο αυξάνεται, το Gateway θα χρειαστεί περισσότερο χρόνο για να επεξεργαστεί αιτήματα και δεν θα μπορεί να επεξεργαστεί τη ροή αναπαραγωγής. Επιπλέον, εάν ο πελάτης έστειλε μια συναλλαγή, τότε χρειάζεται μόνο να ελέγξετε την εγκυρότητά της και να την προωθήσετε περαιτέρω. Επομένως, αντικαταστήσαμε τη διαδικασία μεμονωμένης πύλης με πολλά στοιχεία που μπορούν να εκτελούνται παράλληλα: πληροφορίες πολλαπλών νημάτων και διεργασίες συναλλαγών που εκτελούνται ανεξάρτητα η μία από την άλλη σε μια κοινόχρηστη περιοχή μνήμης χρησιμοποιώντας κλείδωμα RW. Και ταυτόχρονα εισαγάγαμε τις διαδικασίες αποστολής και αναπαραγωγής.
Επιπτώσεις των συναλλαγών υψηλής συχνότητας
Η παραπάνω έκδοση της αρχιτεκτονικής υπήρχε μέχρι το 2010. Εν τω μεταξύ, δεν ήμασταν πλέον ικανοποιημένοι με την απόδοση των διακομιστών HP Superdome. Επιπλέον, η αρχιτεκτονική PA-RISC ήταν σχεδόν νεκρή· ο πωλητής δεν πρόσφερε σημαντικές ενημερώσεις. Ως αποτέλεσμα, αρχίσαμε να μετακινούμαστε από το HP UX/PA RISC στο Linux/x86. Η μετάβαση ξεκίνησε με την προσαρμογή των διακομιστών πρόσβασης.
Γιατί έπρεπε να αλλάξουμε ξανά την αρχιτεκτονική; Το γεγονός είναι ότι η διαπραγμάτευση υψηλής συχνότητας έχει αλλάξει σημαντικά το προφίλ φορτίου στον πυρήνα του συστήματος.
Ας υποθέσουμε ότι έχουμε μια μικρή συναλλαγή που προκάλεσε σημαντική αλλαγή τιμής - κάποιος αγόρασε μισό δισεκατομμύριο δολάρια. Μετά από μερικά χιλιοστά του δευτερολέπτου, όλοι οι συμμετέχοντες στην αγορά το παρατηρούν αυτό και αρχίζουν να κάνουν μια διόρθωση. Φυσικά, τα αιτήματα παρατάσσονται σε μια τεράστια ουρά, την οποία το σύστημα θα χρειαστεί πολύ χρόνο για να διαγράψει.
Σε αυτό το διάστημα των 50 ms, η μέση ταχύτητα είναι περίπου 16 χιλιάδες συναλλαγές ανά δευτερόλεπτο. Αν μειώσουμε το παράθυρο στα 20 ms, έχουμε μέση ταχύτητα 90 χιλιάδων συναλλαγών ανά δευτερόλεπτο, με 200 χιλιάδες συναλλαγές στην κορυφή. Με άλλα λόγια, το φορτίο δεν είναι σταθερό, με ξαφνικές εκρήξεις. Και η ουρά των αιτημάτων πρέπει πάντα να διεκπεραιώνεται γρήγορα.
Γιατί όμως υπάρχει καθόλου ουρά; Έτσι, στο παράδειγμά μας, πολλοί χρήστες παρατήρησαν την αλλαγή της τιμής και έστειλαν συναλλαγές ανάλογα. Έρχονται στο Gateway, τους σειριοποιεί, βάζει μια συγκεκριμένη σειρά και τους στέλνει στο δίκτυο. Οι δρομολογητές ανακατεύουν τα πακέτα και τα προωθούν. Όποιος το πακέτο έφτασε πρώτο, αυτή η συναλλαγή «κέρδισε». Ως αποτέλεσμα, οι πελάτες ανταλλαγής άρχισαν να παρατηρούν ότι εάν η ίδια συναλλαγή στάλθηκε από πολλές πύλες, τότε οι πιθανότητες ταχείας διεκπεραίωσής της αυξάνονταν. Σύντομα, ρομπότ ανταλλαγής άρχισαν να βομβαρδίζουν το Gateway με αιτήματα και προέκυψε μια χιονοστιβάδα συναλλαγών.
Ένας νέος γύρος εξέλιξης
Μετά από εκτεταμένες δοκιμές και έρευνα, μεταβήκαμε στον πυρήνα του λειτουργικού συστήματος σε πραγματικό χρόνο. Για αυτό, επιλέξαμε το RedHat Enterprise MRG Linux, όπου το MRG σημαίνει πλέγμα ανταλλαγής μηνυμάτων σε πραγματικό χρόνο. Το πλεονέκτημα των ενημερώσεων κώδικα σε πραγματικό χρόνο είναι ότι βελτιστοποιούν το σύστημα για την ταχύτερη δυνατή εκτέλεση: όλες οι διεργασίες παρατάσσονται σε μια ουρά FIFO, οι πυρήνες μπορούν να απομονωθούν, δεν υπάρχουν εξαγωγές, όλες οι συναλλαγές υποβάλλονται σε επεξεργασία με αυστηρή σειρά.
Κόκκινο - εργασία με ουρά σε κανονικό πυρήνα, πράσινο - εργασία σε πυρήνα σε πραγματικό χρόνο.
Αλλά η επίτευξη χαμηλής καθυστέρησης σε κανονικούς διακομιστές δεν είναι τόσο εύκολη:
- Η λειτουργία SMI, η οποία στην αρχιτεκτονική x86 είναι η βάση για την εργασία με σημαντικά περιφερειακά, παρεμβαίνει σε μεγάλο βαθμό. Η επεξεργασία όλων των ειδών συμβάντων υλικού και η διαχείριση στοιχείων και συσκευών εκτελείται από το υλικολογισμικό στη λεγόμενη διαφανή λειτουργία SMI, στην οποία το λειτουργικό σύστημα δεν βλέπει καθόλου τι κάνει το υλικολογισμικό. Κατά κανόνα, όλοι οι μεγάλοι προμηθευτές προσφέρουν ειδικές επεκτάσεις για διακομιστές υλικολογισμικού που επιτρέπουν τη μείωση του όγκου της επεξεργασίας SMI.
- Δεν θα πρέπει να υπάρχει δυναμικός έλεγχος της συχνότητας του επεξεργαστή, αυτό οδηγεί σε επιπλέον χρόνο διακοπής λειτουργίας.
- Όταν το αρχείο καταγραφής του συστήματος αρχείων ξεπλένεται, συμβαίνουν ορισμένες διεργασίες στον πυρήνα που προκαλούν απρόβλεπτες καθυστερήσεις.
- Πρέπει να δώσετε προσοχή σε πράγματα όπως CPU Affinity, Interrupt affinity, NUMA.
Πρέπει να πω ότι το θέμα της ρύθμισης υλικού και πυρήνα Linux για επεξεργασία σε πραγματικό χρόνο αξίζει ένα ξεχωριστό άρθρο. Περάσαμε πολύ χρόνο πειραματιζόμενοι και ερευνώντας προτού πετύχουμε ένα καλό αποτέλεσμα.
Όταν μετακινούμαστε από διακομιστές PA-RISC σε x86, πρακτικά δεν χρειάστηκε να αλλάξουμε πολύ τον κωδικό συστήματος, απλώς τον προσαρμόσαμε και τον επαναδιαμορφώσαμε. Ταυτόχρονα, διορθώσαμε αρκετά σφάλματα. Για παράδειγμα, οι συνέπειες του γεγονότος ότι το PA RISC ήταν ένα σύστημα Big Endian και το x86 ήταν ένα Little Endian σύστημα, εμφανίστηκαν γρήγορα: για παράδειγμα, τα δεδομένα διαβάστηκαν λανθασμένα. Το πιο δύσκολο σφάλμα ήταν ότι χρησιμοποιεί το PA RISC () πρόσβαση στη μνήμη, ενώ το x86 μπορεί να αναδιατάξει τις λειτουργίες ανάγνωσης, έτσι ο κώδικας που ίσχυε απόλυτα σε μια πλατφόρμα κατεστάλη σε μια άλλη.
Μετά τη μετάβαση στο x86, η απόδοση αυξήθηκε σχεδόν τρεις φορές, ο μέσος χρόνος επεξεργασίας συναλλαγών μειώθηκε στα 60 μs.
Ας ρίξουμε τώρα μια πιο προσεκτική ματιά σε ποιες βασικές αλλαγές έχουν γίνει στην αρχιτεκτονική του συστήματος.
Καυτό έπος αποθεματικό
Κατά τη μετάβαση σε διακομιστές εμπορευμάτων, γνωρίζαμε ότι ήταν λιγότερο αξιόπιστοι. Επομένως, κατά τη δημιουργία μιας νέας αρχιτεκτονικής, υποθέσαμε εκ των προτέρων την πιθανότητα αποτυχίας ενός ή περισσότερων κόμβων. Ως εκ τούτου, χρειαζόταν ένα ζεστό σύστημα αναμονής που θα μπορούσε πολύ γρήγορα να μεταβεί σε εφεδρικές μηχανές.
Επιπλέον, υπήρχαν άλλες απαιτήσεις:
- Σε καμία περίπτωση δεν πρέπει να χάσετε τις επεξεργασμένες συναλλαγές.
- Το σύστημα πρέπει να είναι απολύτως διαφανές για τις υποδομές μας.
- Οι πελάτες δεν πρέπει να βλέπουν τις διακοπείσες συνδέσεις.
- Οι κρατήσεις δεν θα πρέπει να επιφέρουν σημαντική καθυστέρηση, επειδή αυτός είναι ένας κρίσιμος παράγοντας για την ανταλλαγή.
Κατά τη δημιουργία ενός συστήματος ζεστής αναμονής, δεν θεωρήσαμε τέτοια σενάρια ως διπλές αποτυχίες (για παράδειγμα, το δίκτυο σε έναν διακομιστή σταμάτησε να λειτουργεί και ο κύριος διακομιστής πάγωσε). δεν εξέτασε την πιθανότητα σφαλμάτων στο λογισμικό επειδή εντοπίζονται κατά τη διάρκεια της δοκιμής. και δεν έλαβε υπόψη τη λανθασμένη λειτουργία του υλικού.
Ως αποτέλεσμα, καταλήξαμε στο ακόλουθο σχήμα:
- Ο κύριος διακομιστής αλληλεπιδρούσε απευθείας με τους διακομιστές Gateway.
- Όλες οι συναλλαγές που ελήφθησαν στον κύριο διακομιστή αντιγράφηκαν αμέσως στον εφεδρικό διακομιστή μέσω ενός ξεχωριστού καναλιού. Ο διαιτητής (Κυβερνήτης) συντόνιζε τη μετάβαση σε περίπτωση που προέκυπταν προβλήματα.
- Ο κύριος διακομιστής επεξεργαζόταν κάθε συναλλαγή και περίμενε επιβεβαίωση από τον εφεδρικό διακομιστή. Για να μειώσουμε την καθυστέρηση στο ελάχιστο, αποφύγαμε να περιμένουμε την ολοκλήρωση της συναλλαγής στον εφεδρικό διακομιστή. Δεδομένου ότι ο χρόνος που χρειάστηκε για να ταξιδέψει μια συναλλαγή στο δίκτυο ήταν συγκρίσιμος με τον χρόνο εκτέλεσης, δεν προστέθηκε επιπλέον καθυστέρηση.
- Μπορούσαμε να ελέγξουμε μόνο την κατάσταση επεξεργασίας του κύριου και του εφεδρικού διακομιστή για την προηγούμενη συναλλαγή και η κατάσταση επεξεργασίας της τρέχουσας συναλλαγής ήταν άγνωστη. Εφόσον εξακολουθούσαμε να χρησιμοποιούσαμε διεργασίες με ένα νήμα, η αναμονή για απάντηση από το Backup θα είχε επιβραδύνει ολόκληρη τη ροή επεξεργασίας, επομένως κάναμε έναν εύλογο συμβιβασμό: ελέγξαμε το αποτέλεσμα της προηγούμενης συναλλαγής.
Το σχέδιο λειτούργησε ως εξής.
Ας υποθέσουμε ότι ο κύριος διακομιστής σταματά να ανταποκρίνεται, αλλά τα Gateways συνεχίζουν να επικοινωνούν. Παρουσιάζεται ένα χρονικό όριο λήξης στον εφεδρικό διακομιστή, επικοινωνεί με τον κυβερνήτη, ο οποίος του αναθέτει το ρόλο του κύριου διακομιστή και όλες οι πύλες μεταβαίνουν στον νέο κύριο διακομιστή.
Εάν ο κύριος διακομιστής επανέλθει στο διαδίκτυο, ενεργοποιεί επίσης ένα εσωτερικό χρονικό όριο λήξης, επειδή δεν υπήρξαν κλήσεις προς τον διακομιστή από την πύλη για ορισμένο χρονικό διάστημα. Στη συνέχεια απευθύνεται και στον Κυβερνήτη και τον αποκλείει από το σχέδιο. Ως αποτέλεσμα, η ανταλλαγή λειτουργεί με έναν διακομιστή μέχρι το τέλος της περιόδου συναλλαγών. Δεδομένου ότι η πιθανότητα αποτυχίας διακομιστή είναι αρκετά χαμηλή, αυτό το σχήμα θεωρήθηκε αρκετά αποδεκτό· δεν περιείχε πολύπλοκη λογική και ήταν εύκολο να δοκιμαστεί.
Συνεχίζεται.
Πηγή: www.habr.com