Αυτή είναι η συνέχεια μιας μακράς ιστορίας για την ακανθώδες πορεία μας προς τη δημιουργία ενός ισχυρού συστήματος υψηλού φορτίου που διασφαλίζει τη λειτουργία του Exchange. Το πρώτο μέρος είναι εδώ:
Μυστηριώδες λάθος
Μετά από πολυάριθμες δοκιμές, το ενημερωμένο σύστημα συναλλαγών και εκκαθάρισης τέθηκε σε λειτουργία και βρεθήκαμε αντιμέτωποι με ένα σφάλμα για το οποίο μπορούσαμε να γράψουμε μια αστυνομική-μυστική ιστορία.
Λίγο μετά την εκκίνηση στον κύριο διακομιστή, μια από τις συναλλαγές υποβλήθηκε σε επεξεργασία με σφάλμα. Ωστόσο, όλα ήταν καλά στον εφεδρικό διακομιστή. Αποδείχθηκε ότι μια απλή μαθηματική πράξη υπολογισμού του εκθέτη στον κύριο διακομιστή έδωσε αρνητικό αποτέλεσμα από το πραγματικό όρισμα! Συνεχίσαμε την έρευνά μας και στον καταχωρητή SSE2 βρήκαμε μια διαφορά σε ένα bit, το οποίο είναι υπεύθυνο για τη στρογγυλοποίηση κατά την εργασία με αριθμούς κινητής υποδιαστολής.
Γράψαμε ένα απλό βοηθητικό πρόγραμμα δοκιμής για τον υπολογισμό του εκθέτη με το σύνολο bit στρογγυλοποίησης. Αποδείχθηκε ότι στην έκδοση του RedHat Linux που χρησιμοποιήσαμε, υπήρχε σφάλμα κατά την εργασία με τη μαθηματική συνάρτηση όταν εισήχθη το άμοιρο bit. Το αναφέραμε στο RedHat, μετά από λίγο λάβαμε ένα patch από αυτούς και το κυκλοφορήσαμε. Το σφάλμα δεν παρουσιάστηκε πλέον, αλλά δεν ήταν σαφές από πού προήλθε αυτό το κομμάτι; Η λειτουργία ήταν υπεύθυνη για αυτό fesetround από τη γλώσσα C. Αναλύσαμε προσεκτικά τον κώδικά μας αναζητώντας το υποτιθέμενο σφάλμα: ελέγξαμε όλες τις πιθανές καταστάσεις. εξέτασε όλες τις συναρτήσεις που χρησιμοποιούσαν στρογγυλοποίηση. προσπάθησε να αναπαράγει μια αποτυχημένη συνεδρία. χρησιμοποίησε διαφορετικούς μεταγλωττιστές με διαφορετικές επιλογές. Χρησιμοποιήθηκε στατική και δυναμική ανάλυση.
Δεν ήταν δυνατή η εύρεση της αιτίας του σφάλματος.
Στη συνέχεια άρχισαν να ελέγχουν το υλικό: πραγματοποίησαν δοκιμή φορτίου των επεξεργαστών. Έλεγξε τη μνήμη RAM. Πραγματοποιήσαμε ακόμη και δοκιμές για το πολύ απίθανο σενάριο ενός σφάλματος πολλών bit σε ένα κελί. Μάταια.
Στο τέλος, καταλήξαμε σε μια θεωρία από τον κόσμο της φυσικής υψηλής ενέργειας: κάποιο σωματίδιο υψηλής ενέργειας πέταξε στο κέντρο δεδομένων μας, τρύπησε τον τοίχο της θήκης, χτύπησε τον επεξεργαστή και έκανε το μάνδαλο της σκανδάλης να κολλήσει σε αυτό ακριβώς το κομμάτι. Αυτή η παράλογη θεωρία ονομάστηκε «νετρίνο». Εάν είστε μακριά από τη σωματιδιακή φυσική: τα νετρίνα σχεδόν δεν αλληλεπιδρούν με τον έξω κόσμο και σίγουρα δεν μπορούν να επηρεάσουν τη λειτουργία του επεξεργαστή.
Δεδομένου ότι δεν ήταν δυνατό να βρεθεί η αιτία της αποτυχίας, ο "προσβλητικός" διακομιστής αφαιρέθηκε από τη λειτουργία για κάθε περίπτωση.
Μετά από κάποιο χρονικό διάστημα, αρχίσαμε να βελτιώνουμε το ζεστό σύστημα δημιουργίας αντιγράφων ασφαλείας: εισαγάγαμε τα λεγόμενα "θερμά αποθέματα" (ζεστά) - ασύγχρονα αντίγραφα. Έλαβαν μια ροή συναλλαγών που θα μπορούσαν να βρίσκονται σε διαφορετικά κέντρα δεδομένων, αλλά τα θερμά δεν αλληλεπιδρούσαν ενεργά με άλλους διακομιστές.
Γιατί έγινε αυτό; Εάν ο διακομιστής δημιουργίας αντιγράφων ασφαλείας αποτύχει, τότε το ζεστό συνδεδεμένο με τον κύριο διακομιστή γίνεται το νέο αντίγραφο ασφαλείας. Δηλαδή, μετά από μια αποτυχία, το σύστημα δεν παραμένει με έναν κύριο διακομιστή μέχρι το τέλος της περιόδου συναλλαγών.
Και όταν η νέα έκδοση του συστήματος δοκιμάστηκε και τέθηκε σε λειτουργία, παρουσιάστηκε ξανά το σφάλμα στρογγυλοποίησης bit. Επιπλέον, με την αύξηση του αριθμού των θερμών διακομιστών, το σφάλμα άρχισε να εμφανίζεται πιο συχνά. Ταυτόχρονα, ο πωλητής δεν είχε τίποτα να δείξει, αφού δεν υπήρχαν συγκεκριμένα στοιχεία.
Κατά την επόμενη ανάλυση της κατάστασης, προέκυψε μια θεωρία ότι το πρόβλημα θα μπορούσε να σχετίζεται με το ΛΣ. Γράψαμε ένα απλό πρόγραμμα που καλεί μια συνάρτηση σε έναν ατελείωτο βρόχο fesetround, θυμάται την τρέχουσα κατάσταση και την ελέγχει μέσω του ύπνου, και αυτό γίνεται σε πολλά ανταγωνιστικά νήματα. Έχοντας επιλέξει τις παραμέτρους για τον ύπνο και τον αριθμό των νημάτων, αρχίσαμε να αναπαράγουμε με συνέπεια την αποτυχία του bit μετά από περίπου 5 λεπτά λειτουργίας του βοηθητικού προγράμματος. Ωστόσο, η υποστήριξη της Red Hat δεν μπόρεσε να την αναπαράγει. Η δοκιμή των άλλων διακομιστών μας έδειξε ότι μόνο εκείνοι με συγκεκριμένους επεξεργαστές είναι επιρρεπείς στο σφάλμα. Ταυτόχρονα, η μετάβαση σε νέο πυρήνα έλυσε το πρόβλημα. Στο τέλος, απλώς αντικαταστήσαμε το λειτουργικό σύστημα και η πραγματική αιτία του σφάλματος παρέμεινε ασαφής.
Και ξαφνικά πέρυσι δημοσιεύτηκε ένα άρθρο στο Habré "" Η κατάσταση που περιγράφεται σε αυτό ήταν πολύ παρόμοια με τη δική μας, αλλά ο συγγραφέας προχώρησε περαιτέρω την έρευνα και πρότεινε μια θεωρία ότι το σφάλμα ήταν στον μικροκώδικα. Και όταν οι πυρήνες Linux ενημερώνονται, οι κατασκευαστές ενημερώνουν επίσης τον μικροκώδικα.
Περαιτέρω ανάπτυξη του συστήματος
Αν και απαλλαγήκαμε από το σφάλμα, αυτή η ιστορία μας ανάγκασε να επανεξετάσουμε την αρχιτεκτονική του συστήματος. Άλλωστε δεν προστατευτήκαμε από την επανάληψη τέτοιων σφαλμάτων.
Οι ακόλουθες αρχές αποτέλεσαν τη βάση για τις επόμενες βελτιώσεις στο σύστημα κρατήσεων:
- Δεν μπορείς να εμπιστευτείς κανέναν. Οι διακομιστές ενδέχεται να μην λειτουργούν σωστά.
- Επιφύλαξη της πλειοψηφίας.
- Εξασφάλιση συναίνεσης. Ως λογική προσθήκη στην κράτηση της πλειοψηφίας.
- Είναι πιθανές διπλές αποτυχίες.
- Ζωτικότητα. Το νέο πρόγραμμα hot standby δεν πρέπει να είναι χειρότερο από το προηγούμενο. Οι συναλλαγές θα πρέπει να συνεχίζονται χωρίς διακοπή μέχρι τον τελευταίο διακομιστή.
- Μικρή αύξηση της καθυστέρησης. Οποιαδήποτε διακοπή λειτουργίας συνεπάγεται τεράστιες οικονομικές απώλειες.
- Ελάχιστη αλληλεπίδραση δικτύου για να διατηρηθεί η καθυστέρηση όσο το δυνατόν χαμηλότερη.
- Επιλογή νέου κύριου διακομιστή σε δευτερόλεπτα.
Καμία από τις λύσεις που διατίθενται στην αγορά δεν μας ταίριαζε και το πρωτόκολλο Raft ήταν ακόμα στα σπάργανα, οπότε δημιουργήσαμε τη δική μας λύση.
Δικτύωση
Εκτός από το σύστημα κρατήσεων, ξεκινήσαμε τον εκσυγχρονισμό της αλληλεπίδρασης δικτύου. Το υποσύστημα I/O αποτελούνταν από πολλές διεργασίες, οι οποίες είχαν τη χειρότερη επίδραση στο jitter και στην καθυστέρηση. Με εκατοντάδες διεργασίες που χειρίζονται συνδέσεις TCP, αναγκαστήκαμε να αλλάζουμε συνεχώς μεταξύ τους και σε κλίμακα μικροδευτερόλεπτου αυτή είναι μια μάλλον χρονοβόρα λειτουργία. Αλλά το χειρότερο μέρος είναι ότι όταν μια διεργασία λάμβανε ένα πακέτο για επεξεργασία, το έστελνε σε μια ουρά SystemV και μετά περίμενε ένα συμβάν από μια άλλη ουρά SystemV. Ωστόσο, όταν υπάρχει μεγάλος αριθμός κόμβων, η άφιξη ενός νέου πακέτου TCP σε μια διαδικασία και η λήψη δεδομένων στην ουρά σε μια άλλη αντιπροσωπεύουν δύο ανταγωνιστικά συμβάντα για το λειτουργικό σύστημα. Σε αυτήν την περίπτωση, εάν δεν υπάρχουν διαθέσιμοι φυσικοί επεξεργαστές και για τις δύο εργασίες, ο ένας θα υποβληθεί σε επεξεργασία και ο δεύτερος θα τοποθετηθεί σε μια ουρά αναμονής. Είναι αδύνατο να προβλέψουμε τις συνέπειες.
Σε τέτοιες περιπτώσεις, μπορεί να χρησιμοποιηθεί δυναμικός έλεγχος προτεραιότητας διεργασιών, αλλά αυτό θα απαιτήσει τη χρήση κλήσεων συστήματος με ένταση πόρων. Ως αποτέλεσμα, μεταβήκαμε σε ένα νήμα χρησιμοποιώντας το κλασικό epoll, αυτό αύξησε σημαντικά την ταχύτητα και μείωσε τον χρόνο επεξεργασίας των συναλλαγών. Επίσης, απαλλαγήκαμε από ξεχωριστές διαδικασίες επικοινωνίας δικτύου και επικοινωνία μέσω του SystemV, μειώσαμε σημαντικά τον αριθμό των κλήσεων συστήματος και αρχίσαμε να ελέγχουμε τις προτεραιότητες των λειτουργιών. Μόνο στο υποσύστημα I/O, ήταν δυνατή η εξοικονόμηση περίπου 8-17 μικροδευτερόλεπτων, ανάλογα με το σενάριο. Αυτό το σχήμα μονού νήματος έχει χρησιμοποιηθεί αμετάβλητο από τότε· ένα νήμα epoll με περιθώριο είναι αρκετό για την εξυπηρέτηση όλων των συνδέσεων.
Επεξεργασία συναλλαγών
Το αυξανόμενο φορτίο στο σύστημά μας απαιτούσε αναβάθμιση σχεδόν όλων των στοιχείων του. Όμως, δυστυχώς, η στασιμότητα στην αύξηση των ταχυτήτων του ρολογιού των επεξεργαστών τα τελευταία χρόνια δεν επέτρεψε πλέον να κλιμακωθούν οι διαδικασίες κατά μέτωπο. Ως εκ τούτου, αποφασίσαμε να χωρίσουμε τη διαδικασία Engine σε τρία επίπεδα, με το πιο απασχολημένο από αυτά να είναι το σύστημα ελέγχου κινδύνου, το οποίο αξιολογεί τη διαθεσιμότητα κεφαλαίων σε λογαριασμούς και δημιουργεί τις ίδιες τις συναλλαγές. Αλλά τα χρήματα μπορούν να είναι σε διαφορετικά νομίσματα και ήταν απαραίτητο να καταλάβουμε σε ποια βάση θα έπρεπε να χωριστεί η επεξεργασία των αιτημάτων.
Η λογική λύση είναι να το διαιρέσουμε ανά νόμισμα: ένας διακομιστής διαπραγματεύεται σε δολάρια, ένας άλλος σε λίρες και ένας τρίτος σε ευρώ. Αλλά εάν, με ένα τέτοιο σχήμα, αποστέλλονται δύο συναλλαγές για την αγορά διαφορετικών νομισμάτων, τότε θα προκύψει το πρόβλημα του αποσυγχρονισμού του πορτοφολιού. Αλλά ο συγχρονισμός είναι δύσκολος και ακριβός. Επομένως, θα ήταν σωστό να μοιράζεστε χωριστά ανά πορτοφόλια και ξεχωριστά ανά όργανα. Παρεμπιπτόντως, τα περισσότερα δυτικά χρηματιστήρια δεν έχουν το καθήκον να ελέγχουν τους κινδύνους τόσο αυστηρά όσο εμείς, επομένως τις περισσότερες φορές αυτό γίνεται εκτός σύνδεσης. Χρειαζόταν να εφαρμόσουμε την ηλεκτρονική επαλήθευση.
Ας εξηγήσουμε με ένα παράδειγμα. Ένας έμπορος θέλει να αγοράσει 30 $ και το αίτημα πηγαίνει στην επικύρωση συναλλαγής: ελέγχουμε εάν επιτρέπεται σε αυτόν τον έμπορο σε αυτήν τη λειτουργία συναλλαγών και αν έχει τα απαραίτητα δικαιώματα. Εάν όλα είναι εντάξει, το αίτημα πηγαίνει στο σύστημα επαλήθευσης κινδύνου, π.χ. να ελέγξει την επάρκεια των κεφαλαίων για την ολοκλήρωση μιας συναλλαγής. Υπάρχει μια σημείωση ότι το απαιτούμενο ποσό είναι προς το παρόν δεσμευμένο. Στη συνέχεια, το αίτημα προωθείται στο σύστημα συναλλαγών, το οποίο εγκρίνει ή απορρίπτει τη συναλλαγή. Ας υποθέσουμε ότι η συναλλαγή έχει εγκριθεί - τότε το σύστημα επαλήθευσης κινδύνου σηματοδοτεί ότι τα χρήματα ξεμπλοκάρονται και τα ρούβλια μετατρέπονται σε δολάρια.
Γενικά, το σύστημα ελέγχου κινδύνων περιέχει πολύπλοκους αλγόριθμους και εκτελεί μεγάλο αριθμό υπολογισμών με μεγάλη ένταση πόρων και δεν ελέγχει απλώς το «υπόλοιπο λογαριασμού», όπως μπορεί να φαίνεται με την πρώτη ματιά.
Όταν ξεκινήσαμε να χωρίζουμε τη διαδικασία Engine σε επίπεδα, αντιμετωπίσαμε ένα πρόβλημα: ο κώδικας που ήταν διαθέσιμος εκείνη τη στιγμή χρησιμοποιούσε ενεργά την ίδια σειρά δεδομένων στα στάδια επικύρωσης και επαλήθευσης, κάτι που απαιτούσε την επανεγγραφή ολόκληρης της βάσης κώδικα. Ως αποτέλεσμα, δανειστήκαμε μια τεχνική για την επεξεργασία οδηγιών από σύγχρονους επεξεργαστές: καθένας από αυτούς χωρίζεται σε μικρά στάδια και πολλές ενέργειες εκτελούνται παράλληλα σε έναν κύκλο.
Μετά από μια μικρή προσαρμογή του κώδικα, δημιουργήσαμε μια διοχέτευση για παράλληλη επεξεργασία συναλλαγών, στην οποία η συναλλαγή χωρίστηκε σε 4 στάδια του αγωγού: αλληλεπίδραση δικτύου, επικύρωση, εκτέλεση και δημοσίευση του αποτελέσματος
Ας δούμε ένα παράδειγμα. Έχουμε δύο συστήματα επεξεργασίας, σειριακό και παράλληλο. Η πρώτη συναλλαγή φτάνει και αποστέλλεται για επικύρωση και στα δύο συστήματα. Η δεύτερη συναλλαγή φτάνει αμέσως: σε ένα παράλληλο σύστημα μεταφέρεται αμέσως σε λειτουργία και σε ένα διαδοχικό σύστημα τίθεται σε μια ουρά περιμένοντας να περάσει η πρώτη συναλλαγή από το τρέχον στάδιο επεξεργασίας. Δηλαδή, το κύριο πλεονέκτημα της επεξεργασίας αγωγών είναι ότι επεξεργαζόμαστε πιο γρήγορα την ουρά συναλλαγών.
Έτσι καταλήξαμε στο σύστημα ASTS+.
Είναι αλήθεια ότι δεν είναι όλα τόσο ομαλά ούτε με τους μεταφορείς. Ας υποθέσουμε ότι έχουμε μια συναλλαγή που επηρεάζει τους πίνακες δεδομένων σε μια γειτονική συναλλαγή· αυτή είναι μια τυπική κατάσταση για μια ανταλλαγή. Μια τέτοια συναλλαγή δεν μπορεί να εκτελεστεί σε έναν αγωγό γιατί μπορεί να επηρεάσει άλλους. Αυτή η κατάσταση ονομάζεται κίνδυνος δεδομένων και τέτοιες συναλλαγές απλώς επεξεργάζονται ξεχωριστά: όταν τελειώσουν οι «γρήγορες» συναλλαγές στην ουρά, η διοχέτευση σταματά, το σύστημα επεξεργάζεται την «αργή» συναλλαγή και, στη συνέχεια, ξεκινά ξανά τη διοχέτευση. Ευτυχώς, το ποσοστό τέτοιων συναλλαγών στη συνολική ροή είναι πολύ μικρό, επομένως ο αγωγός σταματάει τόσο σπάνια που δεν επηρεάζει τη συνολική απόδοση.
Στη συνέχεια, αρχίσαμε να λύνουμε το πρόβλημα του συγχρονισμού τριών νημάτων εκτέλεσης. Το αποτέλεσμα ήταν ένα σύστημα βασισμένο σε ένα buffer δακτυλίου με κελιά σταθερού μεγέθους. Σε αυτό το σύστημα, τα πάντα υπόκεινται σε ταχύτητα επεξεργασίας· τα δεδομένα δεν αντιγράφονται.
- Όλα τα εισερχόμενα πακέτα δικτύου εισέρχονται στο στάδιο της κατανομής.
- Τα τοποθετούμε σε έναν πίνακα και τα σημειώνουμε ως διαθέσιμα για το στάδιο #1.
- Η δεύτερη συναλλαγή έφτασε, είναι και πάλι διαθέσιμη για το στάδιο Νο. 1.
- Το πρώτο νήμα επεξεργασίας βλέπει τις διαθέσιμες συναλλαγές, τις επεξεργάζεται και τις μετακινεί στο επόμενο στάδιο του δεύτερου νήματος επεξεργασίας.
- Στη συνέχεια επεξεργάζεται την πρώτη συναλλαγή και επισημαίνει το αντίστοιχο κελί
deleted— είναι πλέον διαθέσιμο για νέα χρήση.
Ολόκληρη η ουρά επεξεργάζεται με αυτόν τον τρόπο.
Η επεξεργασία κάθε σταδίου διαρκεί μονάδες ή δεκάδες μικροδευτερόλεπτα. Και αν χρησιμοποιήσουμε τυπικά σχήματα συγχρονισμού λειτουργικού συστήματος, θα χάσουμε περισσότερο χρόνο στον ίδιο τον συγχρονισμό. Γι' αυτό ξεκινήσαμε να χρησιμοποιούμε το spinlock. Ωστόσο, αυτή είναι πολύ κακή μορφή σε ένα σύστημα σε πραγματικό χρόνο και η RedHat δεν συνιστά αυστηρά να το κάνετε αυτό, επομένως εφαρμόζουμε ένα spinlock για 100 ms και, στη συνέχεια, μεταβαίνουμε στη λειτουργία σηματοφόρου για να εξαλείψουμε την πιθανότητα αδιεξόδου.
Ως αποτέλεσμα, πετύχαμε απόδοση περίπου 8 εκατομμυρίων συναλλαγών ανά δευτερόλεπτο. Και κυριολεκτικά δύο μήνες αργότερα σχετικά με το LMAX Disruptor είδαμε μια περιγραφή ενός κυκλώματος με την ίδια λειτουργικότητα.
Τώρα θα μπορούσαν να υπάρχουν πολλά νήματα εκτέλεσης σε ένα στάδιο. Όλες οι συναλλαγές διεκπεραιώθηκαν μία προς μία, με τη σειρά που ελήφθησαν. Ως αποτέλεσμα, η κορυφαία απόδοση αυξήθηκε από 18 χιλιάδες σε 50 χιλιάδες συναλλαγές ανά δευτερόλεπτο.
Σύστημα διαχείρισης συναλλαγματικού κινδύνου
Δεν υπάρχει όριο στην τελειότητα και σύντομα ξεκινήσαμε ξανά τον εκσυγχρονισμό: στο πλαίσιο του ASTS+, αρχίσαμε να μεταφέρουμε τα συστήματα διαχείρισης κινδύνου και διακανονισμού σε αυτόνομα στοιχεία. Αναπτύξαμε μια ευέλικτη μοντέρνα αρχιτεκτονική και ένα νέο μοντέλο ιεραρχικού κινδύνου και προσπαθήσαμε να χρησιμοποιήσουμε την τάξη όπου ήταν δυνατόν fixed_point αντί για double.
Αλλά αμέσως προέκυψε ένα πρόβλημα: πώς να συγχρονίσετε όλη την επιχειρηματική λογική που λειτουργεί εδώ και πολλά χρόνια και να τη μεταφέρετε στο νέο σύστημα; Ως αποτέλεσμα, η πρώτη έκδοση του πρωτοτύπου του νέου συστήματος έπρεπε να εγκαταλειφθεί. Η δεύτερη έκδοση, η οποία αυτή τη στιγμή λειτουργεί στην παραγωγή, βασίζεται στον ίδιο κώδικα, ο οποίος λειτουργεί τόσο στο τμήμα συναλλαγών όσο και στο τμήμα κινδύνου. Κατά τη διάρκεια της ανάπτυξης, το πιο δύσκολο πράγμα που μπορούσε να γίνει ήταν η συγχώνευση git μεταξύ δύο εκδόσεων. Ο συνάδελφός μας Evgeniy Mazurenok έκανε αυτή την επέμβαση κάθε εβδομάδα και κάθε φορά έβριζε για πολύ μεγάλο χρονικό διάστημα.
Όταν επιλέγαμε ένα νέο σύστημα, έπρεπε αμέσως να λύσουμε το πρόβλημα της αλληλεπίδρασης. Κατά την επιλογή ενός διαύλου δεδομένων, ήταν απαραίτητο να διασφαλιστεί σταθερό jitter και ελάχιστη καθυστέρηση. Το δίκτυο InfiniBand RDMA ήταν το πλέον κατάλληλο για αυτό: ο μέσος χρόνος επεξεργασίας είναι 4 φορές μικρότερος από ό,τι στα δίκτυα Ethernet 10 G. Αλλά αυτό που πραγματικά μας συνεπήρε ήταν η διαφορά στα εκατοστημόρια - 99 και 99,9.
Φυσικά, το InfiniBand έχει τις προκλήσεις του. Πρώτον, ένα διαφορετικό API - ibverbs αντί για sockets. Δεύτερον, δεν υπάρχουν σχεδόν καθόλου ευρέως διαθέσιμες λύσεις ανταλλαγής μηνυμάτων ανοιχτού κώδικα. Προσπαθήσαμε να φτιάξουμε το δικό μας πρωτότυπο, αλλά αποδείχθηκε πολύ δύσκολο, οπότε επιλέξαμε μια εμπορική λύση - Confinity Low Latency Messaging (πρώην IBM MQ LLM).
Τότε προέκυψε το καθήκον της σωστής κατανομής του συστήματος κινδύνου. Εάν απλώς αφαιρέσετε το Risk Engine και δεν δημιουργήσετε έναν ενδιάμεσο κόμβο, τότε οι συναλλαγές από δύο πηγές μπορούν να αναμειχθούν.
Οι λεγόμενες λύσεις Ultra Low Latency έχουν μια λειτουργία αναδιάταξης: οι συναλλαγές από δύο πηγές μπορούν να διευθετηθούν με την απαιτούμενη σειρά κατά την παραλαβή· αυτό υλοποιείται χρησιμοποιώντας ένα ξεχωριστό κανάλι για την ανταλλαγή πληροφοριών σχετικά με την παραγγελία. Αλλά δεν χρησιμοποιούμε ακόμη αυτήν τη λειτουργία: περιπλέκει ολόκληρη τη διαδικασία και σε ορισμένες λύσεις δεν υποστηρίζεται καθόλου. Επιπλέον, σε κάθε συναλλαγή θα πρέπει να εκχωρούνται αντίστοιχες χρονικές σημάνσεις και στο σχήμα μας αυτός ο μηχανισμός είναι πολύ δύσκολο να εφαρμοστεί σωστά. Επομένως, χρησιμοποιήσαμε το κλασικό σχήμα με έναν μεσίτη μηνυμάτων, δηλαδή με έναν αποστολέα που διανέμει μηνύματα μεταξύ του Risk Engine.
Το δεύτερο πρόβλημα αφορούσε την πρόσβαση του πελάτη: εάν υπάρχουν πολλές πύλες κινδύνου, ο πελάτης πρέπει να συνδεθεί σε καθεμία από αυτές και αυτό θα απαιτήσει αλλαγές στο επίπεδο πελάτη. Θέλαμε να ξεφύγουμε από αυτό σε αυτό το στάδιο, επομένως ο τρέχων σχεδιασμός της πύλης κινδύνου επεξεργάζεται ολόκληρη τη ροή δεδομένων. Αυτό περιορίζει σημαντικά τη μέγιστη απόδοση, αλλά απλοποιεί σημαντικά την ενοποίηση του συστήματος.
Αναπαραγωγή σε πανομοιότυπο
Το σύστημά μας δεν πρέπει να έχει ένα μόνο σημείο αστοχίας, δηλαδή, όλα τα στοιχεία πρέπει να είναι διπλά, συμπεριλαμβανομένου του μεσίτη μηνυμάτων. Επιλύσαμε αυτό το πρόβλημα χρησιμοποιώντας το σύστημα CLLM: περιέχει ένα σύμπλεγμα RCMS στο οποίο δύο διεκπεραιωτές μπορούν να εργαστούν σε λειτουργία master-slave και όταν ο ένας αποτυγχάνει, το σύστημα μεταβαίνει αυτόματα στο άλλο.
Εργασία με ένα εφεδρικό κέντρο δεδομένων
Το InfiniBand είναι βελτιστοποιημένο για λειτουργία ως τοπικό δίκτυο, δηλαδή για σύνδεση εξοπλισμού rack-mount, και ένα δίκτυο InfiniBand δεν μπορεί να τοποθετηθεί μεταξύ δύο γεωγραφικά κατανεμημένων κέντρων δεδομένων. Ως εκ τούτου, εφαρμόσαμε μια γέφυρα/αποστολέα, η οποία συνδέεται με την αποθήκευση μηνυμάτων μέσω κανονικών δικτύων Ethernet και αναμεταδίδει όλες τις συναλλαγές σε ένα δεύτερο δίκτυο IB. Όταν χρειάζεται να πραγματοποιήσουμε μετεγκατάσταση από ένα κέντρο δεδομένων, μπορούμε να επιλέξουμε με ποιο κέντρο δεδομένων θα εργαστούμε τώρα.
Αποτελέσματα της
Όλα τα παραπάνω δεν έγιναν ταυτόχρονα· χρειάστηκαν αρκετές επαναλήψεις για την ανάπτυξη μιας νέας αρχιτεκτονικής. Δημιουργήσαμε το πρωτότυπο σε ένα μήνα, αλλά χρειάστηκαν περισσότερα από δύο χρόνια για να το φέρουμε σε λειτουργική κατάσταση. Προσπαθήσαμε να επιτύχουμε τον καλύτερο συμβιβασμό μεταξύ της αύξησης του χρόνου επεξεργασίας των συναλλαγών και της αύξησης της αξιοπιστίας του συστήματος.
Δεδομένου ότι το σύστημα ενημερώθηκε σε μεγάλο βαθμό, εφαρμόσαμε την ανάκτηση δεδομένων από δύο ανεξάρτητες πηγές. Εάν ο χώρος αποθήκευσης μηνυμάτων δεν λειτουργεί σωστά για κάποιο λόγο, μπορείτε να πάρετε το αρχείο καταγραφής συναλλαγών από μια δεύτερη πηγή - από τη Μηχανή κινδύνου. Αυτή η αρχή τηρείται σε όλο το σύστημα.
Μεταξύ άλλων, μπορέσαμε να διατηρήσουμε το API πελάτη, έτσι ώστε ούτε οι μεσίτες ούτε κανένας άλλος να απαιτούν σημαντική επανεξέταση για τη νέα αρχιτεκτονική. Χρειάστηκε να αλλάξουμε κάποιες διεπαφές, αλλά δεν χρειάστηκε να κάνουμε σημαντικές αλλαγές στο μοντέλο λειτουργίας.
Ονομάσαμε την τρέχουσα έκδοση της πλατφόρμας μας Rebus - ως συντομογραφία για τις δύο πιο αξιοσημείωτες καινοτομίες στην αρχιτεκτονική, Risk Engine και BUS.
Αρχικά, θέλαμε να διαθέσουμε μόνο το τμήμα εκκαθάρισης, αλλά το αποτέλεσμα ήταν ένα τεράστιο κατανεμημένο σύστημα. Οι πελάτες μπορούν πλέον να αλληλεπιδρούν είτε με την Πύλη Trade, την Πύλη Εκκαθάρισης ή και με τα δύο.
Τι πετύχαμε τελικά:
Μείωσε το επίπεδο καθυστέρησης. Με μικρό όγκο συναλλαγών, το σύστημα λειτουργεί όπως και η προηγούμενη έκδοση, αλλά ταυτόχρονα μπορεί να αντέξει πολύ μεγαλύτερο φορτίο.
Η κορυφαία απόδοση αυξήθηκε από 50 χιλιάδες σε 180 χιλιάδες συναλλαγές ανά δευτερόλεπτο. Μια περαιτέρω αύξηση παρεμποδίζεται από τη μοναδική ροή αντιστοίχισης παραγγελιών.
Υπάρχουν δύο τρόποι για περαιτέρω βελτίωση: παραλληλισμός αντιστοίχισης και αλλαγή του τρόπου λειτουργίας με το Gateway. Τώρα όλες οι πύλες λειτουργούν σύμφωνα με ένα σχήμα αναπαραγωγής, το οποίο, κάτω από ένα τέτοιο φορτίο, παύει να λειτουργεί κανονικά.
Τέλος, μπορώ να δώσω μερικές συμβουλές σε όσους ολοκληρώνουν τα εταιρικά συστήματα:
- Να είστε προετοιμασμένοι για το χειρότερο ανά πάσα στιγμή. Τα προβλήματα προκύπτουν πάντα απροσδόκητα.
- Συνήθως είναι αδύνατο να ξαναδημιουργηθεί γρήγορα η αρχιτεκτονική. Ειδικά αν χρειάζεται να επιτύχετε τη μέγιστη αξιοπιστία σε πολλούς δείκτες. Όσο περισσότεροι κόμβοι, τόσο περισσότεροι πόροι χρειάζονται για υποστήριξη.
- Όλες οι προσαρμοσμένες και αποκλειστικές λύσεις θα απαιτούν πρόσθετους πόρους για έρευνα, υποστήριξη και συντήρηση.
- Μην αναβάλλετε την επίλυση ζητημάτων αξιοπιστίας του συστήματος και ανάκτησης μετά από βλάβες· λάβετέ τα υπόψη στο αρχικό στάδιο του σχεδιασμού.
Πηγή: www.habr.com