Condividi sessioni tra istanze di tomcat (senza utilizzare sessioni di Sticky Session)

Question

Avrò 3 server Tomcat e un Load Balancer che invia le richieste senza utilizzare 'sticky sessions'.

Voglio condividere i dati delle sessioni tra i server e sto pensando di mantenerli in DB. Mi piacerebbe usare memcached come strato di fronte al mio DB per servire le richieste più velocemente e a don't put my db under heavy load.

Sto pensando di fornire il mio gestore Tomcat personalizzato che utilizza memcached prima di ottenere/persistere i dati della sessione in DB poiché al momento non vedo un modo trasparente di farlo (significa che dovrò gestirlo ancora nel caso io passi ad un altro app server).

Questa è una buona soluzione o vedi un approccio migliore?

Answer 1

Facciamo una cosa simile nella nostra applicazione (Weblogic, ma non importa), dove abbiamo una chiave di sessione unica memorizzata come cookie nel browser. Tale chiave verrà quindi utilizzata per ogni richiesta per ripristinare i dati della sessione pertinenti dal database.

Utilizzando questo principio, possiamo sempre passare a un altro server utilizzando il servizio di bilanciamento del carico senza che l'utente se ne accorga. In aggiunta a ciò, non memorizziamo nulla di rilevante nella sessione dell'utente e lavoriamo con molti campi nascosti nel browser (il bilanciamento del carico supporta la crittografia degli URL e la protezione del valore forma, quindi siamo dalla parte della sicurezza ...) .

Answer 2

Penso che Terracotta Web Sessions sia quello che vuoi.

Answer 3

Memorizzare lo stato della sessione al di fuori dei server delle app (Tomcat nel tuo caso), è una configurazione molto comune e consigliata per i siti Web su larga scala. Questo di solito è fatto nel perseguimento di uno stile di architettura chiamato Shared Nothing.

È possibile memorizzare il proprio stato in diversi luoghi: db, memcached, cache replicata commerciale, ecc. Funzionano tutti con diverse combinazioni di trade off. Personalmente, ho avuto un grande successo con memcached. Memcached è estremamente veloce e stabile.

In genere, scelgo la semplicità e utilizzo i server N memcache in cui N> 1, diciamo 2. Quando gli utenti eseguono l'accesso, i server di app lanciano una moneta per decidere quale server memorizza lo stato degli utenti. Il cookie inviato al browser include informazioni per sapere quale server memcache instradare da quel momento in poi. Richieste successive dallo stato di recupero del browser dal server memcache appropriato in ogni richiesta. Se un server memcache fallisce, l'utente dovrà effettuare nuovamente il login quando i server app riselezioneranno un nuovo server, ma ciò è estremamente raro.

Answer 4

Le sessioni persistenti nel database limitano la scalabilità. Se la scalabilità non è così importante per te (db + memcached) è un approccio valido.

Una cosa da tenere a mente quando si usano le sessioni non -sticky sono richieste simultanee: quando si ha ad es. ajax-richieste (eseguite in parallelo/simultaneamente) saranno servite da diversi tomc (a causa di non appiccicosità) e quindi accedere contemporaneamente alla sessione. Finché hai richieste concorrenti che potrebbero modificare la sessione, devi implementare un qualche tipo di sincronizzazione/blocco della sessione.

Forse questo è interessante per te: ho creato lo memcached-session-manager con l'obiettivo sia di prestazioni ottimali sia di scalabilità illimitata. Può funzionare con qualsiasi back-end compatibile con memcached (ad esempio anche memcachedb, membase ecc. O semplicemente memcached). Sebbene sia stato originariamente creato per un approccio appiccicoso, esiste già uno branch for nonsticky-sessions esistente e un sample app che mostra come/che funziona. In questo momento c'è un thread on the mailing list on further improvements for nonsticky-sessions (gestione di richieste concorrenti e prevenzione di single-point-of-failure).