¿Manejo de sesiones sin base de datos ACID?

Question

Estoy pensando en usar un noSQL (mongoDB) emparejado con memcached para almacenar sesiones en mi webapp. La idea es que en cada carga de página, los datos del usuario se comparen con los datos en la memcache y, si algo ha cambiado, los datos se escribirían tanto en memcached como mySQL. De esta forma, las lecturas se reducirán en gran medida y se utilizarán las memcachas para hacer lo que mejor hace.

Sin embargo, estoy un poco preocupado por el uso de una base de datos no ACID para el almacenamiento de la sesión, especialmente con la capa de memcached. Digamos que algo va mal al actualizar la sesión al DB y nuestros usuarios se jadearon al instante preguntándose por qué el producto que colocaron en el carrito no aparece ...

¿Cuál es el enfoque apropiado para esto? ¿Deberíamos ir a un almacenamiento de sesión mySQL o está bien mantener una base de datos de soporte no ácida para las sesiones?

Gracias!

Answer 1

Si no quiere perder sus datos, siga las bases de datos probadas por ACID.

¿Cuál es la recompensa que estás buscando?

Si desea un sistema seguro, no puede confiar en nada del usuario, excepto tal vez los enteros seleccionados, por lo que dejarlos almacenar la información suele ser una muy mala idea.

No veo la recompensa por el almacenamiento de sesiones fuera de su base de datos MySQL. Puede cron limpiar en las tablas si esa es su preocupación, pero ¿para qué molestarse? Algunos usuarios comprarán en un sitio y luego se distraerán por un tiempo. Luego regresarían un día o dos más tarde.

Si usa cookies o algo realmente temporal para almacenar su información de sesión, existe una gran probabilidad de que se desperdicie su tiempo de compra. Los usuarios realmente valoran su tiempo ... así que si almacenó su información de sesión en la base de datos, puede escribir algo sexy para administrar esa información.

Además, el agradable efecto secundario de esto es que generará una gran cantidad de información residual sobre lo que a las personas les gusta en su sitio web que quizás no estén disponibles más adelante. Al igual que podría incluso considerar que algo de eso es como una encuesta o algo en el que los elementos que las personas agregan a su carrito podrían afectar la forma en que administra su empresa, ordena el inventario o enfoca su comercialización.

Si va con algo realmente temporal, entonces pierde beneficios residuales.

Answer 2

Sin ningún bloqueo en la sesión, tenga mucho cuidado con lo que está almacenando. Nunca almacene nada que dependa de lo que haya leído antes, ya que los datos pueden cambiar entre usted y su lectura, especialmente en el caso de ajax, donde múltiples solicitudes pueden salir a la vez.

Un ejemplo de lo que no debe almacenar en una sesión no bloqueada sería un carrito de compras ya que, para agregar un producto, debe leer, deserializar, agregar el producto y luego volver a serializarlo. Si cualquier otra solicitud hace lo mismo entre las primeras solicitudes de lectura y escritura, perderá los datos de la segunda solicitud.

Tener un vistazo a este artículo para más detalles: http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/

mantener las sesiones en su sistema de archivos (donde PHP los encierra para usted), en su base de datos (en la que tiene que hacer el bloqueo manual) o nunca, nunca, escribir cualquier cosa de valor para su sesión si ese valor se deriva de una lectura previa.

Answer 3

Al usar memcached como memoria caché para la base de datos, es el usuario el que debe garantizar la coherencia de los datos entre la base de datos y la memoria caché. Si desea ampliar y agregar más servidores, es probable que no esté sincronizado con la base de datos, incluso si todo parece correcto.

En su lugar, puede considerar Hazelcast. A partir de 1.9 también es compatible con el protocolo de Memcache. En comparación con Memcached Hazelcast quiere que implemente Map Persister y solo él mismo actualiza la base de datos para las entradas actualizadas. De esta forma, no tiene que manejar el tipo de material "Comprobar caché, si la base de datos de actualización ha cambiado".

Answer 4

Estoy usando MongoDB como almacenamiento de sesión actualmente. Es posible evitar las condiciones de carrera mencionadas por pilif. Encontré una clase que implementa un controlador de sesión para MongoDB (http://www.jqueryin.com/projects/mongo-session/) y lo bifurqué en github para satisfacer mis necesidades (http://github.com/halfdan/MongoSession).

Answer 5

Si escribe su aplicación para que el usuario almacene toda la información de la sesión del lado del cliente, simplemente verifique esa información según sea necesario, no tendrá que preocuparse por las sesiones del lado del servidor. Este es uno de los principios en la arquitectura de estilo REST. Por ejemplo, si el usuario está solicitando agregar un artículo a su carrito de compras, simplemente almacene la lista itemID y cuente en el lado del cliente. Cuando acceda a la página del carrito, puede buscar fácilmente la información del artículo de la lista de ítems que le están indicando que están en su carrito.

Durante el proceso de pago, vaya directamente a la base de datos con las transacciones para asegurarse de que no haya condiciones de carrera, y verifique su inventario en vivo. Si el inventario no está allí cuando vayan a pagar, simplemente diga, "lo siento, acabamos de agotar existencias".Por supuesto, en ese momento deberías actualizar las cachés que tienes por ahí para decirles a las personas que tienes inventario.

Answer 6

Me gustaría ver cuánto cuesta adquirir el usuario y luego preguntar cuál es el costo de implementar un sistema realmente bueno. Tenga en cuenta que los usuarios son un método de reintento biológico. "Estoy aburrido ... presione volver a cargar ...". Si bien esta no es la solución más perfecta, a veces es aceptable frente a la comparación de costos para "no perder nada nunca".

Si desea seguridad adicional, puede hacer que sus sesiones se guarden en caché en un conjunto separado de servidores de Memcache para que no haya vaciados accidentales. :)

Hay una serie de otros sistemas membase.org y algunas otras soluciones persistentes de Memcache (implementaciones de Java) que persistirán en el almacenamiento en el disco. Si desea modificar algo su cliente, o cómo accede a Memcache, puede hacer su propia replicación de objetos de sesión de Memcache.

-daniel