Επιλέγοντας το anarchon

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

Όσα αναφέρει αυτή η σελίδα για άλλα εργαλεία ελέγχθηκαν στις 13 Οκτωβρίου 2026, με βάση τις εκδόσεις και τις σελίδες της ενότητας Πηγές. Τα εργαλεία αυτά αλλάζουν: διαβάστε τη δική τους τεκμηρίωση πριν αποφασίσετε.

Με λίγα λόγια

Προσέγγιση	Ταιριάζει όταν	Τι αναλαμβάνετε
anarchon	Επαναλαμβανόμενοι handlers που εκτελούνται μέσα στα instances της υπηρεσίας σας, με συντονισμό μέσω ενός store που ήδη μοιράζονται	Η ανάκαμψη εξαρτάται από το backend· οι προσπάθειες έχουν όριο· οι handlers πρέπει να είναι idempotent· ορισμένα slots παραλείπονται εκ σχεδιασμού
BullMQ	Εργασία σε ουρά: εκκρεμότητες, επαναλήψεις με backoff, όρια ρυθμού, ροές εξαρτώμενων εργασιών	Έννοιες και ρύθμιση ουράς· workers που πρέπει να εκτελούνται, στη διεργασία της εφαρμογής σας ή σε ξεχωριστές
node-cron	Χρονόμετρα σε μία διεργασία, ή ένας runner ανά προγραμματισμένο χρόνο με την επιλογή `distributed`	Τι συμβαίνει σε μια εκτέλεση της οποίας ο runner κατέρρευσε· η μίσθωση πρέπει να διαρκεί περισσότερο από την εκτέλεση
Δικό σας χρονόμετρο και lock	Μια ομάδα που θέλει να έχει δικό της τον κώδικα χρονοπρογραμματισμού και κλειδώματος	Ανανέωση, ανάκαμψη, ιστορικό, τερματισμός και συμπεριφορά σε αστοχίες: τα σχεδιάζετε και τα ελέγχετε εσείς
Kubernetes CronJob	Μαζική εργασία που πρέπει να εκτελείται στο δικό της container, χωριστά από την υπηρεσία	Ένα Pod ανά εκτέλεση· κύκλος ζωής Job και Pod· manifests προς συντήρηση

anarchon

Πού εκτελείται η εργασία. Μέσα στα instances της υπηρεσίας σας: ο handler είναι μια συνάρτηση της εφαρμογής σας.
Τι χρειάζεται. Ένα store προσβάσιμο από όλα τα instances: Redis, Valkey, PostgreSQL, SQLite σε ένα μηχάνημα, ή έναν libSQL server. Το RabbitMQ και το NATS λειτουργούν με λιγότερα χαρακτηριστικά.
Ποιος εκτελεί έναν προγραμματισμένο χρόνο. Κάθε instance υπολογίζει το ίδιο slot και προσπαθεί να το διεκδικήσει· ένα ατομικό βήμα στο store επιτρέπει σε ένα instance να κερδίσει κάθε προσπάθεια.
Όταν ο runner καταρρεύσει. Σε lease backend, ένα άλλο instance ξεκινά ξανά την εκτέλεση ως νέα προσπάθεια, περίπου μία μίσθωση αργότερα, έως maxAttempts φορές. Ο handler ξεκινά από την αρχή. Σε RabbitMQ, NATS και στις απλές στρατηγικές του Redis η εκτέλεση χάνεται.
Μακριές εκτελέσεις. Σε lease backend, η επόμενη εκτέλεση μιας εργασίας παραλείπεται όσο η τρέχουσα κρατά ενεργή μίσθωση.
Χαμένοι χρόνοι. Κατά την εκκίνηση εκτελείται μόνο η πιο πρόσφατη χαμένη εκτέλεση, και μόνο αν έπρεπε να τρέξει εντός του catchUpMs. Οι παλαιότερες δεν επαναλαμβάνονται.

Ο πίνακας των backends δείχνει ποιο backend έχει τι, και η σελίδα Εγγυήσεις και όρια αναφέρει τι υπόσχεται και τι όχι.

BullMQ

Το BullMQ είναι ουρά για εργασίες και μηνύματα. Οι Job Schedulers του παράγουν εργασίες από ένα χρονικό διάστημα ή ένα cron pattern, και οι workers τις επεξεργάζονται.

Πού εκτελείται η εργασία. Σε έναν Worker, τον οποίο δημιουργείτε σε μια διεργασία Node.js. Αυτή μπορεί να είναι η διεργασία της εφαρμογής σας ή μια ξεχωριστή· το ξεχωριστό deployment είναι επιλογή σας, όχι απαίτηση.
Τι χρειάζεται. Redis από προεπιλογή. Η τεκμηρίωσή του περιγράφει επίσης ένα προαιρετικό PostgreSQL backend (PostgreSQL 13 ή νεότερο) με το ίδιο API, και χαρακτηρίζει το Redis backend «the default and the most battle-tested option».
Όταν ένας worker σταματήσει να ανανεώνει το lock μιας εργασίας. Η τεκμηρίωση αναφέρει «a stalled job is moved back to the waiting status and will be processed again by another worker», και ότι μια εργασία που φτάνει τον μέγιστο αριθμό stalls μεταφέρεται στο σύνολο των αποτυχημένων.
Χρονοπρογραμματισμός. Ένας Job Scheduler «will only generate new jobs when the last job begins processing», επομένως μια φορτωμένη ουρά μπορεί να παράγει εργασίες αραιότερα από το διάστημα.

Επιλέξτε το BullMQ όταν η δουλειά είναι ουρά: πολλές εργασίες σε αναμονή, καθεμία προς επεξεργασία, με επαναλήψεις και backoff, προτεραιότητες, όρια ρυθμού ή ροές. Το anarchon δεν έχει τίποτα από αυτά. Αποφασίζει ποιο instance εκτελεί μια εργασία σε κάθε προγραμματισμένο χρόνο και δεν κρατά εκκρεμότητες.

node-cron

Το node-cron εκτελεί μια συνάρτηση με χρονόμετρο στη διεργασία που την προγραμμάτισε. Χωρίς κάτι επιπλέον, τρία instances εκτελούν την εργασία τρεις φορές.

Επικάλυψη. Το noOverlap παραλείπει μια εκτέλεση όσο η προηγούμενη βρίσκεται σε εξέλιξη.
Πολλά instances. Με distributed: true μια εργασία «fires on exactly one instance per scheduled time». Από προεπιλογή διαβάζει τη μεταβλητή περιβάλλοντος NODE_CRON_RUN: ορίζετε ένα instance ως runner, και αν αυτό είναι εκτός λειτουργίας η εργασία δεν εκτελείται. Για υψηλή διαθεσιμότητα η τεκμηρίωσή του παραπέμπει στο @node-cron/redis-coordinator, όπου τα instances διεκδικούν κάθε προγραμματισμένο χρόνο με μίσθωση (distributedLease, 30 s από προεπιλογή), και η μίσθωση πρέπει να διαρκεί περισσότερο από την εκτέλεση της εργασίας.
Όρια που δηλώνει. Η τεκμηρίωσή του το ονομάζει «a coordination primitive, not a transactional queue», αναφέρει ότι μια εκτέλεση μπορεί να συμβεί περισσότερες από μία φορές μετά από κατάρρευση και επανάληψη ή με μεγάλη απόκλιση ρολογιών, και συνιστά idempotent εργασίες. Δεν αναφέρει ότι άλλο instance αναλαμβάνει μια εκτέλεση της οποίας ο runner κατέρρευσε.

Επιλέξτε το node-cron όταν μία διεργασία εκτελεί το πρόγραμμα, ή όταν σας αρκεί ένας runner ανά προγραμματισμένο χρόνο. Το anarchon προσθέτει ανανεούμενη μίσθωση με ανάληψη της εκτέλεσης ενός runner που κατέρρευσε, παράδοση κατά τον τερματισμό, ανάκτηση μετά από downtime και ιστορικό εκτελέσεων, και σε stores πέρα από το Redis.

Δικό σας χρονόμετρο και lock

Μια βιβλιοθήκη χρονομέτρου και ένα κατανεμημένο lock, όπως ο αλγόριθμος Redlock, μπορούν να συνδυαστούν: κάθε instance προσπαθεί να πάρει ένα lock για τον προγραμματισμένο χρόνο, και ο κάτοχος εκτελεί την εργασία.

Η τεκμηρίωση του Redis για το Redlock αναφέρει τα όρια που τότε αναλαμβάνετε:

Ένα lock έχει χρόνο ισχύος και απελευθερώνεται αυτόματα όταν αυτός λήξει. Ο αμοιβαίος αποκλεισμός «is guaranteed only as long as the client holding the lock terminates its work within the lock validity time», επομένως μια μεγαλύτερη εργασία πρέπει να επεκτείνει το lock.
Σας λέει να μην υποθέτετε «that a lock is retained as long as the process that had acquired it is alive», και να υλοποιήσετε fencing tokens.
Το Redis δεν χρησιμοποιεί μονοτονικό ρολόι για τη λήξη, επομένως μια μετατόπιση του ρολογιού μπορεί να επιτρέψει σε περισσότερες από μία διεργασίες να κρατούν το lock.

Ένα lock απαντά στο «ποιος μπορεί να εκτελέσει τώρα». Δεν καταγράφει ότι μια εκτέλεση έγινε, δεν ξεκινά ξανά μια εγκαταλελειμμένη εκτέλεση, δεν την παραδίδει κατά τον τερματισμό και δεν ανακτά μια χαμένη. Με αυτή την προσέγγιση, ο κώδικας αυτός είναι δικός σας. Το anarchon υλοποιεί αυτά τα μέρη, και τα σενάρια αστοχίας του τα ελέγχουν με πραγματικές διεργασίες.

Kubernetes CronJob

Ένα CronJob δημιουργεί ένα Job βάσει προγράμματος, και το Job εκκινεί Pods που εκτελούν το container σας.

Πού εκτελείται η εργασία. Στο δικό της Pod, που εκκινείται για κάθε εκτέλεση, χωριστά από την υπηρεσία σας.
Επικάλυψη. Το concurrencyPolicy είναι Allow από προεπιλογή· το Forbid παραλείπει μια εκτέλεση όσο το προηγούμενο Job εκτελείται· το Replace αντικαθιστά το Job που εκτελείται.
Χαμένοι χρόνοι. Το startingDeadlineSeconds ορίζει πόσο αργά μπορεί να ξεκινήσει ένα Job. Αν χάθηκαν περισσότεροι από 100 χρόνοι, ο controller δεν εκκινεί το Job και καταγράφει σφάλμα.
Διπλές εκτελέσεις. Η τεκμηρίωση αναφέρει «there are certain circumstances where two Jobs might be created, or no Job might be created», και ότι γι’ αυτό τα Jobs πρέπει να είναι idempotent.
Pods. Το CronJob «is only responsible for creating Jobs that match its schedule, and the Job in turn is responsible for the management of the Pods it represents».

Επιλέξτε ένα CronJob όταν η δουλειά είναι ένα πρόγραμμα μαζικής επεξεργασίας με δικό του image, πόρους και κύκλο ζωής, ή όταν δεν πρέπει να μοιράζεται διεργασία με την κίνηση των αιτημάτων. Επιλέξτε το anarchon όταν η εργασία είναι συνάρτηση της υπηρεσίας: χρησιμοποιεί τις συνδέσεις, τη ρύθμιση και τον κώδικα που έχει ήδη η υπηρεσία, και εκτελείται σε διεργασία που έχει ήδη ξεκινήσει. Η συνταγή Rolling deploys στο Kubernetes δείχνει το anarchon μέσα σε ένα Deployment.

Πότε το anarchon είναι το λάθος εργαλείο

Κάθε εμφάνιση πρέπει να υποστεί επεξεργασία. Το anarchon παραλείπει slots εκ σχεδιασμού: όσο η προηγούμενη εκτέλεση συνεχίζεται, μετά από μεγάλο downtime, ή όταν ένα instance καθυστερήσει. Χρησιμοποιήστε ουρά, ή κάντε κάθε εκτέλεση να δουλεύει πάνω σε ό,τι εκκρεμεί.
Ροές εργασίας (workflows). Δεν έχει εξαρτώμενες εργασίες, fan-out, προτεραιότητες ή όρια ρυθμού.
Αυστηρός πραγματικός χρόνος. Μια εκτέλεση ξεκινά μεταξύ του slot της και του slot + jitterMs, και μια ανάληψη έρχεται περίπου μία μίσθωση μετά από μια κατάρρευση.
Exactly-once παρενέργειες. Μια εκτέλεση της οποίας ο runner αποτύχει ξεκινά ξανά από την αρχή. Κανένας scheduler δεν αναιρεί την ανάγκη για idempotent handlers.
Χωρίς κοινόχρηστο store. Instances που δεν μοιράζονται τίποτα δεν μπορούν να συντονιστούν μέσω του anarchon.
Η άδεια δεν ταιριάζει. Το anarchon διατίθεται υπό την AGPLv3 ή υπό εμπορική άδεια· το BullMQ και το redlock είναι MIT, το node-cron είναι ISC και το Kubernetes είναι Apache-2.0. Δείτε τις Άδειες χρήσης.

Πηγές

Εργαλείο	Έκδοση που ελέγχθηκε	Σελίδες
BullMQ	6.3.14	Workers, Stalled jobs, Job Schedulers, PostgreSQL backend
node-cron	4.6.0, με `@node-cron/redis-coordinator` 0.1.0	README, Distributed coordination
Redlock	Ο αλγόριθμος όπως τον τεκμηριώνει το Redis	Distributed Locks with Redis
Kubernetes	Τεκμηρίωση για την v1.37	CronJob