Quando il vostro sito è servito da solo 1 web server
, per ogni coppia, un oggetto sessione viene creato e rimane nella memoria del server web. Tutte le richieste dal client si rivolgono a questo server Web e aggiornano questo oggetto di sessione. Se alcuni dati devono essere memorizzati nell'oggetto di sessione nel periodo di interazione, vengono memorizzati in questo oggetto di sessione e rimangono lì finché esiste la sessione.
Tuttavia, se il sito Web è servito da multiple web servers
che si trova dietro a load balancer
, 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, è possibile che www.mywebsite.com/index.jsp sia servito dal server A, www.mywebsite.com/login.jsp è servito dal server B e 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 un oggetto sessione per te e perché queste sessioni gli oggetti si trovano su 3 caselle indipendenti, non c'è modo diretto di sapere cosa c'è nell'oggetto 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 allo load balancer
viene richiesto di utilizzare sessioni persistenti, tutte le interazioni avverranno con the same physical server
, anche se sono presenti altri server. Pertanto, l'oggetto della tua sessione sarà lo stesso per tutta la tua interazione con questo sito.
Per riassumere, In caso di sessioni adesive, tutte le richieste verranno indirizzate allo stesso server Web fisico mentre nel caso di un loadbalancer non appiccicoso può scegliere qualsiasi server web per soddisfare le vostre richieste.
A titolo di esempio, si può leggere su Balancer di Amazon Elastic Load e le sessioni di appiccicoso qui: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html
fonte
2012-11-30 08:57:25
@ TJ- cosa succederà se un nodo non sarà disponibile? – gstackoverflow
Nella maggior parte dei casi, la sessione andrà persa. In caso di [AWS ESB] (http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html) _Se un'istanza fallisce o diventa non sana, il servizio di bilanciamento del carico interrompe la richiesta di routing a tale esempio, sceglie invece una nuova istanza sana basata sull'algoritmo di bilanciamento del carico esistente. Il servizio di bilanciamento del carico tratta la sessione come ora "bloccata" nella nuova istanza sana e continua a instradare le richieste a tale istanza anche se l'istanza fallita ritorna._ –
In base a quali informazioni il LoadBalancer rende appiccicosa una sessione HTTP? Soprattutto sulle connessioni HTTPS questo problema diventa interessante. Feed 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? O il LB usa semplicemente l'indirizzo IP del client? In questo caso, che dire del server proxy in cui più client utilizzano lo stesso indirizzo IP? O ancora peggio, i client mobili, dove l'indirizzo IP cambia di frequente? O esiste anche una tecnica migliore per questo? Grazie – g000ze