Come viene raggiunta la viscosità della sessione su più server Web?

Quanti server Web ha StackOverflow / ServerFault?

Se la risposta è "più di una", ottiene la viscosità della sessione durante il polling DNS?

I siti Web di grandi dimensioni possono essere "bilanciati in base al carico" su più macchine. In molte configurazioni con bilanciamento del carico, un utente può colpire qualsiasi macchina back-end durante una sessione. Per questo motivo, esistono numerosi metodi per consentire a molte macchine di condividere sessioni utente.

Il metodo scelto dipenderà dallo stile di bilanciamento del carico impiegato, nonché dalla disponibilità / capacità dello storage back-end:

Informazioni sulla sessione memorizzate solo nei cookie : le informazioni sulla sessione (non solo un identificatore di sessione) sono memorizzate nel cookie di un utente. Ad esempio, il cookie dell'utente potrebbe contenere il contenuto del proprio carrello. Per impedire agli utenti di manomettere i dati della sessione, è possibile che venga fornito un HMAC insieme al cookie. Questo metodo è probabilmente il meno adatto per la maggior parte delle applicazioni:

• Non è necessario alcun archivio back-end
• L'utente non deve colpire la stessa macchina ogni volta, quindi è possibile utilizzare il bilanciamento del carico DNS
• Non esiste alcuna latenza associata al recupero delle informazioni sulla sessione da un computer di database (poiché viene fornito con la richiesta HTTP). Utile se il tuo sito è bilanciato dal carico di macchine in diversi continenti.
• La quantità di dati che è possibile archiviare nella sessione è limitata (dal limite della dimensione dei cookie 4K)
• La crittografia deve essere utilizzata se un utente non dovrebbe essere in grado di vedere i contenuti della propria sessione
• HMAC (o simile) deve essere impiegato per prevenire la manomissione dei dati della sessione da parte dell'utente
• Poiché i dati della sessione non sono memorizzati sul lato server, è più difficile per gli sviluppatori eseguire il debug

Il servizio di bilanciamento del carico indirizza sempre l'utente sullo stesso computer : molti servizi di bilanciamento del carico possono impostare il proprio cookie di sessione, indicando da quale computer back-end un utente sta facendo richieste e indirizzandolo a quel computer in futuro. Poiché l'utente è sempre indirizzato alla stessa macchina, non è richiesta la condivisione della sessione tra più macchine. Questo può essere buono in alcune situazioni:

• Potrebbe non essere necessario modificare la gestione della sessione di un'applicazione esistente per diventare a conoscenza di più macchine
• Non è richiesto alcun sistema di database condiviso (o simile) per l'archiviazione delle sessioni, aumentando probabilmente l'affidabilità, ma a costo della complessità
• Una macchina back-end in discesa eliminerà tutte le sessioni utente avviate su di essa, con essa.
• Mettere fuori servizio le macchine è più difficile. Gli utenti con sessioni su una macchina da smontare per manutenzione dovrebbero essere autorizzati a completare le loro attività, prima che la macchina venga spenta. A supporto di ciò, i bilanciatori del carico Web possono avere una funzione per "svuotare" le richieste a un determinato computer back-end.

Database back-end condiviso o archivio chiave / valore : le informazioni sulla sessione sono archiviate in un database back-end, a cui tutti i server Web hanno accesso a query e aggiornamenti. Il browser dell'utente memorizza un cookie contenente un identificatore (come l'ID sessione), che punta alle informazioni sulla sessione. Questo è probabilmente il metodo più pulito dei tre:

• L'utente non deve mai essere esposto alle informazioni sulla sessione memorizzata.
• L'utente non deve colpire la stessa macchina ogni volta, quindi è possibile utilizzare il bilanciamento del carico DNS
• Uno svantaggio è il collo di bottiglia che può essere collocato su qualsiasi sistema di archiviazione back-end.
• Le informazioni sulla sessione potrebbero essere scadute e il backup sarà coerente.

Nel complesso, la maggior parte delle applicazioni Web dinamiche esegue una serie di query del database o richieste di archivio chiave / valore, quindi il database o l'archivio chiave / valore è la posizione di archiviazione logica dei dati della sessione.

Se la domanda è come mantenere le sessioni su più server Web front-end, la risposta è in genere utilizzare un database centralizzato. Invece di fare affidamento sulle istanze del server Web per tenere traccia dei file di sessione sui file system locali, scrivere gli ID di sessione e i dati in un DB centrale e tutti i server Web recupererebbero invece i dati da lì.

L'uso di nemcached sembra essere una buona soluzione non menzionata da @David Pashley

Significa avere un'istanza memcached remota condivisa da tutti i server e usare l'estensione PECL memcache che fornisce il proprio gestore di sessioni.

Richiede solo cambiare due parametri nella configurazione di php!

Ecco un buon tutorial http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/

IIRC, in DotNetRocks # 440 hanno detto un periodo del server. Non so se è ancora così.

Modifica: In realtà era Hanselminutes # 134 . Scusate.

Puoi impostare un cookie.

È possibile calcolare un hash dell'IP remoto (nei suoi host remoti con numero dispari più semplice passare al server A, host con numero pari andare al server B).

Sembra che tu possa farlo anche tramite alcuni valori che rimangono con il sistema sorgente se stai usando un tunnel SSL.

In genere, ciascuno dei meccanismi sopra descritti richiede un server "proxy inverso" o un bilanciamento del carico di qualche tipo. Il servizio di bilanciamento del carico accetta il traffico e lo indirizza a qualsiasi server inizialmente aveva la sessione, in base a uno dei criteri sopra indicati.

Non sono sicuro, tuttavia, che cosa intendi per "polling DNS"

a) È possibile memorizzare le informazioni sulla sessione nel cookie dell'utente. Vedi i cookie induriti senza stato, che non memorizzano dati sul lato server, ma conservano lo stato della sessione http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf . b) È possibile modificare l'archivio back-end della sessione in database o memcached. Per eliminare il singolo punto di errore, è possibile impostare la replica del database o più nodi memcached. Si noti che memcached è raccomandato in tali configurazioni in cui perdere lo stato dell'utente in sessione non è un grosso errore e non lo rende molto infelice. Per i casi in cui preservare lo stato è vitale, utilizzare i database. Sia PHP, Django che Rails consentono agli sviluppatori di scrivere backend di sessione personalizzati.