Mantenimento dello stato nel server delle applicazioni o nel database?

Question

REST sostiene le applicazioni Web senza stato client sul server. Il famoso esempio del carrello è tradotto in una risorsa che normalmente risiede in un database.

Mi chiedo se sia una buona pratica utilizzare un database per quel tipo di dati, poiché il database è già il collo di bottiglia in molte applicazioni. Non sarebbe meglio usare invece un java bean enterprise stateful? I server delle applicazioni sono progettati pensando a clusting.

Quali sono i vantaggi e gli svantaggi dei due approcci?

Answer 1

Memorizzazione sessioni sul server applicativo funziona solo se:

• I vostri clienti si connettono sempre allo stesso server di applicazione (alias "affinità di sessione")
• Il cluster applicazione nodi usano tutti un comune punto di montaggio (nfs, ecc.) per lo spooling delle sessioni

L'archiviazione delle sessioni in un database centrale e/o EJB funzionerà se ai client non viene garantita la connessione sempre allo stesso nodo dell'applicazione nel cluster.

Un altro approccio da considerare è l'utilizzo di un servizio come memcached. Questo funzionerà in entrambi i casi.

Answer 2

In generale:

Database

• più affidabile e sopravviverà un riavvio app/server
• possono essere condivisi tra i server con bilanciamento del carico, senza avere a che fare con le sessioni "appiccicosi"
• accesso più lento

In memoria (bean di stato non distribuito)

• veloce memorizzazione e il recupero
• Meno codice
• andranno persi se l'applicazione/server si riavvia

vostra scelta sarà totalmente dipendenti dalle vostre esigenze applicative e l'ambiente. A parità di condizioni, preferisco la soluzione di database a causa del bilanciamento del carico e dei vantaggi di affidabilità, ma questo può facilmente essere eccessivo in molti scenari.

Answer 3

Cosa succede quando il server dell'app muore. Lo stato della sessione è ancora importante? Vai per un database.

Avete più stato di sessione, quindi il server può gestire per tutti gli utenti concorrenti? Spostare i dati in un database e tirare fuori solo ciò di cui hai realmente bisogno al momento, potrebbe essere una soluzione.

La tua app è in cluster? In tal caso, il database centrale si assicura che i dati di sessione siano sempre disponibili.

Altrimenti: basta archiviarlo nella sessione.

Avete requisiti di ridimensionamento estremi (come stackoverflow o siti con un traffico ancora maggiore)? Trova un modo per non utilizzare il database.

È vero, che il database è spesso il collo di bottiglia. Ma un database correttamente configurato dovrebbe gestire solo un paio di byte di dati di sessione. Dati e query più complessi sono le prestazioni a costi inferiori.

Answer 4

Tutti gli altri articoli sono buoni suggerimenti. Un altro è questo: non utilizzare lo stato della sessione se non ne hai assolutamente bisogno.

Memorizzazione di sessione in un database è (generalmente) una cattiva idea per un paio di motivi semplici:

1. utilizzo tipico della sessione è quello di evitare di dover caricare i dati comuni alle diverse volte del server di database. Se la sessione è memorizzata nel server db, beh, in realtà non hai fatto molto.

2. La sessione deve essere serializzata e deserializzata per ogni singola pagina di esecuzione. Ciò significa che i dati di sessione dovrebbero essere recuperati dal server e scritti sul server ogni singola pagina caricata indipendentemente dal fatto che lo si usi o meno.

Nella mia esperienza è molto meglio servita per tirare semplicemente i dati dal server di database quando realmente bisogno. Nella maggior parte dei casi, le persone mettono in sessione tutti i tipi di dati di breve durata semplicemente perché pensano di risolvere un problema di prestazioni, quando in realtà peggiorano la situazione.

Inoltre, se si limita la quantità di dati verso il basso (ad esempio, un id utente, un nome o qualcosa del genere), è possibile archiviarlo in un client di cookie crittografato e non doversi preoccupare affatto.

MemCache è un'opzione; ma di nuovo guarderei seriamente all'utilizzo del database e vedere se è possibile ottimizzare le query e gli schemi prima di tutto.