Sto lavorando su un social network usando Vue.js su frontend e Node / Express su backend. Per memorizzare sessioni utente sto usando Redis. Mi chiedo se dovrei colpire Redis ogni volta che un utente richiede il contenuto, o forse c'è un modo per ridurre il carico?
Dovresti utilizzare gestione della sessione per gestire il trasferimento di informazioni tra client e server.
La gestione delle sessioni implica essenzialmente l'autenticazione di un utente per eseguire inizialmente un'azione privilegiata, con tutte le attività successive autenticate tramite informazioni "condivise", ad esempio: cookie.
Chiedere agli utenti di autenticarsi per ogni singola azione può essere considerato più sicuro, ma ridurrà pesantemente l'usabilità della piattaforma e la soddisfazione generale dell'utente come risultato.
Per quanto riguarda il carico del database, senza vedere l'applicazione specifica non posso essere al 100% tuttavia ti consiglio se si sta registrando l'ultima volta che è stata usata la sessione, non è necessario scrivere molte altre informazioni il database.
Identità basata sui reclami è un buon modo per ridurre il carico dell'autenticazione di un utente.
Il modo più semplice per implementare quello è avere un primo portale di autenticazione che genera token firmati contenenti le richieste necessarie per l'utente e quindi avere la chiamata successiva che richiede quel token, verificare la firma e fidarsi delle affermazioni.
Vedi JWT per un'implementazione pratica.
Questo è davvero un po 'fuori tema qui. Non sappiamo quale sia la tua domanda / i / assomiglia - quindi non possiamo rispondere alla domanda che hai fatto oltre a dire che la rilevanza funzionale di solito sovrascrive la considerazione della prestazione. Tuttavia dal momento che altri hanno già iniziato a rispondere ....
Tradizionalmente, le sessioni http utilizzano un identificatore casuale inviato al client che è una chiave per i dati sul server. Ogni volta che una richiesta richiede dati di sessione, questa viene letta dalla memoria. E nella maggior parte delle implementazioni viene successivamente riscritto nello spazio di archiviazione o prima del completamento della richiesta. Quest'ultimo è importante per aggiornare il timestamp della sessione in modo che possa essere raccolto in seguito. Ora è assolutamente necessario riportare i dati in memoria quando sono stati modificati, ma le scritture sono almeno 3 volte più costose delle letture. Pertanto, anche se è possibile implementarlo senza influire sulla consegna del contenuto al client, non scrivere i dati di sessione invariati nello spazio di archiviazione con ogni richiesta può avere un grande impatto sulla capacità.
Anche l'utilizzo di un supporto di archiviazione più veloce può aiutare.
Poi c'è la possibilità di memorizzare nella cache il contenuto. Alcuni contenuti devono essere generati di nuovo ogni volta che si accede. Alcuni contenuti saranno quasi statici per un determinato utente e alcuni contenuti saranno uguali per tutti gli utenti. HTTP fornisce meccanismi per pubblicizzare questo fatto sul client e su un proxy inverso . Ad esempio, per il contenuto memorizzabile in cache da un utente specifico, è possibile incorporare l'id utente in Etag, ma ricordarsi di aggiungere un controllo cache: intestazione privata nel punto in cui lascia il proxy inverso.
Sebbene in genere non ci si possa fidare del contenuto inviato dal client, è possibile crittografare i dati nei cookie e utilizzare il client per l'archiviazione e controllare la manomissione durante la decrittografia. Di nuovo, si tratta di capacità piuttosto che di prestazioni. E alcuni pensieri devono essere applicati alla persistenza dei dati sul client, anche se è crittografato.
Ma, tranne che in pochissimi casi, il sovraccarico prestazionale delle sessioni, relativo a tutto il resto in corso in una pagina Web, è molto, MOLTO piccolo.
Sembra che tu stia eseguendo l'autenticazione o almeno una parte di essa.
I'm wondering if I should hit Redis everytime user requests content,
Sì, devi controllare la sessione utente sullo storage back-end su ogni richiesta http , in questo modo i server web e i framework web gestiscono le sessioni utente, alcune di esse usa il filesystem per memorizzare sessioni come Apache e altri usano DB relazionali come Django Framework per default.
L'archiviazione in memoria come Redis e Memcached è di fatto la scelta giusta per questo caso.
Tuttavia, è ancora possibile aumentare le prestazioni riducendo il numero di roundtrip tra il client e il server. Ciò può essere ottenuto aggregando i dati a un numero minore di richieste che diminuirà nella frequenza di hit su Redis.
No, non è necessario premere Redis su ogni richiesta è la risposta, in quanto è possibile gestire le sessioni dal back-end mediante l'emissione di un cookie sicuro. Immagina cosa succederebbe se Facebook o Twitter colpissero il loro db su ogni richiesta fatta dall'utente? Inoltre, rallenterebbe la richiesta degli utenti.
Leggi altre domande sui tag account-security databases