Ψάχνετε για σύστημα αναμονής; Ή μήπως ψάχνετε ένα καλύτερο; Εδώ είναι όλες οι πληροφορίες που χρειάζεστε!
Τα συστήματα ουράς είναι το καλύτερα κρυμμένο μυστικό της ανάπτυξης backend.
Χωρίς να προσπαθήσω να γράψω ένα ποίημα για να επαινέσω τα συστήματα ουράς, θα έλεγα ότι ένας κατώτερος προγραμματιστής backend γίνεται προγραμματιστής μεσαίου επιπέδου υποστήριξης αφού μάθει να ενσωματώνει ουρές στο σύστημα. Οι ουρές βελτιώνουν την εμπειρία των πελατών (θα δούμε πώς), μειώνουν την πολυπλοκότητα και βελτιώνουν την αξιοπιστία σε ένα σύστημα.
Σίγουρα, για πολύ απλές εφαρμογές ιστού με σχεδόν μηδενική επισκεψιμότητα και ιστότοπους φυλλαδίων, οι ουρές μπορεί να είναι συνολικά (ή ακόμα και αδύνατο να εγκατασταθούν εάν βρίσκεστε σε ένα τυπικό περιβάλλον κοινόχρηστης φιλοξενίας), αλλά οι μη ασήμαντες εφαρμογές θα ωφεληθούν από την ουρά συστήματα και μεγάλες εφαρμογές είναι αδύνατες χωρίς τη συμμετοχή σε ουρά.
Πριν ξεκινήσουμε, μια δήλωση αποποίησης ευθύνης: εάν είστε ήδη άνετοι με τα συστήματα ουράς και θέλετε να συγκρίνετε τις διάφορες επιλογές, οι επόμενες λίγες εισαγωγικές ενότητες θα προκαλέσουν μεγάλο ύπνο. 🙂 Γι’ αυτό μη διστάσετε να πηδήξετε αμέσως μπροστά. Οι εισαγωγικές ενότητες προορίζονται για όσους έχουν μόνο μια θολή ιδέα των συστημάτων ουρών ή απλώς άκουσαν το όνομα εν παρόδω.
Πίνακας περιεχομένων
Τι είναι το σύστημα αναμονής;
Ας ξεκινήσουμε καταλαβαίνοντας τι είναι η ουρά.
Η ουρά είναι μια δομή δεδομένων στην επιστήμη των υπολογιστών που μιμείται, καλά, τις ουρές του πραγματικού κόσμου που βλέπουμε γύρω μας. Αν πάτε σε ένα γκισέ εισιτηρίων, για παράδειγμα, θα παρατηρήσετε ότι θα πρέπει να σταθείτε στο τέλος της ουράς, ενώ το άτομο στην αρχή της ουράς θα πάρει πρώτο το εισιτήριο. Αυτό είναι που ονομάζουμε επίσης φαινόμενο «πρώτης έλευσης, πρώτος σερβιρισμένος». Στην επιστήμη των υπολογιστών, είναι δυνατό να γραφτούν προγράμματα που αποθηκεύουν τις εργασίες τους όπως αυτή σε μια ουρά, επεξεργάζοντάς τα ένα προς ένα με την ίδια βάση με την πρώτη σειρά προτεραιότητας.
Λάβετε υπόψη ότι η ουρά δεν πραγματοποιεί καμία πραγματική επεξεργασία από μόνη της. Είναι απλώς μια προσωρινή αποθήκευση, όπου οι εργασίες περιμένουν μέχρι να παραληφθούν από κάτι. Αν όλα αυτά ακούγονται λίγο αφηρημένα, μην ανησυχείτε. Είναι μια αφηρημένη έννοια, αλλά θα δούμε ξεκάθαρα παραδείγματα στην επόμενη ενότητα. 🙂
Γιατί χρειάζεστε συστήματα ουράς;
Χωρίς να μπαίνω σε μια πολύ μακροσκελή περιγραφή, θα έλεγα ότι η κύρια ανάγκη για συστήματα ουράς είναι λόγω της επεξεργασίας παρασκηνίου, της παράλληλης εκτέλεσης και της ανάκτησης από αποτυχία. Ας τα δούμε αυτά με τη βοήθεια παραδειγμάτων:
Επεξεργασία φόντου
Ας υποθέσουμε ότι εκτελείτε μια καμπάνια μάρκετινγκ ηλεκτρονικού εμπορίου όπου ο χρόνος είναι σημαντικός και ότι η αίτησή σας είναι κατασκευασμένη έτσι ώστε να στέλνει ένα μήνυμα ηλεκτρονικού ταχυδρομείου επιβεβαίωσης ακριβώς πριν ο πελάτης ολοκληρώσει την πληρωμή και εμφανιστεί η σελίδα “ευχαριστώ”. Εάν ο διακομιστής αλληλογραφίας στον οποίο συνδέεστε είναι εκτός λειτουργίας, η ιστοσελίδα απλώς θα πεθάνει, προκαλώντας ρήξη στην εμπειρία χρήστη.
Φανταστείτε τον μεγάλο αριθμό αιτημάτων υποστήριξης που θα λαμβάνατε! Σε αυτήν την περίπτωση, είναι καλύτερο να προωθήσετε αυτήν την αποστολή αποστολής email σε μια ουρά εργασίας και να δείξετε στον πελάτη τη σελίδα επιτυχίας.
Παράλληλη εκτέλεση
Πολλοί προγραμματιστές, ειδικά εκείνοι που συνήθως κωδικοποιούν απλούστερες εφαρμογές χαμηλής επισκεψιμότητας, συνηθίζουν να χρησιμοποιούν εργασίες cron για επεξεργασία στο παρασκήνιο. Αυτό είναι καλό έως ότου το μέγεθος της εισόδου μεγαλώσει τόσο πολύ που δεν μπορεί να διαγραφεί. Για παράδειγμα, ας υποθέσουμε ότι έχετε μια εργασία cron που συγκεντρώνει αναφορές αναλυτικών στοιχείων και τις στέλνει μέσω email στους χρήστες και ότι το σύστημά σας μπορεί να επεξεργαστεί 100 αναφορές ανά λεπτό.
Μόλις η εφαρμογή σας μεγαλώσει και αρχίσει να λαμβάνει περισσότερα από 100 αιτήματα ανά λεπτό κατά μέσο όρο, θα αρχίσει να μειώνεται όλο και περισσότερο και δεν θα μπορεί ποτέ να ολοκληρώσει όλες τις εργασίες.
Σε ένα σύστημα ουράς, αυτή η κατάσταση μπορεί να αποφευχθεί με τη δημιουργία πολλών εργαζομένων, οι οποίοι μπορούν ο καθένας να επιλέξει μια εργασία (που περιέχει 100 αναφορές που πρέπει να γίνουν η καθεμία) και να εργαστούν παράλληλα για να ολοκληρώσουν την εργασία πολύ, πολύ νωρίτερα.
Ανάκτηση από αποτυχία
Γενικά δεν σκεφτόμαστε την αποτυχία ως προγραμματιστές ιστού. Θεωρούμε δεδομένο ότι οι διακομιστές μας και τα API που χρησιμοποιούμε θα είναι πάντα online. Αλλά η πραγματικότητα είναι διαφορετική — οι διακοπές δικτύου είναι πολύ συνηθισμένες και τα εξαιρετικά API στα οποία βασίζεστε μπορεί να είναι εκτός λειτουργίας λόγω προβλημάτων υποδομής (προτού πείτε “όχι εγώ!”, μην ξεχνάτε μαζική διακοπή λειτουργίας του Amazon S3). Επομένως, επιστρέφοντας στο παράδειγμα αναφοράς, εάν μέρος της δημιουργίας αναφορών σας απαιτεί να συνδεθείτε στο API πληρωμών και αυτή η σύνδεση διακοπεί για 2 λεπτά, τι θα συμβεί με τις 200 αναφορές που απέτυχαν;
Ωστόσο, τα συστήματα ουράς περιλαμβάνουν σημαντικά έξοδα. Η καμπύλη εκμάθησης είναι αρκετά απότομη καθώς εισέρχεστε σε έναν εντελώς νέο τομέα, η πολυπλοκότητα της εφαρμογής και της ανάπτυξής σας αυξάνεται και οι εργασίες σε ουρά δεν μπορούν πάντα να ελεγχθούν με ακρίβεια 100%. Τούτου λεχθέντος, υπάρχουν περιπτώσεις όπου η δημιουργία μιας εφαρμογής χωρίς ουρές απλώς δεν είναι δυνατή.
Με αυτό να μην υπάρχει, ας ρίξουμε μια ματιά σε μερικές από τις κοινές επιλογές μεταξύ των backend/συστημάτων που βρίσκονται σε ουρά σήμερα.
Redis
Redis είναι γνωστό ως κατάστημα κλειδιού-τιμής που απλώς αποθηκεύει, ενημερώνει και ανακτά σειρές δεδομένων χωρίς γνώση της δομής των δεδομένων. Αν και αυτό θα μπορούσε να ίσχυε νωρίτερα, σήμερα το Redis διαθέτει αποτελεσματικές και εξαιρετικά χρήσιμες δομές δεδομένων όπως λίστες, ταξινομημένα σύνολα, ακόμη και ένα σύστημα Pub-Sub, γεγονός που το καθιστά ιδιαίτερα επιθυμητό για υλοποιήσεις ουράς.
Τα πλεονεκτήματα του Redis είναι:
- Πλήρως βάση δεδομένων στη μνήμη, με αποτέλεσμα ταχύτερη ανάγνωση/εγγραφή.
- Εξαιρετικά αποδοτικό: Μπορεί εύκολα να υποστηρίξει περισσότερες από 100.000 λειτουργίες ανάγνωσης/εγγραφής ανά δευτερόλεπτο.
- Ιδιαίτερα ευέλικτο σχήμα επιμονής. Μπορείτε είτε να επιλέξετε τη μέγιστη απόδοση με το κόστος της πιθανής απώλειας δεδομένων σε περίπτωση αστοχιών είτε να ρυθμίσετε σε πλήρως συντηρητική λειτουργία για να θυσιάσετε την απόδοση για συνέπεια.
- Συμπλέγματα που υποστηρίζονται από το κουτί
Λάβετε υπόψη ότι το Redis δεν διαθέτει αφαιρέσεις μηνυμάτων/ουράς/ανάκτησης, επομένως πρέπει είτε να χρησιμοποιήσετε ένα πακέτο είτε να δημιουργήσετε μόνοι σας ένα ελαφρύ σύστημα. Ένα παράδειγμα είναι ότι το Redis είναι το προεπιλεγμένο backend της ουράς για το πλαίσιο Laravel PHP, όπου έχει υλοποιηθεί ένας προγραμματιστής από τους συντάκτες του πλαισίου.
Εκμάθηση Redis είναι εύκολο.
RabbitMQ
Υπάρχουν μερικές λεπτές διαφορές μεταξύ του Redis και του RabbitMQοπότε ας τα βγάλουμε από τη μέση πρώτα.
Πρώτα απ ‘όλα, το RabbitMQ έχει έναν πιο εξειδικευμένο, καλά καθορισμένο ρόλο, και έτσι κατασκευάστηκε για να αντικατοπτρίζει αυτό – την ανταλλαγή μηνυμάτων. Με άλλα λόγια, το γλυκό του σημείο είναι να λειτουργεί ως ενδιάμεσος μεταξύ δύο συστημάτων, κάτι που δεν ισχύει για το Redis, το οποίο λειτουργεί ως βάση δεδομένων. Ως αποτέλεσμα, το RabbitMQ παρέχει μερικές ακόμη ευκολίες που λείπουν στο Redis: δρομολόγηση μηνυμάτων, επαναλήψεις, διανομή φορτίου κ.λπ.
Εάν το σκεφτείτε, οι ουρές εργασιών μπορούν επίσης να θεωρηθούν ως ένα σύστημα ανταλλαγής μηνυμάτων, όπου ο προγραμματιστής, οι εργαζόμενοι και οι «υποβολείς» εργασίας μπορούν να θεωρηθούν ως οντότητες που συμμετέχουν στη μετάδοση μηνυμάτων.
Το RabbitMQ έχει τα ακόλουθα πλεονεκτήματα:
- Καλύτερες αφαιρέσεις για τη μετάδοση μηνυμάτων, μειώνοντας την εργασία σε επίπεδο εφαρμογής, εάν η μετάδοση μηνυμάτων είναι αυτό που χρειάζεστε.
- Πιο ανθεκτικό σε διακοπές ρεύματος και διακοπές ρεύματος (από το Redis, τουλάχιστον από προεπιλογή).
- Υποστήριξη συμπλέγματος και ομοσπονδίας για κατανεμημένες αναπτύξεις.
- Χρήσιμα εργαλεία για τη διαχείριση και την παρακολούθηση των αναπτύξεών σας.
- Υποστήριξη για όλες σχεδόν τις μη τετριμμένες γλώσσες προγραμματισμού εκεί έξω.
- Ανάπτυξη με το εργαλείο της επιλογής σας (Docker, Chef, Puppet κ.λπ.).
Πότε να χρησιμοποιήσετε το RabbitMQ; Θα έλεγα ότι είναι μια εξαιρετική επιλογή όταν γνωρίζετε ότι πρέπει να χρησιμοποιήσετε ασύγχρονη μετάδοση μηνυμάτων, αλλά δεν είστε έτοιμοι να αντιμετωπίσετε την τεράστια πολυπλοκότητα ορισμένων από τις άλλες επιλογές ουράς σε αυτήν τη λίστα (δείτε παρακάτω).
ActiveMQ
Εάν ασχολείστε με τον επιχειρηματικό χώρο (ή κατασκευάζετε μια εφαρμογή υψηλής διανομής και μεγάλης κλίμακας) και δεν θέλετε να χρειάζεται να ανακαλύπτετε ξανά τον τροχό συνεχώς (και να κάνετε λάθη στην πορεία), ActiveMQ αξίζει μια ματιά.
Εδώ υπερέχει το ActiveMQ:
- Εφαρμόζεται σε Java και έτσι έχει πολύ καθαρή ενσωμάτωση Java (ακολουθεί το πρότυπο JMS).
- Υποστηριζόμενα πολλαπλά πρωτόκολλα: AMQP, MQTT, STOMP, OpenWire κ.λπ.
- Χειρίζεται την ασφάλεια, τη δρομολόγηση, τη λήξη μηνυμάτων, τα αναλυτικά στοιχεία κ.λπ., εκτός συσκευασίας.
- Ψημένη υποστήριξη για δημοφιλή μοτίβα διανομής μηνυμάτων, εξοικονομώντας χρόνο και δαπανηρά λάθη.
Αυτό δεν σημαίνει ότι το ActiveMQ είναι διαθέσιμο μόνο για Java. Έχει πελάτες για Python, C/C++, Node, .Net και άλλα οικοσυστήματα, επομένως δεν θα πρέπει να υπάρχουν ανησυχίες για πιθανή κατάρρευση στο μέλλον. Επιπλέον, το ActiveMQ είναι χτισμένο σε εντελώς ανοιχτά πρότυπα και η δημιουργία των δικών σας ελαφρών πελατών θα πρέπει να είναι εύκολη.
Όλα όσα είπαν και έγιναν, λάβετε υπόψη ότι το ActiveMQ είναι απλώς ένας μεσίτης και δεν περιλαμβάνει backend. Θα πρέπει ακόμα να χρησιμοποιήσετε ένα από τα υποστηριζόμενα backend για να αποθηκεύσετε τα μηνύματα. Το συμπεριέλαβα εδώ επειδή δεν είναι συνδεδεμένο με μια συγκεκριμένη γλώσσα προγραμματισμού (όπως άλλες δημοφιλείς λύσεις όπως το Celery, το Sidekiq, κ.λπ.)
Amazon MQ
Amazon MQ αξίζει μια γρήγορη αλλά σημαντική αναφορά εδώ. Εάν πιστεύετε ότι το ActiveMQ είναι η ιδανική λύση για τις ανάγκες σας, αλλά δεν θέλετε να ασχοληθείτε μόνοι σας με την κατασκευή και τη συντήρηση της υποδομής, το Amazon MQ προσφέρει μια διαχειριζόμενη υπηρεσία για να το κάνετε αυτό. Υποστηρίζει όλα τα πρωτόκολλα που κάνει το ActiveMQ — δεν υπάρχει καμία διαφορά στα χαρακτηριστικά — αφού χρησιμοποιεί το ίδιο το ActiveMQ κάτω από την επιφάνεια.
Το πλεονέκτημα είναι ότι είναι μια διαχειριζόμενη υπηρεσία, επομένως δεν χρειάζεται να ανησυχείτε για τίποτα άλλο εκτός από τη χρήση της. Είναι ακόμη πιο λογικό για εκείνες τις αναπτύξεις που είναι σε AWS, καθώς μπορείτε να αξιοποιήσετε άλλες υπηρεσίες και προσφορές απευθείας από την ανάπτυξή σας (για παράδειγμα ταχύτερες μεταφορές δεδομένων).
Amazon SQS
Δεν μπορούμε να περιμένουμε από την Amazon να καθίσει ήσυχα όταν πρόκειται για κρίσιμα κομμάτια υποδομής, έτσι δεν είναι; 🙂
Και έτσι έχουμε Amazon SQS, που είναι μια πλήρως φιλοξενούμενη, απλή υπηρεσία ουράς (κυριολεκτικά) από τον γνωστό γίγαντα AWS. Για άλλη μια φορά, οι λεπτές διαφορές είναι σημαντικές, επομένως σημειώστε ότι το SQS δεν έχει την έννοια της μετάδοσης μηνυμάτων. Όπως το Redis, είναι ένα απλό backend για την αποδοχή και τη διανομή θέσεων εργασίας σε ουρές.
Λοιπόν, πότε θα θέλατε να χρησιμοποιήσετε το Amazon SQS; Εδώ είναι μερικοί λόγοι:
- Είστε οπαδός του AWS και δεν θα αγγίξετε τίποτα άλλο (ειλικρινά, υπάρχουν πολλοί άνθρωποι εκεί έξω, και νομίζω ότι δεν υπάρχει τίποτα κακό με αυτό).
- Χρειάζεστε μια φιλοξενούμενη λύση, επομένως βεβαιωθείτε ότι το ποσοστό αποτυχίας είναι μηδενικό και καμία από τις εργασίες δεν θα χαθεί.
- Δεν θέλετε να δημιουργήσετε ένα σύμπλεγμα και πρέπει να το παρακολουθείτε μόνοι σας. Ή χειρότερα, πρέπει να δημιουργήσετε εργαλεία παρακολούθησης όταν θα μπορούσατε να χρησιμοποιήσετε αυτόν τον χρόνο για να κάνετε παραγωγική ανάπτυξη.
- Έχετε ήδη σημαντικές επενδύσεις στην πλατφόρμα AWS και το να μένετε κλειδωμένοι είναι λογικό.
- Θέλετε ένα εστιασμένο, απλό σύστημα ουράς χωρίς κανένα από τα χνούδια που σχετίζονται με τη μετάδοση μηνυμάτων, τα πρωτόκολλα και οτιδήποτε άλλο.
Συνολικά, το Amazon SQS είναι μια σταθερή επιλογή για όποιον θέλει να ενσωματώσει ουρές εργασίας στο σύστημά του και δεν χρειάζεται να ανησυχεί για την εγκατάσταση/παρακολούθηση πραγμάτων μόνος του.
Beanstalkd
Beanstalkd υπάρχει εδώ και πολύ καιρό και είναι ένα δοκιμασμένο στη μάχη, γρήγορο, εύκολο backend για ουρά εργασίας. Υπάρχουν μερικά χαρακτηριστικά του Beanstalkd που το κάνουν να διαφέρει σημαντικά από το Redis:
- Είναι αυστηρά ένα σύστημα ουράς εργασίας και τίποτα άλλο. Σπρώχνεις θέσεις εργασίας, οι οποίες έλκονται από τους εργαζόμενους αργότερα. Επομένως, εάν η εφαρμογή σας έχει έστω και μια μικρή ανάγκη για αποστολή μηνυμάτων, θα θέλατε να αποφύγετε το Beanstalkd.
- Δεν υπάρχουν προηγμένες δομές δεδομένων όπως σύνολα, ουρές προτεραιότητας κ.λπ.
- Το Beanstalkd είναι αυτό που ονομάζεται ουρά First In, First Out (FIFO). Δεν υπάρχει τρόπος να κανονίσετε θέσεις εργασίας κατά προτεραιότητα.
- Δεν υπάρχουν επιλογές για ομαδοποίηση.
Όλα αυτά είπε ότι το Beanstalkd δημιουργεί ένα λείο και γρήγορο σύστημα ουράς για απλά έργα που ζουν σε έναν μόνο διακομιστή. Για πολλούς, είναι πιο γρήγορο και πιο σταθερό από το Redis. Αν λοιπόν έχετε θέματα με το Redis που απλά δεν φαίνεται να μπορείτε να λύσετε ό,τι κι αν γίνει, και οι ανάγκες σας είναι απλές, το Beanstalkd αξίζει να δοκιμάσετε.
συμπέρασμα
Αν έχετε διαβάσει μέχρι εδώ (ή έχετε φτάσει εδώ για να διαβάζετε 😉 ), υπάρχει πολύ καλή πιθανότητα να σας ενδιαφέρουν τα συστήματα ουράς ή να χρειάζεστε ένα. Αν ναι, η λίστα σε αυτήν τη σελίδα θα σας εξυπηρετήσει καλά, εκτός και αν ψάχνετε για ένα σύστημα ουράς για συγκεκριμένη γλώσσα/πλαίσιο.
Μακάρι να μπορούσα να σας πω ότι η ουρά είναι απλή και 100% αξιόπιστη, αλλά δεν είναι. Είναι ακατάστατο, και αφού είναι όλα στο παρασκήνιο και συμβαίνουν πολύ γρήγορα (τα λάθη μπορεί να περάσουν απαρατήρητα και να γίνουν πολύ δαπανηρά). Ωστόσο, οι ουρές είναι πολύ απαραίτητες πέρα από ένα σημείο, και θα διαπιστώσετε ότι είναι ένα ισχυρό όπλο (ίσως και το πιο ισχυρό) στο οπλοστάσιό σας. Καλή τύχη! 🙂