Gestión de sesión http escalable (java, linux)

Question

¿Existe una mejor práctica para la gestión de sesión http escalable?

espacio Problema:

• cesta tipo de caso de uso. El usuario compra en el sitio, eventualmente visitando; la sesión debe ser preservada.
• centros de datos múltiples
• servidores web múltiples en cada centro de datos
• Java, Linux

Sé que hay muchas maneras de hacerlo, y siempre puedo llegar a mi propia solución específica, pero me preguntaba si la sabiduría de stackoverflow del público puede ayudar a que me centre en las mejores prácticas

en general parece que hay algunos enfoques:

• No mantener las sesiones; Siempre ejecute sin estado, religiosamente [no funciona para mí ...]
• Use j2ee, ejb y el resto de esa cuadrilla
• use una base de datos para almacenar sesiones. Supongo que hay herramientas para facilitar eso, así que no tengo que crearlo solo
• Usar memcached para almacenar sesiones (u otro tipo de almacenamiento intermedio, semi persistente)
• Usar valor-clave DB. "más persistente" que memcached
• Use "sesiones del lado del cliente", lo que significa que toda la información de la sesión vive en campos de formulario ocultos, y se transfiere de cliente a servidor. Nada está almacenado en el servidor.

¿Alguna sugerencia? Gracias

Answer 1

Me gustaría ir con un poco de solución de caché distribuida estándar. Podría ser su servidor de aplicaciones provisto, podría ser memcached, podría ser terracotta Probablemente no importe demasiado cuál elija, siempre y cuando esté utilizando algo suficientemente popular (para que sepa que la mayoría de los errores ya están cazados) .

En cuanto a sus otras ideas:

• No mantener la sesión - y cuando no sea posible
dijo Sesión lateral
• Cliente - demasiado insegura - supongamos que alguien hackea la cookie para poner precio más bajo en el carrito de la compra
• Usar la base de datos: las bases de datos suelen ser el cuello de botella más difícil de resolver, no coloque más allí de lo necesario.

Esos son mis 2 centavos :)

Con respecto a múltiples centros de datos - que tendrá que tener alguna afinidad de la sesión para el centro de datos que se inició el. No creo que haya ninguna solución para el caché distribuido que pueda funcionar entre diferentes centros de datos.

Answer 2

Parece que se ha perdido sesiones vainilla replicadas http de su lista. Cualquier contenedor de servlets que valga la pena admite la replicación de sesiones en todo el clúster. Siempre que los elementos que coloque en la sesión no sean enormes, y sean serializables, entonces es muy fácil hacerlo funcionar.

http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

edición: Parece, sin embargo, que la replicación de sesiones Tomcat no se adapta bien a las grandes agrupaciones. Por eso, se recomienda usar JBoss + Tomcat, que da la idea de "la replicación de compañeros":

http://www.jboss.org/community/wiki/BuddyReplicationandSessionData

Answer 3

Personalmente no he gestionado esos clústeres, pero cuando hice un curso de J2EE en la universidad, el profesor me dijo que guardara las sesiones en una base de datos y no intentara almacenarlas en caché. (De todos modos, no puede almacenar en caché las páginas dinámicas de forma significativa). Las sesiones de Http son del lado del cliente según la definición, ya que el ID de sesión es una cookie. Si el cliente se niega a almacenar cookies (por ejemplo, es paranoico sobre el seguimiento), entonces no puede tener una sesión. Puede obtener esta identificación llamando al HttpSession.getId().

Por supuesto, la base de datos es un cuello de botella, por lo que terminará con dos clusters: un clúster de servidor de aplicaciones y un clúster de base de datos.

Por lo que yo sé, los dos granos de mensajes con estado y sesiones regulares servlet HTTP sólo existen en la memoria sin balanceo de carga incorporada.

BTW. No almacenaría la dirección de correo electrónico o los nombres de usuario en un campo oculto, pero tal vez el contenido del carrito no sea tan confidencial.

Answer 4

Preferiría dejar de almacenar estado de aplicación de usuario en una sesión HTTP, pero eso requeriría una forma diferente de pensar cómo funciona la aplicación y utilizar una arquitectura RESTful sin estado. Esto normalmente implica dejar de admitir versiones anteriores de navegadores que no admiten arquitecturas MVWW en el lado del cliente.

El carrito de la compra no es un estado de la aplicación de usuario es un estado aplicación lo que significa que se almacena en una base de datos y administrado como tal. Puede haber una tabla de asociación que vincule al usuario con uno o varios carritos de compra suponiendo que es posible compartir carritos.

Su mayor obstáculo probablemente sea cómo autenticar al usuario para cada solicitud si no tiene estado. La autenticación básica es el enfoque más simple que no involucra sesiones, FORM-auth requerirá sesiones independientemente. Una implementación JASPIC (como HTTP Headers u OAuth) podrá mitigar sus inquietudes de autenticación en otro lugar, en cuyo caso se puede usar una cookie para administrar su token de autenticación (como FORM-auth) o encabezado HTTP como SiteMinder o certificados de cliente con Apache .

Las bases de datos más costosas como DB2 tienen características de Alta disponibilidad y Recuperación de desastres que funcionan en múltiples centros de datos. Tenga en cuenta que no está diseñado para equilibrar la carga de la base de datos, ya que habría un gran impacto debido al tráfico de la red.