Yocker
  1. Yocker
  3. Sessioni appiccicose e NON appiccicose
Intereting Posts
Come posso arrotondare il tempo ai minuti X più vicini? Log4net che scorre nome file giornaliero con data nel nome del file operatori come stringhe Come ottenere una colonna datetime in SQLite con Objective C XPath per selezionare più tag Perché strsplit usa un lookahead positivo e guarda le corrispondenze di asserzione in modo diverso? Come leggere request.getInputStream () più volte convertire la matrice di byte in bitmapimage Il modo migliore per creare opzioni di configurazione personalizzate per la mia app Rails? Qual è la differenza tra E in Java Generics? Come usare NSDecimalNumber? C ++: passaggio di argomenti “passati per riferimento” Abbina spazi bianchi ma non newlines Distinguere tra thread Java e thread del sistema operativo? C #: un modo elegante per partizionare una lista?

Sessioni appiccicose e NON appiccicose

Voglio sapere la differenza tra le sessioni appiccicose e non appiccicose. Cosa ho capito dopo aver letto da internet:

Appiccicoso : sarà presente solo l’object a sessione singola.

Sessione non appiccicosa : object di sessione per ogni nodo del server

Quando il sito Web viene servito da un solo server Web, per ogni coppia client-server, viene creato un object sessione che rimane nella memoria del server Web. Tutte le richieste dal client si rivolgono a questo server Web e aggiornano questo object di sessione. Se alcuni dati devono essere memorizzati nell’object di sessione nel periodo di interazione, vengono memorizzati in questo object di sessione e rimangono lì finché esiste la sessione.

Tuttavia, se il sito Web è gestito da più server Web che si trovano dietro un sistema di bilanciamento del carico, il servizio di bilanciamento del carico decide a quale server web (fisico) effettivo deve essere assegnato ogni richiesta. Ad esempio, se ci sono 3 server Web A, B e C dietro il servizio di bilanciamento del carico, è ansible che http://www.mywebsite.com/index.jsp sia servito dal server A, http://www.mywebsite.com/login.jsp è servito da il server B e http://www.mywebsite.com/accoutdetails.php sono serviti dal server C.

Ora, se le richieste vengono servite da (fisicamente) 3 server diversi, ogni server ha creato per te un object di sessione e poiché questi oggetti di sessione siedono su tre caselle indipendenti, non c’è modo diretto di sapere cosa c’è nell’object di sessione dell’altro. Per sincronizzare tra queste sessioni del server, potrebbe essere necessario scrivere / leggere i dati della sessione in un livello comune a tutti, come un DB. Ora scrivere e leggere i dati da / verso un db per questo caso d’uso potrebbe non essere una buona idea. Ora, ecco il ruolo di sticky-session .

Se al bilanciamento del carico viene richiesto di utilizzare sessioni persistenti, tutte le interazioni avverranno con lo stesso server fisico, anche se sono presenti altri server. Pertanto, l’object della tua sessione sarà lo stesso per tutta la tua interazione con questo sito.

Per riassumere, In caso di Sticky Session, tutte le richieste saranno indirizzate allo stesso server web fisico mentre nel caso di un loadbalancer non appiccicoso può scegliere qualsiasi server web per soddisfare le tue richieste.

Ad esempio, puoi leggere su Elastic Load Balancer di Amazon e sessioni appiccicose qui: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

Ho fatto una risposta con ulteriori dettagli qui: https://stackoverflow.com/a/11045462/592477

Oppure puoi leggerlo lì ==>

Quando usi loadbalancing significa che hai diverse istanze di tomcat e devi dividere i carichi.

  • Se stai utilizzando la replica di sessione senza sessione appiccicosa: immagina di avere un solo utente che utilizza la tua app Web e di avere 3 istanze di Tomcat. Questo utente invia diverse richieste alla tua app, quindi loadbalancer invierà alcune di queste richieste alla prima istanza di tomcat e invierà alcune di queste richieste alla seconda istanza e altre alla terza.
  • Se stai utilizzando una sessione persistente senza replica: immagina di avere un solo utente che utilizza la tua app Web e di avere 3 istanze di Tomcat. Questo utente invia diverse richieste alla tua app, quindi il loadbalancer invierà la prima richiesta dell’utente a una delle tre istanze di tomcat e tutte le altre richieste inviate da questo utente durante la sua sessione verranno inviate alla stessa istanza di tomcat. Durante queste richieste, se si arresta o si riavvia questa istanza di tomcat (istanza di tomcat che viene utilizzata), il loadbalancer invia le richieste rimanenti a un’altra istanza di tomcat ancora in esecuzione, MA poiché non si utilizza la replica di sessione, l’instance tomcat che riceve le richieste rimanenti non hanno una copia della sessione utente quindi per questo tomcat l’utente inizia una sessione: l’utente perde la sessione e viene disconnesso dall’app Web anche se l’app Web è ancora in esecuzione.
  • Se stai utilizzando la sessione persistente CON la replica della sessione: immagina di avere un solo utente che utilizza la tua app Web e di avere 3 istanze di Tomcat. Questo utente invia diverse richieste alla tua app, quindi il loadbalancer invierà la prima richiesta dell’utente a una delle tre istanze di tomcat e tutte le altre richieste inviate da questo utente durante la sua sessione verranno inviate alla stessa istanza di tomcat. Durante queste richieste, se si arresta o si riavvia questa istanza di tomcat (istanza di tomcat utilizzata), il loadbalancer invia le richieste rimanenti a un’altra istanza di tomcat ancora in esecuzione, mentre si utilizza la replica di sessione, il tomcat di istanza che riceve le richieste rimanenti ha una copia della sessione utente quindi l’utente continua nella sua sessione: l’utente continua a navigare nell’app Web senza essere disconnesso, l’arresto dell’istanza di tomcat non ha alcun impatto sulla navigazione dell’utente.