Gestione di sessioni senza database ACID?

Question

Sto pensando di utilizzare un noSQL (mongoDB) associato a memcached per archiviare le sessioni con nella mia webapp. L'idea è che al caricamento di ogni pagina, i dati dell'utente vengano confrontati con i dati nella memcache e se qualcosa è cambiato, i dati verrebbero scritti sia su memcached che su mySQL. In questo modo le letture sarebbero notevolmente ridotte e memcached utilizzato per fare ciò che sa fare meglio.

Tuttavia, sono un po 'preoccupato dell'utilizzo di un database non ACID per l'archiviazione di sessione, in particolare con il livello memcached. Diciamo che qualcosa va storto durante l'aggiornamento della sessione al DB ei nostri utenti hanno subito mal di testa chiedendosi perché il loro prodotto che hanno inserito nel carrello non viene visualizzato ...

Qual è un approccio appropriato a questo? Dovremmo optare per uno storage di sessione mySQL o è opportuno mantenere un database di supporto non acido per le sessioni?

Grazie!

Answer 1

Se non si desidera perdere i dati, attenersi ai database ACID testati.

Qual è il profitto che stai cercando?

Se si desidera un sistema sicuro, non è possibile fidarsi di nulla da parte dell'utente, ad eccezione degli interi selezionati, pertanto lasciare che vengano memorizzate le informazioni è in genere una pessima idea.

Non vedo il pagamento per l'archiviazione di sessioni al di fuori del database MySQL. Puoi cron cleanup sui tavoli se questa è la tua preoccupazione, ma perché preoccuparsi? Alcuni utenti effettueranno acquisti su un sito e quindi si distraggono per un po '. Tornerebbero un giorno o due dopo.

Se si utilizzano i cookie o qualcosa di temporaneo per archiviare le proprie informazioni sulla sessione, c'è davvero una buona possibilità che il loro tempo di acquisto sia stato sprecato. Gli utenti apprezzano davvero il loro tempo ... quindi se hai memorizzato le loro informazioni sulla sessione nel database, puoi scrivere qualcosa di sexy per gestire quei dati.

Inoltre, il piacevole effetto collaterale di questo è che genererai molte informazioni residue su ciò che le persone sul tuo sito web potrebbero non essere disponibili in futuro. Come si potrebbe anche considerare che alcune di esse siano come un sondaggio o qualcosa in cui gli articoli che le persone aggiungono al proprio carrello potrebbero avere un impatto su come gestisci la tua attività, ordinare l'inventario o focalizzare il tuo marketing.

Se vai con qualcosa di temporaneo, perdi i benefici residui.

Answer 2

Senza alcun blocco sulla sessione, essere veramente, molto attento a ciò che si sta memorizzando. Non archiviare mai nulla che dipenda da ciò che hai letto prima, dato che i dati potrebbero cambiare tra la lettura e la scrittura, specialmente nel caso di ajax in cui più richieste possono uscire contemporaneamente.

Un esempio di ciò che non è necessario memorizzare in una sessione non bloccata sarebbe un carrello della spesa come, per aggiungere un prodotto, è necessario leggere, unserialize, aggiungere il prodotto e quindi serializzare nuovamente. Se qualsiasi altra richiesta fa la stessa cosa tra le prime richieste di lettura e scrittura, si perdono i dati della seconda richiesta.

Date un'occhiata a questo articolo per i dettagli: http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/

Mantenere sessioni sul vostro filesystem (dove PHP li blocca per voi), nel vostro database (in cui devi fare bloccaggio manuale) o mai, mai, scrivere qualsiasi cosa di valore per la tua sessione se quel valore è derivato da una lettura precedente.

Answer 3

Mentre si utilizza memcached come cache per il database, è l'utente che deve garantire la coerenza dei dati tra il database e la cache. Se vuoi aumentare la scala e aggiungere altri server, è probabile che non sia sincronizzato con il database, anche se tutto sembra ok.

Invece si può considerare Hazelcast. A partire dal 1.9 supporta anche il protocollo memcache. Rispetto alla memcached Hazelcast vuole implementare la mappa Persister e solo essa aggiorna il database per le voci aggiornate. In questo modo non è necessario gestire il tipo di cache di "verifica cache, se i dati sono stati modificati".

Answer 4

Attualmente sto usando MongoDB come memoria di sessione. È possibile evitare le condizioni di gara menzionate da pilif. Ho trovato una classe che implementa un gestore di sessione per MongoDB (http://www.jqueryin.com/projects/mongo-session/) e l'ho biforcata su github per soddisfare le mie esigenze (http://github.com/halfdan/MongoSession).

Answer 5

Se si scrive l'app in modo che l'utente memorizzi tutte le informazioni di sessione sul lato client, quindi è sufficiente verificare tali informazioni in base alle esigenze, non sarà necessario preoccuparsi delle sessioni sul lato server. Questo è uno dei principi dell'architettura in stile REST. Ad esempio, se l'utente sta richiedendo di aggiungere un articolo al proprio carrello, è sufficiente memorizzare l'elenco ID articolo e contare sul lato client. Quando si colpisce la pagina del carrello, è possibile cercare facilmente le informazioni sull'elemento dall'elenco di itemID che stanno dicendo che sono nel carrello.

Durante il checkout, andare direttamente contro il database con le transazioni per assicurarsi che non si ottengano condizioni di gara e controllare il proprio inventario. Se l'inventario non è presente quando vanno al check-out, basta dire "mi dispiace, siamo appena esauriti".Naturalmente, a quel punto dovresti aggiornare tutti i cache che hai a disposizione che dicono alle persone che hai un inventario.

Answer 6

Vorrei vedere quanto costa l'utente per l'acquisto e poi chiedere quale è il costo per l'implementazione di un sistema veramente buono. Tieni presente che gli utenti sono un metodo di ripetizione biologica. "Sono annoiato ... premere di nuovo ricarica ..." Mentre, questa non è la soluzione più perfetta, a volte è accettabile rispetto al comparsion di costo per "non perdere nulla - mai".

Se si desidera ulteriore sicurezza, è possibile avere le sessioni memorizzate nella cache su un set separato di server memcache in modo che non si verifichino arresti accidentali. :)

Esistono numerosi altri sistemi membase.org e alcune altre soluzioni persistenti di memcache (implementazioni java) che permetteranno l'archiviazione su disco. Se si desidera modificare il client in qualche modo, o come si accede a memcache, è possibile eseguire la propria replica degli oggetti di sessione memcache.

-daniel