¿Mantener el estado en el servidor de aplicaciones o en la base de datos?

Question

REST recomienda aplicaciones web sin estado de cliente en el servidor. El famoso ejemplo de carro de compras se traduce a un recurso que generalmente reside en una base de datos.

Me pregunto si es una buena práctica utilizar una base de datos para ese tipo de datos, ya que la base de datos ya es el cuello de botella en muchas aplicaciones. ¿No sería mejor usar un enterprise haba de Java con estado? Los servidores de aplicaciones están diseñados teniendo en cuenta clustring.

¿Cuáles son las ventajas y desventajas de los dos enfoques?

Answer 1

sesiones de almacenamiento en el servidor de aplicaciones sólo funcionará si:

• Sus clientes siempre se conectan al mismo servidor de aplicaciones (también conocido como "la afinidad de sesiones")
• El clúster de aplicaciones nodos de todo el uso de un punto de montaje común (NFS, etc.) para poner en cola sesiones

Almacenamiento de sesiones en una base de datos y/o EJB centro funcionará si sus clientes no están garantizados para conectar siempre al mismo nodo de la aplicación en el clúster.

Otro enfoque a considerar es usar un servicio como memcached. Esto funcionará en cualquier caso.

Answer 2

En general:

base de datos

• más fiable y sobrevivirá a un reinicio aplicación/servidor
• se pueden compartir a través de servidores con equilibrio de carga sin tener que lidiar con las sesiones "pegajosos"
• acceso más lento

En memoria (bean con estado no distribuido)

• almacenamiento y recuperación rápida
• menos código
• se perderán si la aplicación/servidor se reinicia

Su elección será totalmente dependiente de sus requisitos de aplicación y el medio ambiente. En igualdad de condiciones, estoy a favor de la solución de base de datos debido a los beneficios de equilibrio de carga y confiabilidad, pero esto puede ser exagerado en muchos escenarios.

Answer 3

¿Qué ocurre cuando muere su servidor de aplicaciones? ¿El estado de la sesión sigue siendo importante? Ir por una base de datos.

¿Tiene más estado de sesión, entonces su servidor puede manejar para todos los usuarios concurrentes? Mover datos a una base de datos y extraer solo lo que realmente necesita en este momento, podría ser una solución.

¿Está agrupada su aplicación? Si es así, la base de datos central se asegura de que los datos de sesión estén siempre disponibles.

De lo contrario: Simplemente guárdelo en la sesión.

¿Tiene requisitos extremos de escala (como stackoverflow o sitios con aún más tráfico)? Encuentre una forma de no usar la base de datos.

Es cierto, que la base de datos es a menudo el cuello de botella. Pero una base de datos correctamente configurada debe manejar un par de bytes de datos de sesión sin problemas. Los datos más complejos y las consultas son lo que cuesta el rendimiento.

Answer 4

Todos los demás artículos son buenas sugerencias. Una más es esta: No use el estado de sesión si no lo necesita en absoluto.

Almacenamiento de sesión en una base de datos es (generalmente) una mala idea para un par de razones simples:

1. El uso típico de sesión es para no tener que cargar los datos comunes desde el servidor de base de datos varias veces. Si la sesión se almacena en el servidor de db, bueno, realmente no has logrado mucho.

2. La sesión debe ser serializada y deserializada para cada ejecución de página. Esto significa que los datos de la sesión tendrían que ser recuperados del servidor, y escritos en el servidor cada carga de página independientemente de si la usas o no.

En mi experiencia, es mucho mejor que simplemente saque los datos de su servidor de base de datos cuando realmente lo necesite. En la mayoría de los casos, las personas ponen todo tipo de datos de corta duración en sesión simplemente porque creen que están resolviendo un problema de rendimiento, cuando en realidad lo están empeorando.

Además, si limita la cantidad de datos hacia abajo (por ejemplo, a una identificación de usuario, nombre o algo similar), entonces puede almacenar eso en un cliente de cookies cifradas y no tener que preocuparse por nada.

MemCache es una opción; pero una vez más, consideraré seriamente el uso de su base de datos y veré si puede ajustar las consultas y los esquemas primero.