Differenza tra operazioni sincrone ed asincrone in informatica

Nello sviluppo di un’architettura per una web app, i vari processi logici ed i flussi di dati che passano da un componente ad un altro, innescati ad esempio in seguito ad una certa azione dell’utente, possono essere distinti in base alle loro caratteristiche di sincronia o asincronia.

Un’operazione sincrona è un tipo di chiamata o richiesta ad un certo servizio o componente tale per cui l’esecuzione del codice di questa operazione si arresterà e rimarrà in attesa fino a quando il servizio interrogato non avrà completato a sua volta le operazioni necessarie per elaborare un certo tipo di risposta da trasmettere finalmente alla prima operazione.

Questo tipo di interazioni di richiesta e risposta tra servizi può anche concatenarsi ed arrivare ad impegnare più componenti allo stesso tempo: è evidente quindi che, specialmente se tali componenti non risiedono sulla stessa macchina ma sono distribuiti tra più macchine distinte, come accade nel caso di un’architettura a microservizi, la latenza di rete esistente tra gli strati dell’applicazione si somma e può dare luogo a rallentamenti per l’intero sistema.

In alcuni casi, la sincronia nelle operazioni è accettabile, se ad esempio il flusso di operazioni da compiere è molto semplice oppure se può essere garantita una certa velocità di esecuzione; in altri casi, la sincronia è necessaria: si pensi all’erogazione di un servizio a pagamento, che può procedere solamente in caso l’operazione di acquisto sia andata a buon fine.

Nei casi in cui la sincronia non sia necessaria e possa dare luogo a ritardi non indifferenti, si può ricorrere ad un sistema di operazioni asincrone. Per implementare operazioni di questo genere si possono utilizzare due modelli differenti: le code di messaggi o la messaggistica Pub/Sub.

Le code di messaggi rappresentano un paradigma che consente di disaccoppiare il tasso di richieste tra due servizi. In una coda di messaggi, un servizio che agisce da mittente, detto producer, inoltra la propria richiesta verso un certo altro servizio destinatario, detto consumer; la richiesta non è però inviata direttamente al destinatario: essa infatti viene prima inserita in una coda di dati amministrati da un servizio terzo, che agisce come gestore di tutte le richieste asincrone del sistema. In questo modo, il servizio emittente potrà generare una serie di richieste ad un certo tasso, mentre il servizio destinatario potrà rispondere ad un un altro tasso, anche più lento del primo, poiché le informazioni riguardanti tutte le richieste da soddisfare saranno conservate in sicurezza nella coda di messaggi.

Nel modello della coda di messaggi, ogni messaggio parte da un singolo producer ed arriva ad un certo singolo consumer: per questa ragione, il modello viene spesso definito one-to-one (uno-a-uno) o point-to-point (punto-a-punto). Per superare questa limitazione, si può ricorrere ad un sistema di messaggistica Pub/Sub, abbreviazione di Publisher/Subscriber, traducibile come “Pubblicante-Iscritto”: in questo modello, i servizi a monte, ovvero i publisher, inoltrano informazioni ad un certo topic (“argomento”), ovvero una raccolta di messaggi; a questo punto, i messaggi contenuti in questa raccolta verranno schedulati per l’invio a tutti i servizi a valle etichettati come “iscritti” a tale topic.

I messaggi saranno conservati nel topic fino a quando gli iscritti non saranno in grado di riceverli ma, al contrario della coda di messaggi, che in genere può garantire un comportamento FIFO (First-In-First-Out), l’ordine di ricezione delle informazioni potrebbe non rispettare l’ordine cronologico di emissione.