Sessioni appiccicose e NON appiccicose

255

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

Sticky : sarà presente solo un singolo oggetto sessione.

Sessione non appiccicosa : oggetto sessione per ciascun nodo del server

session

— Sunny Gupta
fonte

Risposte:

612

Quando il tuo sito Web è servito da un solo server Web, per ogni coppia client-server, viene creato un oggetto sessione che rimane nella memoria del server Web. Tutte le richieste dal client vanno a questo server Web e aggiornano questo oggetto sessione. Se alcuni dati devono essere archiviati nell'oggetto sessione durante il periodo di interazione, vengono archiviati nell'oggetto sessione e rimangono lì finché esiste la sessione.

Tuttavia, se il tuo sito Web è servito da più server Web che si trovano dietro un bilanciamento del carico, il bilanciamento del carico decide a quale server Web (fisico) effettivo dovrebbe andare ogni richiesta. Ad esempio, se ci sono 3 server Web A, B e C dietro il bilanciamento del carico, è possibile che www.mywebsite.com/index.jsp sia servito dal server A, www.mywebsite.com/login.jsp è servito da il server B e www.mywebsite.com/accoutdetails.php sono serviti dal server C.

Ora, se le richieste vengono servite (fisicamente) da 3 server diversi, ogni server ha creato un oggetto sessione per te e poiché questi oggetti sessione si trovano su tre caselle indipendenti, non c'è modo diretto di sapere cosa c'è nell'oggetto 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 dati da / a 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 permanenti, tutte le interazioni avverranno con lo stesso server fisico, anche se sono presenti altri server. Pertanto, l'oggetto della sessione sarà lo stesso durante l'intera interazione con questo sito Web.

Riassumendo, nel caso di sessioni permanenti, tutte le vostre richieste saranno indirizzate allo stesso server Web fisico mentre in caso di un bilanciamento del carico non appiccicoso potrebbe scegliere qualsiasi server web per soddisfare le vostre richieste.

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

— TJ-
fonte

@ TJ- cosa accadrà se un nodo non sarà disponibile?

— gstackoverflow

Nella maggior parte dei casi, la sessione andrà persa. Nel caso di AWS ESB Se un'istanza non riesce o diventa non integra, il bilanciamento del carico interrompe il routing della richiesta a tale istanza, invece sceglie una nuova istanza integra in base all'algoritmo di bilanciamento del carico esistente. Il bilanciamento del carico considera la sessione come "bloccata" nella nuova istanza integra e continua a instradare le richieste a tale istanza anche se l'istanza non riuscita ritorna.

— TJ-

Secondo quali informazioni LoadBalancer rende appiccicosa una sessione HTTP? Soprattutto sulle connessioni HTTPS questo problema diventa interessante. Alimentate l'LB con la chiave privata dei server Web, in modo che sia in grado di interrompere la connessione SSL e recuperare la sessione HTTP? Oppure LB utilizza semplicemente l'indirizzo IP del client? In questo caso, che dire del server proxy in cui più client utilizzano lo stesso indirizzo IP? O peggio ancora, i client mobili, dove l'indirizzo IP cambia frequentemente? O c'è anche una tecnica migliore per questo? Grazie

— g000ze,

Sì, hai assolutamente ragione. Per utilizzare l'intestazione "x-forwarded-for" o un cookie appiccicoso in questo contesto, è necessario utilizzare la terminazione SSL e quindi la richiesta deve essere decrittografata presso l'LB.

— TJ-

@ g000ze Quando si tratta di applicazioni che non sono servite direttamente su Internet, credo che sia comune abilitare TLS solo sul server proxy più esterno. (Un bilanciamento del carico può essere considerato, forse in modo semplicistico, come un tipo speciale di server proxy, che può passare la richiesta a uno o più server.) Il traffico tra il bilanciamento del carico e gli altri server avverrà su una rete locale protetta e pertanto spesso non è necessario crittografarlo o, se è necessario crittografarlo, può essere sufficiente un certificato autofirmato (poiché il proxy può essere configurato per essere attendibile).

— jpmc26,

106

Ho fatto una risposta con qualche dettaglio in più qui: https://stackoverflow.com/a/11045462/592477

Oppure puoi leggerlo lì ==>

Quando usi il bilanciamento del carico 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 l'app Web e di avere 3 istanze tomcat. Questo utente invia diverse richieste alla tua app, quindi il bilanciamento del carico invierà alcune di queste richieste alla prima istanza di Tomcat e invierà alcune di queste richieste alla seconda istanza e altre alla terza.
Se si utilizza la sessione adesiva senza replica:Immagina di avere un solo utente che utilizza la tua app Web e di avere 3 istanze Tomcat. Questo utente invia diverse richieste alla tua app, quindi il bilanciamento del carico 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 tomcat (istanza tomcat utilizzata), il bilanciamento del carico invia le richieste rimanenti a un'altra istanza tomcat ancora in esecuzione, MA poiché non si utilizza la replica di sessione, l'istanza 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 sebbene l'app Web sia ancora in esecuzione.
Se si utilizza la sessione adesiva 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 bilanciamento del carico 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 tomcat (istanza tomcat utilizzata), il loadbalancer invia le richieste rimanenti a un'altra istanza tomcat ancora in esecuzione, mentre si utilizza la replica di sessione, l'istanza tomcat che riceve le richieste rimanenti ha una copia della sessione utente, quindi l'utente continua la sua sessione: l'utente continua a navigare nell'app Web senza essere disconnesso, l'arresto dell'istanza tomcat non influisce sulla navigazione dell'utente.

— nico
fonte

Hmm .. leggendo questo mi chiedo: non avrebbe senso avere una quarta opzione: Non appiccicoso CON la replica della sessione? O in altre parole: qual è il vantaggio di avere una sessione appiccicosa se si replica comunque la sessione nelle diverse istanze? Voglio dire, se stai replicando le sessioni tra le istanze, potresti inoltrare la richiesta anche a qualsiasi server, giusto? Cosa mi sto perdendo?

— dingalapadum,

@dingalapadum hai ragione, teoricamente puoi avere la replica di sessione senza sticky-session. Ma nel caso di un cluster di grandi dimensioni è un male per le prestazioni di rete. Quindi ci sono alcune strategie nell'uso della replica della sessione con una sessione appiccicosa come questa in tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) è mettere una sessione appiccicosa e una sola replica (un nodo qui chiamato gestore backup che mantiene tutta la replica della sessione nodo).

— Nico,

Quindi la sessione appiccicosa ti consente di avere una sola replica di sessione, che è la cosa migliore nel cluster di grandi dimensioni.

— Nico,

Ah vedo - Se capisco correttamente, intendi che replicare tutte le sessioni nell'intero cluster inonderebbe internamente il cluster - Vedo il problema. Oh, e ora osservando più da vicino la tua risposta, ho appena visto che questo è in realtà il primo caso che descrivi ... 'duh me' ..

— dingalapadum

@dingalapadum la tua domanda è benvenuta consente di migliorare la risposta

— Nico