Ciao a tutti.
E bentornati.
Nel video di oggi parleremo del ruolo delle code di messaggi nelle transazioni dei database.
Vediamo quindi di capire questo aspetto con un caso d'uso.
Supponiamo di avere un singolo database ospitato su RDF.
Ora, a causa di una promozione di vendita in corso, il numero di transazioni corrette che si sono verificate
nel database ha raggiunto dieci volte il carico normale.
Quindi, poiché è presente un unico database e il carico è elevato,
molte richieste falliscono regolarmente.
Un altro requisito importante è che le nuove promozioni in corso, che comportano
un carico 20 volte superiore al normale, siano programmate a mesi alterni.
Non si tratta quindi di attività continuative 24 ore su 24 per tutto il mese.
Si svolge a mesi alterni.
Ora, sulla base di questo caso d'uso specifico, analizziamo la soluzione che è possibile implementare.
Ora, una delle soluzioni più semplici che si potrebbero ipotizzare è quella
di aumentare direttamente le dimensioni del database e anche il numero di IOPS di provisioning, in modo da
poter gestire il carico 20 volte superiore che è attualmente in corso a causa della promozione
delle vendite.
La prima limitazione è che ci sarà un tempo di inattività, quindi se volete scalare verticalmente questo database,
dovrete chiudere il ridimensionamento e poi riavviare il database.
Si tratta quindi di una sfida specifica.
La seconda sfida è l'aumento dei costi.
Per esempio, supponiamo di aver scalato il database prima Il database aveva due GB di RAM,
ora il database ha 16 GB di RAM e le cose funzionano perfettamente.
Ma cosa succede dopo che la promozione della vendita è stata completata?
Il vostro database da 16 GB sarà sempre in funzione e questo aumenterà notevolmente i costi.
Va bene.
Si tratta quindi di una delle architetture a cui le organizzazioni generalmente evitano di rivolgersi soprattutto a causa
di queste sfide.
Per ovviare a questo problema, esiste un approccio migliore che prevede l'uso di una coda di messaggi.
In questo tipo di architettura, invece di inserire direttamente i messaggi nel database,
essi vengono inseriti come parte della coda ASCS e della CE.
Due istanze preleveranno il messaggio dalla coda e lo inseriranno nel database a seconda del
carico.
Supponiamo che il database sia già sottoposto a un carico molto elevato.
Quindi i messaggi possono rimanere nella coda US per un minuto o due, ad esempio, e quando il carico del
database aumenta il set di EC, due istanze possono estrarre il messaggio e reinserire i dati nel database.
Questo tipo di architettura è presente in molte organizzazioni.
Ora, una cosa da notare è che in questo tipo di architettura, ci sarà un piccolo
ritardo tra il messaggio inviato dal client e il messaggio inserito nel database.
Quindi ci sarà un piccolo ritardo.
Ma per la maggior parte dei casi d'uso questa volta il ritardo non ha molta importanza.
Se avete cambiato il nome del vostro profilo in un forum specifico e se il nome del profilo viene aggiornato,
diciamo dopo 2 o 3 minuti, non ha molta importanza e così via.
Quindi in molti casi d'uso non ha importanza.
Ma per i casi d'uso in cui il ritardo non è accettabile, questo tipo di architettura è da
evitare.
Quindi, ancora una volta, negli esami, a seconda del caso d'uso indicato, si può procedere a selezionare la risposta appropriata.
Con questo si conclude il video di oggi.