L'unico motivo per archiviare i dati di sessione in un database (MongoDB, Redis, ecc.) È tale che è disponibile nei processi Node ed è duratura tra i guasti. Nelle architetture di scalabilità, è altamente auspicabile disporre di server stateless in modo che tutto funzioni indipendentemente dal server a cui un particolare utente si connette ei server possono andare su e giù senza perdere nessuno stato.
In altre parole, immagina di avere 10 server dietro un servizio di bilanciamento del carico che gestisce le richieste in arrivo. L'utente 1 effettua una richiesta che il server A gestisce e accede. È necessario memorizzare il fatto di aver effettuato l'accesso in modo da archiviarlo in una sessione. La richiesta successiva finisce per essere indirizzata al server C poiché il server A è occupato con un'altra richiesta. Affinché il Server C sappia che l'utente ha già effettuato l'accesso, ha bisogno dei dati della sessione. Quindi, come ottiene l'accesso ai dati della sessione archiviati dal server A?
Un modo è memorizzare i dati in un cookie sul lato client che viene inviato con ogni richiesta, ma questo non è molto sicuro. Un altro modo è provare e sincronizzare lo stato tra i server Node che può essere fatto, ma tende ad essere costoso e soggetto a errori. Il modo più semplice è archiviare un ID di sessione in un cookie e quindi archiviare i dati di sessione effettivi in un database. Ogni server nodo ha quindi accesso allo stesso database in modo che possano cercare i dati della sessione. In questo modo puoi facilmente scalare dentro e fuori i tuoi server Node e bilanciare il carico quando i server falliscono senza perdere dati.
In termini di prestazioni, l'archivio in memoria sarà il più veloce (ma presenta gli svantaggi sopra). Redis sarà il prossimo più veloce e MongoDB sarà il più lento (generalmente circa 4 volte più lento di Redis). Tieni presente che entrambi saranno abbastanza veloci per la maggior parte dei siti web.