How does that makes mysql more free? does it?
Non lo è.
Sebbene la soluzione di avere scritture asincrone potrebbe sembrare un po 'troppo estesa, non lo è. Oltre ai miglioramenti delle prestazioni dal punto di vista dell'utente (non sta più aspettando che le scritture finiscano, come già menzionato), ci sono altri vantaggi.
Che cosa sono esattamente le scritture del database (ignorante del motore di database, non importa)? Di solito sono azioni generate dall'input dell'utente.
La cosa è, se la richiesta dell'utente supera la convalida dell'input (significa che i codici come 400 Bad Request o 412 Precondition Failed non sono stati restituiti) e la richiesta è effettivamente corretta, la cui responsabilità è assicurarsi che la richiesta venga completata anche se qualcosa non riesce temporaneamente sul server? È responsabilità dell'utente riprovare dopo aver ricevuto l'errore 500 Internal Server o il programmatore del server deve gestirlo?
Credo che i casi limite come gli errori interni del server siano il programmatore e non l'errore dell'utente e in quanto tale è responsabilità del programmatore assicurarsi che le richieste valide che terminano con 500 finiscano effettivamente.
In che modo entrano in gioco code di messaggi, come RabbitMQ?
Rendono molto più semplice l'organizzazione e la ripetizione delle richieste non riuscite.
Immaginiamo uno scenario in cui l'applicazione utilizzata dagli utenti comunica con un server attraverso una semplice API REST. L'azione dell'utente genera una richiesta critica al server che deve essere elaborata e, in caso contrario, si tratta di un problema enorme.
In un normale scenario sincrono, l'azione fallisce e l'utente è immediatamente (o forse dopo alcuni secondi, a seconda del processo) notificato che l'azione è fallita e dovrebbe riprovare. Ma cosa succede se non lo fanno, perché probabilmente non hanno voglia di aspettare altri secondi? Potresti aver semplicemente perso alcuni dati importanti sul client, per non dire che potrebbe aver perso anche il cliente perché lo stavi costantemente disturbando con l'attesa.
Ora immagina che invece di inviare la richiesta in modo sincrono, l'applicazione client lo inviasse a RabbitMQ. Poiché la coda è un servizio molto semplice, ci sono poche possibilità che fallisca. L'utente viene immediatamente informato che la sua richiesta è stata accettata e che verrà notificata una volta che la richiesta è stata elaborata.
Il consumatore recupera il messaggio dalla coda e inizia l'elaborazione. Poiché attualmente stai riscontrando alcuni problemi sul server, l'elaborazione della richiesta critica è fallita diverse volte. Dopo ogni richiesta il messaggio è stato riacceso per riprovare. È appena successo che il 5 ° tentativo abbia finalmente completato il processo, così hai avvertito l'utente della situazione.
How can this architecture scale? (in my speciphic use case as
described above.)
Puoi scalare orizzontalmente l'applicazione aggiungendo altri nodi che agiscono come consumatori dei messaggi RabbitMQ, il che è molto buono. Inoltre, dal punto di vista dell'utente, l'applicazione viene eseguita più velocemente, poiché le richieste, come già accennato, sono asincrone ed elaborate in futuro.