Γειά σου! Το όνομά μου είναι Alexey Pyankov, είμαι προγραμματιστής στην εταιρεία Sportmaster. Σε αυτό Είπα πώς ξεκίνησαν οι εργασίες στον ιστότοπο του Sportmaster το 2012, ποιες πρωτοβουλίες καταφέραμε να «σπρώξουμε» και αντίστροφα, τι γκανιότα συγκεντρώσαμε.
Σήμερα θέλω να μοιραστώ τις σκέψεις που ακολουθούν ένα άλλο θέμα - την επιλογή ενός συστήματος προσωρινής αποθήκευσης για το java backend στον πίνακα διαχείρισης του ιστότοπου. Αυτή η πλοκή έχει ένα ιδιαίτερο νόημα για μένα - αν και η ιστορία εκτυλίχθηκε μόνο για 2 μήνες, αυτές τις 60 ημέρες δουλέψαμε 12-16 ώρες και χωρίς ούτε μια μέρα άδεια. Ποτέ δεν είχα σκεφτεί ή φανταστεί ότι ήταν δυνατόν να δουλέψω τόσο σκληρά.
Ως εκ τούτου, χωρίζω το κείμενο σε 2 μέρη για να μην το φορτώσω εντελώς. Αντίθετα, το πρώτο μέρος θα είναι πολύ ελαφρύ - προετοιμασία, εισαγωγή, κάποιες σκέψεις σχετικά με το τι είναι η προσωρινή αποθήκευση. Εάν είστε ήδη έμπειρος προγραμματιστής ή έχετε εργαστεί με κρυφές μνήμες, από τεχνικής πλευράς πιθανότατα δεν θα υπάρχει τίποτα νέο σε αυτό το άρθρο. Αλλά για έναν junior, μια τόσο μικρή κριτική μπορεί να του πει ποια κατεύθυνση να κοιτάξει αν βρεθεί σε ένα τέτοιο σταυροδρόμι.
Όταν τέθηκε σε παραγωγή η νέα έκδοση του ιστότοπου Sportmaster, τα δεδομένα ελήφθησαν με τρόπο που, για να το θέσω ήπια, δεν ήταν πολύ βολικό. Η βάση ήταν πίνακες που προετοιμάστηκαν για την προηγούμενη έκδοση του ιστότοπου (Bitrix), οι οποίοι έπρεπε να τραβηχτούν στο ETL, να έρθουν σε νέα μορφή και να εμπλουτιστούν με διάφορα μικροπράγματα από μια ντουζίνα ακόμη συστήματα. Για να εμφανιστεί μια νέα εικόνα ή περιγραφή προϊόντος στον ιστότοπο, έπρεπε να περιμένετε μέχρι την επόμενη μέρα - ενημερώσεις μόνο τη νύχτα, μία φορά την ημέρα.
Στην αρχή, υπήρχαν τόσες πολλές ανησυχίες από τις πρώτες εβδομάδες της παραγωγής, που τέτοιες ταλαιπωρίες για τους διαχειριστές περιεχομένου ήταν ασήμαντο. Αλλά, μόλις όλα λύθηκαν, η ανάπτυξη του έργου συνεχίστηκε - λίγους μήνες αργότερα, στις αρχές του 2015, αρχίσαμε να αναπτύσσουμε ενεργά τον πίνακα διαχείρισης. Το 2015 και το 2016, όλα πάνε καλά, κυκλοφορούμε τακτικά, ο πίνακας διαχείρισης καλύπτει όλο και περισσότερο την προετοιμασία των δεδομένων και προετοιμαζόμαστε για το γεγονός ότι σύντομα στην ομάδα μας θα ανατεθεί το πιο σημαντικό και πολύπλοκο πράγμα - το προϊόν κύκλωμα (πλήρης προετοιμασία και συντήρηση δεδομένων για όλα τα προϊόντα). Όμως το καλοκαίρι του 2017, λίγο πριν την έναρξη του κυκλώματος εμπορευμάτων, το έργο θα βρεθεί σε πολύ δύσκολη κατάσταση - ακριβώς λόγω προβλημάτων με την προσωρινή αποθήκευση. Θέλω να μιλήσω για αυτό το επεισόδιο στο δεύτερο μέρος αυτής της έκδοσης που αποτελείται από δύο μέρη.
Αλλά σε αυτή την ανάρτηση θα ξεκινήσω από μακριά, θα παρουσιάσω μερικές σκέψεις - ιδέες για την προσωρινή αποθήκευση, που θα ήταν ένα καλό βήμα για να μετακινηθείτε πριν από ένα μεγάλο έργο.
Όταν εμφανίζεται μια εργασία προσωρινής αποθήκευσης
Η εργασία προσωρινής αποθήκευσης δεν εμφανίζεται απλώς. Είμαστε προγραμματιστές, γράφουμε ένα προϊόν λογισμικού και θέλουμε να είναι σε ζήτηση. Εάν το προϊόν είναι σε ζήτηση και είναι επιτυχημένο, οι χρήστες θα έρθουν. Και όλο και περισσότερα έρχονται. Και τότε υπάρχουν πολλοί χρήστες και τότε το προϊόν φορτώνεται πολύ.
Στα πρώτα στάδια, δεν σκεφτόμαστε τη βελτιστοποίηση και την απόδοση κώδικα. Το κύριο πράγμα είναι η λειτουργικότητα, η γρήγορη ανάπτυξη ενός πιλότου και η δοκιμή υποθέσεων. Και αν το φορτίο αυξηθεί, αντλούμε το σίδερο. Το αυξάνουμε δύο ή τρεις φορές, πέντε φορές, ίσως και 10 φορές. Κάπου εδώ - τα οικονομικά δεν θα το επιτρέπουν πια. Πόσες φορές θα αυξηθεί ο αριθμός των χρηστών; Δεν θα είναι σαν το 2-5-10, αλλά αν πετύχει, θα είναι από 100-1000 έως 100 χιλιάδες φορές. Δηλαδή, αργά ή γρήγορα, θα πρέπει να κάνετε βελτιστοποίηση.
Ας υποθέσουμε ότι κάποιο μέρος του κώδικα (ας το ονομάσουμε αυτό το τμήμα συνάρτηση) διαρκεί πολύ μεγάλο χρονικό διάστημα και θέλουμε να μειώσουμε τον χρόνο εκτέλεσης. Μια συνάρτηση μπορεί να είναι πρόσβαση σε μια βάση δεδομένων ή μπορεί να είναι η εκτέλεση κάποιας πολύπλοκης λογικής - το κύριο πράγμα είναι ότι χρειάζεται πολύς χρόνος για να ολοκληρωθεί. Πόσο μπορείτε να μειώσετε τον χρόνο εκτέλεσης; Στο όριο, μπορείτε να το μειώσετε στο μηδέν, όχι περισσότερο. Πώς μπορείτε να μειώσετε το χρόνο εκτέλεσης στο μηδέν; Απάντηση: εξάλειψη της εκτέλεσης εντελώς. Αντίθετα, επιστρέψτε αμέσως το αποτέλεσμα. Πώς μπορείτε να μάθετε το αποτέλεσμα; Απάντηση: είτε υπολογίστε το είτε ψάξτε κάπου. Χρειάζεται πολύς χρόνος για τον υπολογισμό. Και το να κατασκοπεύεις είναι, για παράδειγμα, να θυμάσαι το αποτέλεσμα που παρήγαγε η συνάρτηση την τελευταία φορά όταν κλήθηκε με τις ίδιες παραμέτρους.
Δηλαδή, η υλοποίηση της συνάρτησης δεν είναι σημαντική για εμάς. Αρκεί απλώς να γνωρίζουμε από ποιες παραμέτρους εξαρτάται το αποτέλεσμα. Στη συνέχεια, εάν οι τιμές των παραμέτρων αντιπροσωπεύονται με τη μορφή ενός αντικειμένου που μπορεί να χρησιμοποιηθεί ως κλειδί σε κάποιο χώρο αποθήκευσης, τότε το αποτέλεσμα του υπολογισμού μπορεί να αποθηκευτεί και να διαβαστεί την επόμενη φορά που θα αποκτήσετε πρόσβαση. Αν αυτή η εγγραφή και η ανάγνωση του αποτελέσματος είναι πιο γρήγορη από την εκτέλεση της συνάρτησης, έχουμε κέρδος από άποψη ταχύτητας. Το ποσό του κέρδους μπορεί να φτάσει τις 100, 1000 και 100 χιλιάδες φορές (το 10^5 είναι μάλλον εξαίρεση, αλλά στην περίπτωση μιας αρκετά καθυστερημένης βάσης, είναι πολύ πιθανό).
Βασικές απαιτήσεις για ένα σύστημα προσωρινής αποθήκευσης
Το πρώτο πράγμα που μπορεί να γίνει απαίτηση για ένα σύστημα προσωρινής αποθήκευσης είναι η γρήγορη ταχύτητα ανάγνωσης και, σε ελαφρώς μικρότερο βαθμό, η ταχύτητα εγγραφής. Αυτό είναι αλήθεια, αλλά μόνο έως ότου περάσουμε το σύστημα στην παραγωγή.
Ας παίξουμε αυτή την υπόθεση.
Ας υποθέσουμε ότι παρέχουμε το τρέχον φορτίο με υλικό και τώρα εισάγουμε σταδιακά την προσωρινή αποθήκευση. Ο αριθμός των χρηστών μεγαλώνει λίγο, το φορτίο μεγαλώνει - προσθέτουμε λίγο κρυφές μνήμες, το βιδώνουμε εδώ κι εκεί. Αυτό συνεχίζεται για κάποιο χρονικό διάστημα και τώρα οι βαριές λειτουργίες ουσιαστικά δεν καλούνται πλέον - ολόκληρο το κύριο φορτίο πέφτει στη μνήμη cache. Ο αριθμός των χρηστών κατά τη διάρκεια αυτής της περιόδου έχει αυξηθεί N φορές.
Και αν η αρχική παροχή υλικού θα μπορούσε να είναι 2-5 φορές, τότε με τη βοήθεια της κρυφής μνήμης θα μπορούσαμε να βελτιώσουμε την απόδοση κατά 10 ή, σε καλή περίπτωση, κατά 100, σε ορισμένα σημεία ίσως κατά έναν παράγοντα των 1000. Δηλαδή, στο ίδιο υλικό – επεξεργαζόμαστε 100 φορές περισσότερα αιτήματα. Τέλεια, σου αξίζει το μελόψωμο!
Αλλά τώρα, σε μια ωραία στιγμή, κατά τύχη, το σύστημα κατέρρευσε και η κρυφή μνήμη κατέρρευσε. Τίποτα το ιδιαίτερο - τελικά, η προσωρινή μνήμη επιλέχθηκε με βάση την απαίτηση "υψηλή ταχύτητα ανάγνωσης και εγγραφής, τα υπόλοιπα δεν έχουν σημασία".
Σε σχέση με το φορτίο εκκίνησης, το απόθεμα σιδήρου μας ήταν 2-5 φορές και το φορτίο κατά τη διάρκεια αυτής της περιόδου αυξήθηκε 10-100 φορές. Χρησιμοποιώντας την προσωρινή μνήμη, εξαλείψαμε τις κλήσεις για βαριές λειτουργίες και επομένως όλα λειτούργησαν. Και τώρα, χωρίς προσωρινή μνήμη, πόσες φορές θα επιβραδύνει το σύστημά μας; Τι θα μας συμβεί; Το σύστημα θα πέσει.
Ακόμα κι αν η προσωρινή μας μνήμη δεν διακόπηκε, αλλά διαγράφηκε μόνο για λίγο, θα χρειαστεί να ζεσταθεί και αυτό θα πάρει λίγο χρόνο. Και κατά τη διάρκεια αυτής της περιόδου, το κύριο βάρος θα πέσει στη λειτουργικότητα.
Συμπέρασμα: τα έργα παραγωγής με υψηλό φορτίο απαιτούν ένα σύστημα προσωρινής αποθήκευσης όχι μόνο για να έχει υψηλές ταχύτητες ανάγνωσης και εγγραφής, αλλά και για να διασφαλίζει την ασφάλεια των δεδομένων και την αντοχή σε αστοχίες.
Η αγωνία της επιλογής
Σε ένα έργο με πίνακα διαχείρισης, η επιλογή έγινε ως εξής: πρώτα εγκαταστήσαμε το Hazelcast, γιατί Ήμασταν ήδη εξοικειωμένοι με αυτό το προϊόν από την εμπειρία του κύριου ιστότοπου. Αλλά εδώ αυτή η επιλογή αποδείχθηκε ανεπιτυχής - στο προφίλ φορτίου μας, το Hazelcast δεν είναι απλώς αργό, αλλά τρομερά αργό. Και τότε είχαμε ήδη εγγραφεί για την ημερομηνία κυκλοφορίας.
Spoiler: πώς ακριβώς εξελίχθηκαν οι συνθήκες που χάσαμε τόσο μεγάλη υπόθεση και καταλήξαμε σε μια οξεία και τεταμένη κατάσταση -θα σας πω στο δεύτερο μέρος- και πώς καταλήξαμε και πώς βγήκαμε. Αλλά τώρα - θα πω απλώς ότι ήταν πολύ άγχος και "να σκεφτώ - κατά κάποιο τρόπο δεν μπορώ να σκεφτώ, κουνάμε το μπουκάλι". Το "Shaking the bottle" είναι επίσης ένα spoiler, περισσότερα για αυτό αργότερα.
Τι κάναμε:
- Κάνουμε μια λίστα με όλα τα συστήματα που προτείνουν η Google και το StackOverflow. Λίγο πάνω από 30
- Γράφουμε δοκιμές με φορτίο τυπικό για την παραγωγή. Για να γίνει αυτό, καταγράψαμε δεδομένα που διέρχονται από το σύστημα σε περιβάλλον παραγωγής - ένα είδος ανιχνευτή δεδομένων όχι στο δίκτυο, αλλά μέσα στο σύστημα. Ακριβώς αυτά τα δεδομένα χρησιμοποιήθηκαν στις δοκιμές.
- Με όλη την ομάδα, όλοι επιλέγουν το επόμενο σύστημα από τη λίστα, το διαμορφώνουν και εκτελούν δοκιμές. Δεν περνάει τη δοκιμή, δεν κουβαλάει το φορτίο - το πετάμε και προχωράμε στο επόμενο στη σειρά.
- Στο 17ο σύστημα έγινε σαφές ότι όλα ήταν απελπιστικά. Σταμάτα να κουνάς το μπουκάλι, ήρθε η ώρα να σκεφτείς σοβαρά.
Αλλά αυτή είναι μια επιλογή όταν πρέπει να επιλέξετε ένα σύστημα που θα «ξεπεράσει την ταχύτητα» σε προπαρασκευασμένες δοκιμές. Τι γίνεται αν δεν υπάρχουν ακόμα τέτοιες δοκιμές και θέλετε να επιλέξετε γρήγορα;
Ας μοντελοποιήσουμε αυτήν την επιλογή (είναι δύσκολο να φανταστεί κανείς ότι ένας προγραμματιστής μεσαίου+ ζει στο κενό και τη στιγμή της επιλογής δεν έχει ακόμη επισημοποιήσει την προτίμησή του ως προς το ποιο προϊόν να δοκιμάσει πρώτο - επομένως, η περαιτέρω συλλογιστική είναι περισσότερο θεωρητικός/φιλοσοφία/ περίπου ένα junior).
Έχοντας αποφασίσει για τις απαιτήσεις, θα αρχίσουμε να επιλέγουμε μια λύση από το κουτί. Γιατί να εφεύρουμε ξανά τον τροχό: θα πάμε να πάρουμε ένα έτοιμο σύστημα προσωρινής αποθήκευσης.
Εάν μόλις ξεκινάτε και το γκουγκλάρετε, τότε δώστε ή πάρτε την παραγγελία, αλλά γενικά, οι οδηγίες θα είναι έτσι. Πρώτα απ' όλα θα συναντήσεις το Redis, ακούγεται παντού. Τότε θα μάθετε ότι το EhCache είναι το παλαιότερο και πιο αποδεδειγμένο σύστημα. Στη συνέχεια θα γράψουμε για το Tarantool, μια εγχώρια ανάπτυξη που έχει μια μοναδική πτυχή της λύσης. Και επίσης το Ignite, επειδή είναι τώρα σε άνοδο σε δημοτικότητα και απολαμβάνει την υποστήριξη της SberTech. Στο τέλος υπάρχει και η Hazelcast, γιατί στον κόσμο των επιχειρήσεων εμφανίζεται συχνά ανάμεσα σε μεγάλες εταιρείες.
Ο κατάλογος δεν είναι εξαντλητικός· υπάρχουν δεκάδες συστήματα. Και μόνο ένα θα βιδώνουμε. Ας πάρουμε τα 5 επιλεγμένα συστήματα για τον «διαγωνισμό ομορφιάς» και ας κάνουμε μια επιλογή. Ποιος θα είναι ο νικητής;
Ρέντη
Διαβάζουμε τι γράφουν στην επίσημη ιστοσελίδα.
- έργο ανοιχτού κώδικα. Προσφέρει αποθήκευση δεδομένων στη μνήμη, δυνατότητα αποθήκευσης στο δίσκο, αυτόματη κατάτμηση, υψηλή διαθεσιμότητα και ανάκτηση από διακοπές δικτύου.
Φαίνεται ότι όλα είναι καλά, μπορείτε να το πάρετε και να το βιδώσετε - ό,τι χρειάζεστε, κάνει. Αλλά για πλάκα, ας δούμε τους άλλους υποψήφιους.
EhCache
- «η πιο ευρέως χρησιμοποιούμενη κρυφή μνήμη για Java» (μετάφραση του σλόγκαν από τον επίσημο ιστότοπο). Επίσης ανοιχτού κώδικα. Και τότε καταλαβαίνουμε ότι το Redis δεν είναι για java, αλλά γενικό, και για να αλληλεπιδράσετε μαζί του χρειάζεστε ένα περιτύλιγμα. Και το EhCache θα είναι πιο βολικό. Τι άλλο υπόσχεται το σύστημα; Αξιοπιστία, αποδεδειγμένη, πλήρης λειτουργικότητα. Λοιπόν, είναι επίσης το πιο κοινό. Και αποθηκεύει προσωρινά terabyte δεδομένων.
Ο Redis έχει ξεχαστεί, είμαι έτοιμος να επιλέξω το EhCache.
Αλλά μια αίσθηση πατριωτισμού με ωθεί να δω τι είναι καλό για τον Tarantool.
Tarantool
- πληροί την ονομασία «πλατφόρμα ενοποίησης δεδομένων σε πραγματικό χρόνο». Ακούγεται πολύ περίπλοκο, επομένως διαβάζουμε τη σελίδα λεπτομερώς και βρίσκουμε μια δυνατή δήλωση: "Αποθηκεύει το 100% των δεδομένων στη μνήμη RAM." Αυτό θα πρέπει να εγείρει ερωτήματα - σε τελική ανάλυση, μπορεί να υπάρχουν πολύ περισσότερα δεδομένα από τη μνήμη. Η εξήγηση είναι ότι σημαίνει ότι το Tarantool δεν εκτελεί σειριοποίηση για την εγγραφή δεδομένων στο δίσκο από τη μνήμη. Αντίθετα, χρησιμοποιεί χαρακτηριστικά χαμηλού επιπέδου του συστήματος, όταν η μνήμη αντιστοιχίζεται απλώς σε ένα σύστημα αρχείων με πολύ καλή απόδοση I/O. Γενικά, έκαναν κάτι υπέροχο και δροσερό.
Ας δούμε τις υλοποιήσεις: Mail.ru εταιρικός αυτοκινητόδρομος, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Αν εξακολουθούσαν να υπάρχουν αμφιβολίες για το Tarantool, τότε η περίπτωση εφαρμογής στη Mastercard με τελειώνει. Παίρνω Tarantool.
Αλλά τέλος πάντων…
Ignite
… υπάρχουν κι άλλα , τιμολογείται ως "πλατφόρμα υπολογιστών στη μνήμη... ταχύτητες στη μνήμη σε petabyte δεδομένων." Υπάρχουν επίσης πολλά πλεονεκτήματα εδώ: κατανεμημένη κρυφή μνήμη στη μνήμη, η ταχύτερη αποθήκευση και προσωρινή μνήμη κλειδιού-τιμής, οριζόντια κλιμάκωση, υψηλή διαθεσιμότητα, αυστηρή ακεραιότητα. Σε γενικές γραμμές, αποδεικνύεται ότι το πιο γρήγορο είναι το Ignite.
Υλοποιήσεις: Sberbank, American Airlines, Yahoo! Ιαπωνία. Και μετά ανακαλύπτω ότι το Ignite δεν εφαρμόζεται μόνο στη Sberbank, αλλά η ομάδα της SberTech στέλνει τους ανθρώπους της στην ίδια την ομάδα Ignite για να βελτιώσουν το προϊόν. Αυτό είναι εντελώς συναρπαστικό και είμαι έτοιμος να πάρω το Ignite.
Είναι εντελώς ασαφές γιατί, κοιτάζω το πέμπτο σημείο.
φουντουκιά
Πηγαίνω στον ιστότοπο , ΑΝΑΓΝΩΣΗ. Και αποδεικνύεται ότι η πιο γρήγορη λύση για κατανεμημένη προσωρινή αποθήκευση είναι το Hazelcast. Είναι τάξεις μεγέθους ταχύτερη από όλες τις άλλες λύσεις και γενικά είναι πρωτοπόρος στον τομέα του πλέγματος δεδομένων στη μνήμη. Σε αυτό το πλαίσιο, το να παίρνεις κάτι άλλο δεν σημαίνει να σέβεσαι τον εαυτό σου. Χρησιμοποιεί επίσης πλεονάζουσα αποθήκευση δεδομένων για συνεχή λειτουργία του συμπλέγματος χωρίς απώλεια δεδομένων.
Αυτό ήταν, είμαι έτοιμος να πάρω το Hazelcast.
Σύγκριση
Αλλά αν κοιτάξετε, και οι πέντε υποψήφιοι περιγράφονται με τέτοιο τρόπο που καθένας από αυτούς είναι ο καλύτερος. Πώς να επιλέξετε; Μπορούμε να δούμε ποιο είναι το πιο δημοφιλές, να ψάξουμε για συγκρίσεις και ο πονοκέφαλος θα φύγει.
Βρίσκουμε ένα τέτοιο , επιλέξτε τα 5 συστήματά μας.
Εδώ ταξινομούνται: ο Redis είναι στην κορυφή, ο Hazelcast στη δεύτερη θέση, το Tarantool και το Ignite κερδίζουν δημοτικότητα, το EhCache ήταν και παραμένει το ίδιο.
Ας δούμε όμως : σύνδεσμοι σε ιστότοπους, γενικό ενδιαφέρον για το σύστημα, προσφορές εργασίας - υπέροχο! Δηλαδή, όταν το σύστημά μου αποτύχει, θα πω: «Όχι, είναι αξιόπιστο! Υπάρχουν πολλές προσφορές εργασίας...» Μια τόσο απλή σύγκριση δεν θα κάνει.
Όλα αυτά τα συστήματα δεν είναι μόνο συστήματα προσωρινής αποθήκευσης. Έχουν επίσης πολλές λειτουργίες, όπως όταν τα δεδομένα δεν αντλούνται στον πελάτη για επεξεργασία, αλλά το αντίστροφο: ο κώδικας που πρέπει να εκτελεστεί στα δεδομένα μετακινείται στον διακομιστή, εκτελείται εκεί και το αποτέλεσμα επιστρέφεται. Και δεν θεωρούνται τόσο συχνά ως ξεχωριστό σύστημα για την προσωρινή αποθήκευση.
Εντάξει, μην τα παρατάμε, ας βρούμε μια άμεση σύγκριση των συστημάτων. Ας πάρουμε τις δύο κορυφαίες επιλογές - Redis και Hazelcast. Μας ενδιαφέρει η ταχύτητα και θα τις συγκρίνουμε με βάση αυτή την παράμετρο.
Hz εναντίον Redis
Το βρίσκουμε αυτό :
Το μπλε είναι το Redis, το κόκκινο είναι το Hazelcast. Το Hazelcast κερδίζει παντού, και υπάρχει μια λογική για αυτό: είναι πολλαπλών νημάτων, εξαιρετικά βελτιστοποιημένο, κάθε νήμα λειτουργεί με το δικό του διαμέρισμα, επομένως δεν υπάρχουν μπλοκ. Και το Redis είναι single-threaded· δεν επωφελείται από τις σύγχρονες πολυπύρηνες CPU. Το Hazelcast έχει ασύγχρονη I/O, το Redis-Jedis έχει μπλοκαρισμένες υποδοχές. Εξάλλου, το Hazelcast χρησιμοποιεί ένα δυαδικό πρωτόκολλο και το Redis είναι κειμενοκεντρικό, που σημαίνει ότι είναι αναποτελεσματικό.
Για κάθε ενδεχόμενο, ας στραφούμε σε μια άλλη πηγή σύγκρισης. Τι θα μας δείξει;
Redis εναντίον Hz
άλλος :
Εδώ, αντίθετα, το κόκκινο είναι το Redis. Δηλαδή, ο Redis υπερτερεί της Hazelcast σε απόδοση. Ο Hazelcast κέρδισε την πρώτη σύγκριση, ο Redis κέρδισε τη δεύτερη. εξήγησε με μεγάλη ακρίβεια γιατί ο Hazelcast κέρδισε την προηγούμενη σύγκριση.
Αποδεικνύεται ότι το αποτέλεσμα του πρώτου ήταν πραγματικά στημένο: ο Redis λήφθηκε στο βασικό κιβώτιο και το Hazelcast ήταν προσαρμοσμένο για μια δοκιμαστική περίπτωση. Στη συνέχεια, αποδεικνύεται: πρώτον, δεν μπορούμε να εμπιστευτούμε κανέναν και δεύτερον, όταν τελικά επιλέγουμε ένα σύστημα, πρέπει ακόμα να το διαμορφώσουμε σωστά. Αυτές οι ρυθμίσεις περιλαμβάνουν δεκάδες, σχεδόν εκατοντάδες παραμέτρους.
Κουνώντας το μπουκάλι
Και μπορώ να εξηγήσω την όλη διαδικασία που έχουμε κάνει τώρα με την ακόλουθη μεταφορά: «Κουνώντας το μπουκάλι». Δηλαδή, τώρα δεν χρειάζεται να προγραμματίσετε, τώρα το κύριο πράγμα είναι να μπορείτε να διαβάσετε το stackoverflow. Και έχω έναν άνθρωπο στην ομάδα μου, έναν επαγγελματία, που λειτουργεί ακριβώς έτσι σε κρίσιμες στιγμές.
Τι κάνει? Βλέπει ένα σπασμένο πράγμα, βλέπει ένα ίχνος στοίβας, παίρνει μερικές λέξεις από αυτό (ποιες είναι η τεχνογνωσία του στο πρόγραμμα), ψάχνει στο Google, βρίσκει το stackoverflow ανάμεσα στις απαντήσεις. Χωρίς να διαβάσει, χωρίς να σκεφτεί, μεταξύ των απαντήσεων στην ερώτηση, επιλέγει κάτι πιο παρόμοιο με την πρόταση "κάντε αυτό και εκείνο" (η επιλογή μιας τέτοιας απάντησης είναι το ταλέντο του, γιατί δεν είναι πάντα η απάντηση που λαμβάνει τα περισσότερα likes) ισχύει , φαίνεται: αν κάτι έχει αλλάξει, τότε υπέροχο. Εάν δεν έχει αλλάξει, γυρίστε το πίσω. Και επαναλάβετε εκκίνηση-έλεγχος-αναζήτηση. Και με αυτόν τον διαισθητικό τρόπο, διασφαλίζει ότι ο κώδικας λειτουργεί μετά από κάποιο χρονικό διάστημα. Δεν ξέρει γιατί, δεν ξέρει τι έκανε, δεν μπορεί να εξηγήσει. Αλλά! Αυτή η μόλυνση λειτουργεί. Και «η φωτιά έχει σβήσει». Τώρα ας καταλάβουμε τι κάναμε. Όταν το πρόγραμμα λειτουργεί, είναι μια τάξη μεγέθους ευκολότερο. Και εξοικονομεί πολύ χρόνο.
Αυτή η μέθοδος εξηγείται πολύ καλά με αυτό το παράδειγμα.
Κάποτε ήταν πολύ δημοφιλές να συλλέγεις ένα ιστιοφόρο σε μπουκάλι. Ταυτόχρονα, το ιστιοφόρο είναι μεγάλο και εύθραυστο και ο λαιμός του μπουκαλιού είναι πολύ στενός, είναι αδύνατο να το σπρώξετε μέσα. Πώς να το συναρμολογήσετε;
Υπάρχει μια τέτοια μέθοδος, πολύ γρήγορη και πολύ αποτελεσματική.
Το πλοίο αποτελείται από ένα σωρό μικροπράγματα: μπαστούνια, σχοινιά, πανιά, κόλλα. Όλα αυτά τα βάζουμε σε ένα μπουκάλι.
Παίρνουμε το μπουκάλι με τα δύο χέρια και αρχίζουμε να κουνάμε. Την τινάζουμε και την κουνάμε. Και συνήθως αποδεικνύεται σκουπίδι, φυσικά. Αλλά μερικές φορές. Μερικές φορές αποδεικνύεται ότι είναι ένα πλοίο! Πιο συγκεκριμένα, κάτι παρόμοιο με πλοίο.
Δείχνουμε αυτό κάτι σε κάποιον: «Σεριόγκα, βλέπεις!;» Και πράγματι, από μακριά μοιάζει με πλοίο. Αλλά αυτό δεν μπορεί να επιτραπεί να συνεχιστεί.
Υπάρχει κι άλλος τρόπος. Χρησιμοποιούνται από πιο προχωρημένους τύπους, όπως οι χάκερ.
Έδωσα ένα καθήκον σε αυτόν τον τύπο, έκανε τα πάντα και έφυγε. Και κοιτάς - φαίνεται ότι έχει γίνει. Και μετά από λίγο, όταν πρέπει να οριστικοποιηθεί ο κωδικός, αυτό ξεκινά εξαιτίας του... Είναι καλό που έχει ήδη καταφέρει να τρέξει μακριά. Αυτοί είναι οι τύποι που, χρησιμοποιώντας το παράδειγμα ενός μπουκαλιού, θα το κάνουν: βλέπετε, όπου είναι ο πάτος, το γυαλί λυγίζει. Και δεν είναι απολύτως σαφές αν είναι διαφανές ή όχι. Στη συνέχεια, οι «χάκερς» έκοψαν αυτόν τον πάτο, εισάγουν ένα πλοίο εκεί, μετά κολλούν ξανά τον πάτο και είναι σαν να έπρεπε να είναι έτσι.
Από την άποψη της ρύθμισης του προβλήματος, όλα φαίνονται να είναι σωστά. Αλλά χρησιμοποιώντας τα πλοία ως παράδειγμα: γιατί να φτιάξετε αυτό το πλοίο καθόλου, ποιος το χρειάζεται ούτως ή άλλως; Δεν παρέχει καμία λειτουργικότητα. Συνήθως τέτοια πλοία είναι δώρα σε πολύ υψηλόβαθμους, που το βάζουν σε ένα ράφι από πάνω τους, ως κάποιου είδους σύμβολο, ως σημάδι. Και αν ένας τέτοιος, επικεφαλής μιας μεγάλης επιχείρησης ή υψηλόβαθμος αξιωματούχος, πώς θα σταθεί η σημαία για μια τέτοια αμυχή, της οποίας ο λαιμός έχει κοπεί; Θα ήταν καλύτερα να μην το γνώριζε ποτέ. Λοιπόν, πώς καταλήγουν να κατασκευάζουν αυτά τα πλοία που μπορούν να δοθούν σε ένα σημαντικό πρόσωπο;
Το μόνο βασικό μέρος για το οποίο πραγματικά δεν μπορείτε να κάνετε τίποτα είναι το σώμα. Και η γάστρα του πλοίου ταιριάζει ακριβώς στο λαιμό. Ενώ το πλοίο συναρμολογείται έξω από το μπουκάλι. Αλλά δεν είναι μόνο η συναρμολόγηση ενός πλοίου, είναι μια πραγματική τέχνη κοσμήματος. Στα εξαρτήματα προστίθενται ειδικοί μοχλοί, οι οποίοι στη συνέχεια επιτρέπουν την ανύψωσή τους. Για παράδειγμα, τα πανιά διπλώνονται, εισάγονται προσεκτικά μέσα και στη συνέχεια, με τη βοήθεια λαβίδων, τραβιέται και ανυψώνεται με μεγάλη ακρίβεια, με ακρίβεια. Το αποτέλεσμα είναι ένα έργο τέχνης που μπορεί να προικιστεί με καθαρή συνείδηση και περηφάνια.
Και αν θέλουμε το έργο να έχει επιτυχία, πρέπει να υπάρχει τουλάχιστον ένας κοσμηματοπώλης στην ομάδα. Κάποιος που νοιάζεται για την ποιότητα του προϊόντος και λαμβάνει υπόψη του όλες τις πτυχές, χωρίς να θυσιάζει τίποτα, ακόμα και σε στιγμές άγχους, όταν οι περιστάσεις απαιτούν να κάνει το επείγον σε βάρος του σημαντικού. Όλα τα επιτυχημένα έργα που είναι βιώσιμα, που έχουν αντέξει στη δοκιμασία του χρόνου, βασίζονται σε αυτήν την αρχή. Υπάρχει κάτι πολύ ακριβές και μοναδικό σε αυτά, κάτι που εκμεταλλεύεται όλες τις διαθέσιμες δυνατότητες. Στο παράδειγμα με το πλοίο στη φιάλη παίζεται το γεγονός ότι η γάστρα του πλοίου περνά από το λαιμό.
Επιστρέφοντας στην εργασία επιλογής του διακομιστή προσωρινής αποθήκευσης, πώς μπορεί να εφαρμοστεί αυτή η μέθοδος; Προσφέρω αυτήν την επιλογή επιλογής από όλα τα συστήματα που υπάρχουν - μην κουνάτε το μπουκάλι, μην διαλέγετε, αλλά κοιτάξτε τι έχουν καταρχήν, τι πρέπει να προσέξετε όταν επιλέγετε ένα σύστημα.
Πού να ψάξετε για μπουκάλι
Ας προσπαθήσουμε να μην κουνήσουμε το μπουκάλι, να μην περάσουμε ένα προς ένα ό,τι υπάρχει, αλλά ας δούμε τι προβλήματα θα προκύψουν αν ξαφνικά, για την αποστολή μας, σχεδιάσουμε μόνοι μας ένα τέτοιο σύστημα. Φυσικά, δεν θα συναρμολογήσουμε το ποδήλατο, αλλά θα χρησιμοποιήσουμε αυτό το διάγραμμα για να μας βοηθήσει να καταλάβουμε ποια σημεία πρέπει να προσέξουμε στις περιγραφές των προϊόντων. Ας σκιαγραφήσουμε ένα τέτοιο διάγραμμα.
Εάν το σύστημα είναι διανεμημένο, τότε θα έχουμε αρκετούς διακομιστές (6). Ας υποθέσουμε ότι υπάρχουν τέσσερα (είναι βολικό να τα τοποθετήσετε στην εικόνα, αλλά, φυσικά, μπορεί να υπάρχουν όσα από αυτά θέλετε). Εάν οι διακομιστές βρίσκονται σε διαφορετικούς κόμβους, αυτό σημαίνει ότι όλοι εκτελούν κάποιο κώδικα που είναι υπεύθυνος για τη διασφάλιση ότι αυτοί οι κόμβοι σχηματίζουν ένα σύμπλεγμα και, σε περίπτωση διακοπής, συνδέονται και αναγνωρίζουν ο ένας τον άλλον.
Χρειαζόμαστε επίσης τη λογική κώδικα (2), η οποία στην πραγματικότητα αφορά την προσωρινή αποθήκευση. Οι πελάτες αλληλεπιδρούν με αυτόν τον κώδικα μέσω κάποιου API. Ο κωδικός πελάτη (1) μπορεί να βρίσκεται είτε εντός του ίδιου JVM είτε να έχει πρόσβαση σε αυτό μέσω του δικτύου. Η λογική που εφαρμόζεται μέσα είναι η απόφαση για το ποια αντικείμενα θα αφήσουμε στην κρυφή μνήμη και ποια θα τα πετάξουμε έξω. Χρησιμοποιούμε τη μνήμη (3) για την αποθήκευση της κρυφής μνήμης, αλλά αν χρειαστεί, μπορούμε να αποθηκεύσουμε ορισμένα από τα δεδομένα στο δίσκο (4).
Ας δούμε σε ποια μέρη θα συμβεί το φορτίο. Στην πραγματικότητα, κάθε βέλος και κάθε κόμβος θα φορτωθούν. Πρώτον, μεταξύ του κώδικα πελάτη και του api, εάν πρόκειται για επικοινωνία δικτύου, η καθίζηση μπορεί να είναι αρκετά αισθητή. Δεύτερον, στο πλαίσιο του ίδιου του api - αν το παρακάνουμε με τη σύνθετη λογική, μπορεί να αντιμετωπίσουμε προβλήματα με την CPU. Και θα ήταν ωραίο αν η λογική δεν έχανε χρόνο στη μνήμη. Και παραμένει αλληλεπίδραση με το σύστημα αρχείων - στη συνηθισμένη έκδοση αυτό είναι σειριακή / επαναφορά και εγγραφή / ανάγνωση.
Ακολουθεί η αλληλεπίδραση με το σύμπλεγμα. Πιθανότατα, θα είναι στο ίδιο σύστημα, αλλά θα μπορούσε να είναι ξεχωριστά. Εδώ πρέπει επίσης να λάβετε υπόψη τη μεταφορά δεδομένων σε αυτό, την ταχύτητα σειριοποίησης δεδομένων και τις αλληλεπιδράσεις μεταξύ του συμπλέγματος.
Τώρα, αφενός, μπορούμε να φανταστούμε «τι γρανάζια θα γυρίσουν» στο σύστημα κρυφής μνήμης κατά την επεξεργασία αιτημάτων από τον κώδικά μας και, αφετέρου, μπορούμε να υπολογίσουμε ποια και πόσα αιτήματα θα δημιουργήσει ο κώδικάς μας σε αυτό το σύστημα. Αυτό αρκεί για να κάνουμε μια λίγο πολύ νηφάλια επιλογή - να επιλέξουμε ένα σύστημα για την περίπτωση χρήσης μας.
φουντουκιά
Ας δούμε πώς να εφαρμόσουμε αυτήν την αποσύνθεση στη λίστα μας. Για παράδειγμα, το Hazelcast.
Για να βάλει/πάρει δεδομένα από το Hazelcast, ο κωδικός πελάτη έχει πρόσβαση (1) στο api. Το Hz σάς επιτρέπει να εκτελείτε τον διακομιστή ως ενσωματωμένο και σε αυτήν την περίπτωση, η πρόσβαση στο api είναι μια κλήση μεθόδου μέσα στο JVM, η οποία μπορεί να θεωρηθεί δωρεάν.
Για να λειτουργήσει η λογική στο (2), το Hz βασίζεται στον κατακερματισμό του πίνακα byte του σειριακού κλειδιού - δηλαδή, το κλειδί θα σειριοποιηθεί σε κάθε περίπτωση. Αυτό είναι αναπόφευκτο για τα Hz.
Οι στρατηγικές έξωσης εφαρμόζονται καλά, αλλά για ειδικές περιπτώσεις μπορείτε να προσθέσετε τις δικές σας. Δεν χρειάζεται να ανησυχείτε για αυτό το κομμάτι.
Ο χώρος αποθήκευσης (4) μπορεί να συνδεθεί. Εξαιρετική. Η αλληλεπίδραση (5) για το ενσωματωμένο μπορεί να θεωρηθεί άμεση. Ανταλλαγή δεδομένων μεταξύ κόμβων στο σύμπλεγμα (6) - ναι, υπάρχει. Αυτή είναι μια επένδυση στην ανοχή σφαλμάτων σε βάρος της ταχύτητας. Η δυνατότητα Hz Near-cache σάς επιτρέπει να μειώσετε την τιμή - τα δεδομένα που λαμβάνονται από άλλους κόμβους στο σύμπλεγμα θα αποθηκευτούν προσωρινά.
Τι μπορεί να γίνει σε τέτοιες συνθήκες για να αυξηθεί η ταχύτητα;
Για παράδειγμα, για να αποφύγετε τη σειριοποίηση του κλειδιού στο (2) - συνδέστε μια άλλη κρυφή μνήμη πάνω από το Hazelcast, για τα πιο δημοφιλή δεδομένα. Η Sportmaster επέλεξε την καφεΐνη για αυτό το σκοπό.
Για περιστροφή στο επίπεδο (6), το Hz προσφέρει δύο τύπους αποθήκευσης: IMap και ReplicatedMap.
Αξίζει να αναφέρουμε πώς ο Hazelcast μπήκε στη στοίβα τεχνολογίας Sportmaster.
Το 2012, όταν εργαζόμασταν στον πρώτο πιλότο του μελλοντικού ιστότοπου, ήταν το Hazelcast που αποδείχθηκε ότι ήταν ο πρώτος σύνδεσμος που επέστρεψε η μηχανή αναζήτησης. Η γνωριμία ξεκίνησε "την πρώτη φορά" - μας συνεπήρε το γεγονός ότι μόλις δύο ώρες αργότερα, όταν βιδώσαμε το Hz στο σύστημα, λειτούργησε. Και λειτούργησε καλά. Μέχρι το τέλος της ημέρας είχαμε ολοκληρώσει μια σειρά από δοκιμές και ήμασταν ευχαριστημένοι. Και αυτό το απόθεμα σθένους ήταν αρκετό για να ξεπεράσει τις εκπλήξεις που έριξε ο Hz με τον καιρό. Τώρα η ομάδα Sportmaster δεν έχει λόγο να εγκαταλείψει το Hazelcast.
Αλλά τέτοια επιχειρήματα όπως "ο πρώτος σύνδεσμος στη μηχανή αναζήτησης" και "Το HelloWorld συναρμολογήθηκε γρήγορα" είναι, φυσικά, μια εξαίρεση και χαρακτηριστικό της στιγμής που έγινε η επιλογή. Οι πραγματικές δοκιμές για το επιλεγμένο σύστημα ξεκινούν με την κυκλοφορία στην παραγωγή και σε αυτό το στάδιο θα πρέπει να δώσετε προσοχή όταν επιλέγετε οποιοδήποτε σύστημα, συμπεριλαμβανομένης της προσωρινής μνήμης. Στην πραγματικότητα, στην περίπτωσή μας μπορούμε να πούμε ότι επιλέξαμε το Hazelcast τυχαία, αλλά μετά αποδείχθηκε ότι επιλέξαμε σωστά.
Για την παραγωγή, πολύ πιο σημαντικό: παρακολούθηση, χειρισμός αστοχιών σε μεμονωμένους κόμβους, αναπαραγωγή δεδομένων, κόστος κλιμάκωσης. Δηλαδή, αξίζει να δώσουμε προσοχή στις εργασίες που θα προκύψουν κατά τη συντήρηση του συστήματος - όταν το φορτίο είναι δεκάδες φορές υψηλότερο από το προγραμματισμένο, όταν ανεβάζουμε κατά λάθος κάτι σε λάθος μέρος, όταν πρέπει να κυκλοφορήσουμε μια νέα έκδοση του κώδικα, αντικαταστήστε τα δεδομένα και κάντε το απαρατήρητο για τους πελάτες.
Για όλες αυτές τις απαιτήσεις, το Hazelcast σίγουρα ταιριάζει.
Συνεχίζεται
Αλλά το Hazelcast δεν είναι πανάκεια. Το 2017, επιλέξαμε το Hazelcast για την προσωρινή μνήμη διαχειριστή, βασιζόμενοι απλώς σε καλές εντυπώσεις από την προηγούμενη εμπειρία. Αυτό έπαιξε βασικό ρόλο σε ένα πολύ σκληρό αστείο, εξαιτίας του οποίου βρεθήκαμε σε μια δύσκολη κατάσταση και «ηρωικά» βγήκαμε από αυτήν για 60 ημέρες. Αλλά περισσότερα για αυτό στο επόμενο μέρος.
Εν τω μεταξύ... Καλό Νέο Κώδικα!
Πηγή: www.habr.com