Διπλότυπα παραγγελιών κατά την εργασία με API: αιτίες και προστασία

Γιατί εμφανίζονται διπλότυπα μετά από μία μόνο ενέργεια

Ο ιδιοκτήτης του πάνελ μπορεί να πατήσει το κουμπί μία φορά και να δει πολλαπλές πανομοιότυπες παραγγελίες: για συνδρομητές, προβολές, αντιδράσεις ή άλλη υπηρεσία. Συνήθως το πρόβλημα δεν βρίσκεται στο ίδιο το κλικ, αλλά στην αλυσίδα μεταξύ πελάτη, API, βάσης δεδομένων και προμηθευτή.

Από την πλευρά του διακομιστή, το «ένα αίτημα» δεν είναι πάντα ένα. Ο πελάτης μπορεί να μην έλαβε απάντηση, να επανέλαβε την αποστολή, ενώ η πρώτη λειτουργία είχε ήδη αποθηκευτεί. Μερικές φορές η παραγγελία δημιουργείται μία φορά στη βάση του πάνελ, αλλά αποστέλλεται δύο φορές στον προμηθευτή. Πρόκειται για διαφορετικά σενάρια, και διορθώνονται με διαφορετικό τρόπο.

Το χρονικό όριο δεν σημαίνει ότι η παραγγελία δεν δημιουργήθηκε

Η πιο συχνή αιτία είναι ότι ο πελάτης περιμένει απάντηση για περιορισμένο χρόνο. Ο διακομιστής λαμβάνει το αίτημα, δημιουργεί την παραγγελία, αλλά απαντά αργότερα από το καθορισμένο χρονικό όριο. Ο πελάτης θεωρεί τη λειτουργία αποτυχημένη και την αποστέλλει ξανά.

Ως αποτέλεσμα, η πρώτη παραγγελία υπάρχει ήδη στη βάση και το δεύτερο αίτημα δημιουργεί άλλη μία. Αυτό συμβαίνει ιδιαίτερα συχνά με αργή απάντηση εξωτερικού API, υπερφορτωμένη ουρά ή ασταθή σύνδεση μεταξύ των υπηρεσιών.

Το χρονικό όριο δηλώνει μόνο την απουσία απάντησης, όχι την απουσία επεξεργασίας του αιτήματος.

Αυτόματες επαναλήψεις στην πλευρά του πελάτη

Οι βιβλιοθήκες για HTTP αιτήματα, οι εργασίες στο παρασκήνιο και οι υπηρεσίες ενσωμάτωσης συχνά επαναλαμβάνουν το αίτημα αυτόματα. Αφορμή μπορεί να είναι σφάλμα σύνδεσης, κωδικός απάντησης διακομιστή, διακοπή δικτύου ή πολύ αργή απάντηση.

Η επανάληψη καθαυτή είναι χρήσιμη: μειώνει τον αριθμό των χαμένων παραγγελιών σε περίπτωση προσωρινών βλαβών. Το μειονέκτημα αυτής της προσέγγισης είναι ότι, χωρίς προστασία από επανεπεξεργασία, μετατρέπει οποιαδήποτε αστάθεια δικτύου σε διπλότυπα.

• η επανάληψη μπορεί να ξεκινά στον κώδικα του ιστότοπου ή του bot;
• η εργασία μπορεί να επανεκκινείται από την ουρά;
• το αίτημα μπορεί να επαναλαμβάνεται από διακομιστή μεσολάβησης ή μονάδα ενσωμάτωσης;
• ο χειριστής μπορεί να στείλει χειροκίνητα ξανά την παραγγελία μετά από σφάλμα.

Το επαναλαμβανόμενο αίτημα φτάνει πριν από την πρώτη απάντηση

Μερικές φορές δύο πανομοιότυπα αιτήματα φτάνουν πράγματι στο API σχεδόν ταυτόχρονα. Για παράδειγμα, ο χρήστης υπέβαλε τη φόρμα δύο φορές, το frontend δεν απενεργοποίησε το κουμπί ή η εργασία στο παρασκήνιο ξεκίνησε ξανά πριν ολοκληρωθεί η πρώτη.

Αν ο χειριστής ελέγχει πρώτα την ύπαρξη της παραγγελίας και μετά τη δημιουργεί, δύο παράλληλες λειτουργίες μπορούν να περάσουν τον έλεγχο ταυτόχρονα. Καθεμία θα δει ότι η παραγγελία δεν υπάρχει ακόμη και καθεμία θα προσθέσει νέα εγγραφή.

Αυτή η κατάσταση ονομάζεται συνθήκη ανταγωνισμού. Ένας απλός προκαταρκτικός έλεγχος στον κώδικα δεν προστατεύει πλήρως από αυτήν. Το μειονέκτημα του ελέγχου χωρίς περιορισμό σε επίπεδο βάσης δεδομένων είναι ότι καταρρέει υπό παράλληλο φόρτο.

Η παραγγελία καταχωρήθηκε, αλλά η απάντηση του API χάθηκε

Το αίτημα περνά από πολλά στάδια: ο διακομιστής λαμβάνει τα δεδομένα, δημιουργεί την εγγραφή, θέτει την εργασία σε ουρά, στέλνει την απάντηση. Σφάλμα μπορεί να προκύψει μεταξύ οποιουδήποτε από αυτά. Για παράδειγμα, η βάση δεδομένων επιβεβαίωσε ήδη τη δημιουργία της παραγγελίας, αλλά η σύνδεση διακόπηκε πριν από τη μεταβίβαση της απάντησης στον πελάτη.

Ο πελάτης δεν γνωρίζει αν η παραγγελία έγινε δεκτή και επαναλαμβάνει τη λειτουργία. Το API χωρίς ξεχωριστό μηχανισμό ελέγχου αντιλαμβάνεται το αίτημα ως νέο. Στο αρχείο καταγραφής αυτό συχνά φαίνεται σαν η υπηρεσία να δημιούργησε δύο παραγγελίες «μόνη της», ενώ είχε δύο εισερχόμενες κλήσεις.

Κλειδί idempotency για τη δημιουργία παραγγελίας

Για τις λειτουργίες δημιουργίας απαιτείται μοναδικό κλειδί idempotency. Ο πελάτης το δημιουργεί πριν από την πρώτη αποστολή και το μεταβιβάζει μαζί με τις παραμέτρους της παραγγελίας. Σε περίπτωση επανάληψης λόγω χρονικού ορίου ή σφάλματος χρησιμοποιείται το ίδιο κλειδί.

Το API αποθηκεύει το κλειδί μαζί με το αποτέλεσμα της επεξεργασίας. Αν φτάσει αίτημα με ήδη γνωστό κλειδί, ο διακομιστής δεν δημιουργεί νέα παραγγελία, αλλά επιστρέφει το αποτέλεσμα της πρώτης κλήσης: το αναγνωριστικό της παραγγελίας, την κατάστασή της ή το σφάλμα που είχε σχηματιστεί προηγουμένως.

Ένα κλειδί πρέπει να αντιστοιχεί σε μία επιχειρηματική λειτουργία, όχι σε μία σύνδεση HTTP.

Το μειονέκτημα της μεθόδου είναι ότι τα κλειδιά πρέπει να αποθηκεύονται, να καθαρίζονται σύμφωνα με κανόνες και να ελέγχονται στην πλευρά του API. Αν δημιουργείται νέο κλειδί σε κάθε επανάληψη, η προστασία δεν θα λειτουργήσει. Αν χρησιμοποιείται ένα κλειδί για διαφορετικές παραγγελίες, μέρος των νέων λειτουργιών θα απορρίπτεται εσφαλμένα.

Η μοναδικότητα πρέπει να ελέγχεται από τη βάση δεδομένων

Η idempotency καλύτερα να συμπληρώνεται από περιορισμό μοναδικότητας στη βάση δεδομένων. Για τον σκοπό αυτό επιλέγεται ένας συνδυασμός που περιγράφει μονοσήμαντα την παραγγελία: εσωτερικό αναγνωριστικό πελάτη, κλειδί idempotency, τύπος υπηρεσίας και άλλα απαραίτητα πεδία.

Η βάση δεδομένων πρέπει να απορρίπτει τη δεύτερη εγγραφή, ακόμη και αν δύο χειριστές έφτασαν ταυτόχρονα στη δημιουργία. Μετά τη σύγκρουση, το API επιστρέφει την υπάρχουσα παραγγελία και όχι σφάλμα χωρίς εξήγηση.

Το μειονέκτημα του αυστηρού περιορισμού μοναδικότητας είναι ότι δεν μπορεί να βασίζεται μόνο στον σύνδεσμο ή στο username. Ο πελάτης μπορεί συνειδητά να παραγγείλει την ίδια υπηρεσία για το ίδιο κανάλι πολλές φορές. Ένας πολύ ευρύς περιορισμός θα μπλόκαρε κανονικές επαναλαμβανόμενες αγορές.

Η ουρά μπορεί να παραδώσει την εργασία περισσότερες από μία φορές

Οι ουρές εργασιών συχνά λειτουργούν με την αρχή «παράδοση τουλάχιστον μία φορά». Αν ο worker επεξεργάστηκε την εργασία αλλά δεν πρόλαβε να επιβεβαιώσει την εκτέλεσή της, η ουρά μπορεί να παραδώσει την ίδια εργασία ξανά σε άλλον worker.

Για την ουρά αυτός είναι ένας κανονικός τρόπος να μην χαθεί η εργασία. Για τη δημιουργία παραγγελίας χωρίς idempotency — πηγή διπλοτύπων. Το αναγνωριστικό της εργασίας ή ένα ξεχωριστό κλειδί λειτουργίας πρέπει να μεταβιβάζεται μέχρι τον τελικό χειριστή, συμπεριλαμβανομένης της μονάδας αποστολής της παραγγελίας στον προμηθευτή.

Το μειονέκτημα της απενεργοποίησης της επαναλαμβανόμενης παράδοσης είναι ότι σε περίπτωση πτώσης του worker μέρος των παραγγελιών μπορεί να χαθεί. Είναι ασφαλέστερο να γίνονται δεκτές οι πιθανές επαναλήψεις και να καθίσταται ο χειριστής ανθεκτικός σε αυτές.

Τα διπλότυπα προκύπτουν μεταξύ πάνελ και προμηθευτή

Η εσωτερική παραγγελία μπορεί να δημιουργηθεί μία φορά, αλλά το αίτημα προς το εξωτερικό API να σταλεί δύο φορές. Η αιτία είναι η ίδια: το πάνελ δεν έλαβε απάντηση από τον προμηθευτή και αποφάσισε να επαναλάβει την αποστολή. Αν ο προμηθευτής πρόλαβε να δεχτεί το πρώτο αίτημα, στην πλευρά του θα εμφανιστούν δύο πανομοιότυπες αιτήσεις.

Απαιτείται ξεχωριστή σύνδεση της εσωτερικής παραγγελίας με την εξωτερική: αναγνωριστικό αποστολής, κλειδί idempotency ή αποθηκευμένη απάντηση του προμηθευτή. Δεν μπορεί να θεωρηθεί ότι η προστασία στην είσοδο του δικού μας πάνελ θα προστατεύσει αυτόματα και τις εξερχόμενες κλήσεις.

Το μειονέκτημα του συγχρονισμού με εξωτερικό API είναι ότι δεν υποστηρίζουν όλοι οι προμηθευτές αναζήτηση βάσει εξωτερικού κλειδιού. Τότε αναγκαστικά καταγράφονται οι προσπάθειες αποστολής και εξετάζονται ξεχωριστά οι αβέβαιες καταστάσεις.

Το webhook δεν πρέπει να δημιουργεί νέα παραγγελία

Τα webhooks ενημερώνουν για αλλαγές: η παραγγελία έγινε δεκτή, ξεκίνησε, εκτελέστηκε, ακυρώθηκε ή χρειάζεται έλεγχο. Το σφάλμα προκύπτει όταν ο χειριστής του webhook αντιλαμβάνεται την ειδοποίηση ως εντολή να δημιουργήσει ξανά την παραγγελία.

Το ίδιο webhook μπορεί να φτάσει επανειλημμένα. Ο αποστολέας επαναλαμβάνει την παράδοση αν δεν έλαβε επιβεβαίωση, ενώ οι ειδοποιήσεις μερικές φορές φτάνουν εκτός σειράς. Ο χειριστής πρέπει να εντοπίζει την υπάρχουσα παραγγελία βάσει εξωτερικού αναγνωριστικού και να ενημερώνει την κατάσταση.

Το μειονέκτημα της επεξεργασίας webhooks μόνο βάσει χρόνου λήψης είναι ότι μια καθυστερημένη ειδοποίηση μπορεί να αντικαταστήσει την τρέχουσα κατάσταση με παρωχημένη. Απαιτούνται αναγνωριστικό συμβάντος, έκδοση κατάστασης ή σαφείς κανόνες μεταβάσεων.

Ποιες εγγραφές θα βοηθήσουν στον εντοπισμό της πηγής των διπλοτύπων

Για τη διερεύνηση δεν αρκεί να βλέπουμε μόνο δύο αριθμούς παραγγελιών. Χρειάζονται δεδομένα για κάθε στάδιο επεξεργασίας: χρόνος αιτήματος, κλειδί idempotency, αναγνωριστικό πελάτη, παράμετροι παραγγελίας, αριθμός εργασίας στο παρασκήνιο, απάντηση εξωτερικού API και προσπάθειες επαναποστολής.

• αντιστοιχίζετε τα διπλότυπα βάσει του κλειδιού λειτουργίας, όχι μόνο βάσει του συνδέσμου;
• ελέγχετε αν υπήρχαν πανομοιότυπα αιτήματα στο αρχείο καταγραφής του εισερχόμενου API;
• εξετάζετε αν η εργασία επαναλήφθηκε στην ουρά;
• διαχωρίζετε τη δημιουργία της εσωτερικής παραγγελίας από την αποστολή στον προμηθευτή;
• αποθηκεύετε το εξωτερικό αναγνωριστικό της αίτησης αμέσως μετά τη λήψη της απάντησης.

Το μειονέκτημα των πολύ σύντομων αρχείων καταγραφής είναι ότι η πηγή του προβλήματος εξαφανίζεται πριν προλάβει να αναλυθεί. Το μειονέκτημα της υπερβολικής καταγραφής είναι ότι στην εγγραφή μπορεί να περιέχονται tokens, προσωπικά δεδομένα και άλλα ευαίσθητα πεδία, γι' αυτό πρέπει να αποκρύπτονται.

Πώς να χειρίζεστε ένα αβέβαιο αποτέλεσμα αιτήματος

Μετά από χρονικό όριο δεν πρέπει να δημιουργείται αμέσως ξανά παραγγελία με νέα δεδομένα. Πρώτα το API πρέπει να ελέγχει τη λειτουργία βάσει του κλειδιού idempotency ή του αναγνωριστικού πελάτη. Αν η παραγγελία βρεθεί, επιστρέφεται η τρέχουσα κατάστασή της. Αν η επεξεργασία βρίσκεται ακόμη σε εξέλιξη, ο πελάτης λαμβάνει κατάσταση αναμονής.

1. Δημιουργία κλειδιού λειτουργίας πριν από το πρώτο αίτημα.
Αποστολή του ίδιου κλειδιού σε κάθε επανάληψη.
2. Αποθήκευση του κλειδιού και της παραγγελίας σε μία ασφαλή λειτουργία της βάσης δεδομένων.
3. Μεταβίβαση του αναγνωριστικού λειτουργίας στην ουρά και στο εξωτερικό API.
4. Επιστροφή της προηγουμένως δημιουργημένης παραγγελίας σε περίπτωση επαναλαμβανόμενης κλήσης.

Ένα τέτοιο σενάριο απαιτεί τροποποίηση του API και της ενσωμάτωσης στην πλευρά του πελάτη. Το μειονέκτημά του είναι δυσκολότερη αποσφαλμάτωση και περισσότερες καταστάσεις παραγγελίας, όμως η επαναλαμβανόμενη παράδοση αιτήματος παύει να σημαίνει αυτόματα επαναλαμβανόμενη αγορά.