I 6 migliori sistemi di accodamento per sviluppatori di back-end

Pubblicato: 2019-08-09

Cerchi un sistema di code? O forse ne stai cercando uno migliore? Ecco tutte le informazioni di cui hai bisogno!

I sistemi di accodamento sono il segreto meglio custodito dello sviluppo di back-end.

Senza cercare di scrivere una poesia in lode dei sistemi di accodamento, direi che uno sviluppatore di backend junior diventa uno sviluppatore di backend di livello medio dopo aver imparato a integrare le code nel sistema. Le code migliorano l'esperienza del cliente (vedremo come), riducono la complessità e migliorano l'affidabilità di un sistema.

Certo, per app Web molto semplici con traffico quasi zero e siti Web di brochure, le code possono essere un problema generale (o addirittura impossibile da installare se ti trovi in un tipico ambiente di hosting condiviso), ma le app non banali trarranno vantaggio dalla coda sistemi e app di grandi dimensioni sono impossibili senza la coda.

Prima di iniziare, un disclaimer: se sei già a tuo agio con i sistemi di coda e vuoi confrontare le varie opzioni, le prossime sezioni introduttive ti indurranno a dormire molto. Quindi sentiti libero di saltare avanti. Le sezioni introduttive sono pensate per coloro che hanno solo una vaga idea dei sistemi di code o hanno appena sentito il nome di sfuggita.

Che cos'è un sistema di code?

Cominciamo col capire cos'è una coda.

Una coda è una struttura di dati nell'informatica che imita, beh, le code del mondo reale che vediamo intorno a noi. Se vai in una biglietteria, ad esempio, noterai che dovrai stare in fondo alla fila, mentre la persona all'inizio della coda prenderà il biglietto per prima. Questo è ciò che chiamiamo anche il fenomeno del “primo arrivato, primo servito”. In informatica, è possibile scrivere programmi che memorizzano i loro compiti come questo in una coda, elaborandoli uno per uno sulla stessa base, primo arrivato, primo servito.

Si noti che la coda non esegue alcuna elaborazione effettiva. È solo una sorta di archiviazione temporanea in cui le attività aspettano fino a quando non vengono raccolte da qualcosa. Se tutto questo suona un po' troppo astratto, non preoccuparti. È un concetto astratto, ma vedremo esempi chiari nella prossima sezione.

Perché hai bisogno di sistemi di coda?

Senza entrare in una descrizione molto lunga, direi che la necessità principale dei sistemi di accodamento è dovuta all'elaborazione in background, all'esecuzione parallela e al ripristino da un errore. Diamo un'occhiata a questi con l'aiuto di esempi:

Elaborazione in background

Supponiamo che tu stia eseguendo una campagna di marketing e-commerce in cui il tempo è essenziale e che la tua applicazione sia costruita in modo da inviare un'e-mail di conferma subito prima che il cliente completi il pagamento e venga mostrata la pagina di ringraziamento. Se il server di posta a cui ti stai connettendo è inattivo, la pagina Web morirà, interrompendo l'esperienza dell'utente.

Immagina l'alto numero di richieste di supporto che riceveresti! In questo caso, è meglio inviare questa attività di invio di e-mail a una coda di lavoro e mostrare al cliente la pagina di successo.

Esecuzione parallela

Molti sviluppatori, in particolare quelli che codificano principalmente app più semplici e a basso traffico, hanno l'abitudine di utilizzare i lavori cron per l'elaborazione in background. Questo va bene finché la dimensione dell'input non diventa così grande da non poter essere cancellata. Ad esempio, supponiamo di avere un cron job che compila report di analisi e li invia tramite posta elettronica agli utenti e che il tuo sistema può elaborare 100 report al minuto.

Non appena la tua app cresce e inizia a ricevere in media più di 100 richieste al minuto, inizierà a rimanere sempre più indietro e non sarà mai in grado di completare tutti i lavori.

In un sistema di coda, questa situazione può essere evitata impostando più lavoratori, ognuno dei quali può prelevare un lavoro (contenente 100 rapporti da eseguire ciascuno) e lavorare in parallelo per terminare l'attività molto, molto prima.

Recupero dal fallimento

Generalmente non pensiamo al fallimento come sviluppatori web. Diamo per scontato che i nostri server e le API che utilizziamo saranno sempre online. Ma la realtà è diversa: le interruzioni di rete sono fin troppo comuni e le eccellenti API su cui fai affidamento potrebbero non funzionare a causa di problemi di infrastruttura (prima di dire "non io!", non dimenticare la massiccia interruzione di Amazon S3). Quindi, tornando all'esempio dei rapporti, se parte della generazione dei rapporti richiede la connessione all'API dei pagamenti e tale connessione si interrompe per 2 minuti, cosa succede ai 200 rapporti non riusciti?

Tuttavia, i sistemi di accodamento comportano un notevole sovraccarico. La curva di apprendimento è piuttosto ripida quando si entra in un dominio completamente nuovo, la complessità dell'applicazione e della distribuzione aumenta e i lavori in coda non possono sempre essere controllati con una precisione del 100%. Detto questo, ci sono situazioni in cui non è possibile creare un'applicazione senza code.

Detto questo, diamo un'occhiata ad alcune delle opzioni comuni tra i backend/sistemi di accodamento oggi.

Redis

Redis è noto come un archivio chiave-valore che archivia, aggiorna e recupera stringhe di dati senza alcuna conoscenza della struttura dei dati. Sebbene ciò potesse essere vero prima, oggi Redis ha strutture di dati efficienti e molto utili come elenchi, set ordinati e persino un sistema Pub-Sub, il che lo rende altamente desiderabile per le implementazioni di code.

I vantaggi di Redis sono:

Database completamente in memoria, con conseguente velocità di lettura/scrittura.
Altamente efficiente: può supportare facilmente più di 100.000 operazioni di lettura/scrittura al secondo.
Schema di persistenza altamente flessibile. Puoi optare per le massime prestazioni al costo di una possibile perdita di dati in caso di guasti o impostare in modalità completamente conservativa per sacrificare le prestazioni per coerenza.
Cluster supportati immediatamente

Tieni presente che Redis non ha alcuna astrazione di messaggistica/accodamento/ripristino, quindi devi utilizzare un pacchetto o creare tu stesso un sistema leggero. Un esempio è che Redis è il backend di coda predefinito per il framework PHP Laravel, in cui uno scheduler è stato implementato dagli autori del framework.

Imparare Redis è facile.

Coniglio MQ

Ci sono alcune sottili differenze tra Redis e RabbitMQ, quindi prima togliamoli di mezzo.

Prima di tutto, RabbitMQ ha un ruolo più specializzato e ben definito, quindi è stato costruito per riflettere questo: la messaggistica. In altre parole, il suo punto debole è fungere da intermediario tra due sistemi, il che non è il caso di Redis, che funge da database. Di conseguenza, RabbitMQ fornisce alcune altre funzionalità che mancano in Redis: routing dei messaggi, tentativi, distribuzione del carico, ecc.

Se ci pensi, le code di attività possono anche essere pensate come un sistema di messaggistica, in cui lo scheduler, i lavoratori e gli "inviatori" del lavoro possono essere considerati entità che partecipano al passaggio di messaggi.

RabbitMQ presenta i seguenti vantaggi:

Migliori astrazioni per il passaggio dei messaggi, riducendo il lavoro a livello di applicazione se il passaggio dei messaggi è ciò di cui hai bisogno.
Più resiliente a interruzioni di corrente e interruzioni (rispetto a Redis, almeno per impostazione predefinita).
Supporto per cluster e federazione per distribuzioni distribuite.
Strumenti utili per la gestione e il monitoraggio delle implementazioni.
Supporto per praticamente tutti i linguaggi di programmazione non banali là fuori.
Distribuzione con il tuo strumento preferito (Docker, Chef, Puppet, ecc.).

Quando usare RabbitMQ? Direi che è un'ottima scelta quando sai che devi utilizzare il passaggio di messaggi asincrono ma non sei pronto ad affrontare l'enorme complessità di alcune delle altre opzioni di accodamento in questo elenco (vedi sotto).

ActiveMQ

Se sei nello spazio aziendale (o stai costruendo un'app altamente distribuita e su larga scala) e non vuoi dover reinventare la ruota tutto il tempo (e commettere errori lungo il percorso), vale la pena dare un'occhiata ad ActiveMQ .

Ecco dove eccelle ActiveMQ:

È implementato in Java e quindi ha un'integrazione Java davvero ordinata (segue lo standard JMS).
Più protocolli supportati: AMQP, MQTT, STOMP, OpenWire, ecc.
Gestisce immediatamente la sicurezza, il routing, la scadenza dei messaggi, l'analisi e così via.
Supporto integrato per i modelli di messaggistica distribuiti più diffusi, che ti fanno risparmiare tempo e costosi errori.

Questo non vuol dire che ActiveMQ sia disponibile solo per Java. Ha client per Python, C/C++, Node, .Net e altri ecosistemi, quindi non dovrebbero esserci preoccupazioni per un possibile crollo in futuro. Inoltre, ActiveMQ è basato su standard completamente aperti e creare i tuoi client leggeri dovrebbe essere facile.

Detto questo, tieni presente che ActiveMQ è solo un broker e non include un back-end. Dovresti comunque utilizzare uno dei backend supportati per archiviare i messaggi. L'ho incluso qui perché non è legato a un particolare linguaggio di programmazione (come altre soluzioni popolari come Celery, Sidekiq, ecc.)

Amazon MQ

Amazon MQ merita una menzione veloce ma importante qui. Se ritieni che ActiveMQ sia la soluzione ideale per le tue esigenze ma non vuoi occuparti della costruzione e della manutenzione dell'infrastruttura da solo, Amazon MQ offre un servizio gestito per farlo. Supporta tutti i protocolli che ActiveMQ fa - non c'è alcuna differenza nelle funzionalità - poiché utilizza lo stesso ActiveMQ sotto la superficie.

Il vantaggio è che si tratta di un servizio gestito, quindi non devi preoccuparti di nient'altro che utilizzarlo. Ha ancora più senso per quelle distribuzioni che si trovano su AWS, poiché puoi sfruttare altri servizi e offerte direttamente dall'interno della tua distribuzione (trasferimenti di dati più veloci, ad esempio).

Amazon SQS

Non possiamo aspettarci che Amazon rimanga in silenzio quando si tratta di pezzi di infrastruttura critici, vero?

E così abbiamo Amazon SQS, che è un servizio di coda semplice e completamente ospitato (letteralmente) dal famoso gigante AWS. Ancora una volta, le sottili differenze sono importanti, quindi tieni presente che SQS non ha il concetto di passaggio di messaggi. Come Redis, è un semplice back-end per accettare e distribuire lavori in coda.

Quindi, quando vorresti utilizzare Amazon SQS? Ecco alcuni motivi:

Sei un fan di AWS e non toccherai nient'altro (onestamente, ci sono molte persone così là fuori, e penso che non ci sia niente di sbagliato in questo).
Hai bisogno di una soluzione in hosting, quindi assicurati che il tasso di errore sia zero e che nessuno dei lavori vada perso.
Non vuoi creare un cluster e devi monitorarlo da solo. O peggio, devi creare strumenti di monitoraggio quando potresti usare quel tempo per fare sviluppo produttivo.
Hai già ingenti investimenti nella piattaforma AWS e rimanere bloccato ha senso per gli affari.
Vuoi un sistema di accodamento mirato e semplice senza la confusione associata al passaggio di messaggi, ai protocolli e quant'altro.

Tutto sommato, Amazon SQS è una scelta solida per chiunque desideri incorporare le code di lavoro nel proprio sistema e non deve preoccuparsi di installare/monitorare le cose da solo.

Beanstalkd

Beanstalkd è in circolazione da molto tempo ed è un backend collaudato, veloce e facile per l'accodamento dei lavori. Ci sono alcune caratteristiche di Beanstalkd che lo rendono notevolmente diverso da Redis:

È rigorosamente un sistema di accodamento dei lavori e nient'altro. Spingi i posti di lavoro, che in seguito vengono ritirati dai lavoratori. Quindi, se la tua applicazione ha anche un minimo bisogno di passaggio di messaggi, dovresti evitare Beanstalkd.
Non ci sono strutture di dati avanzate come set, code di priorità, ecc.
Beanstalkd è quella che viene definita una coda FIFO (First In, First Out). Non c'è modo di organizzare i lavori per priorità.
Non ci sono opzioni per il clustering.

Detto questo, Beanstalkd crea un sistema di code fluido e veloce per progetti semplici che risiedono su un singolo server. Per molti, è più veloce e più stabile di Redis. Quindi, se hai problemi con Redis che non riesci a risolvere, qualunque cosa accada, e le tue esigenze sono semplici, vale la pena provare Beanstalkd.

Conclusione

Se hai letto fino a qui (o hai raggiunto qui la lettura scrematura), ci sono buone probabilità che tu sia interessato ai sistemi di coda o ne abbia bisogno. In tal caso, l'elenco in questa pagina ti sarà utile, a meno che tu non stia cercando un sistema di code specifico per lingua/framework.

Vorrei poterti dire che fare la fila è semplice e affidabile al 100%, ma non lo è. È disordinato e poiché è tutto in background e accade molto velocemente (gli errori possono passare inosservati e diventare molto costosi). Tuttavia, le code sono assolutamente necessarie oltre un certo punto e scoprirai che sono un'arma potente (forse anche la più potente) nel tuo arsenale. Buona fortuna!