Estaba intentando decidir qué es mejor en un modo de proxy inverso Tomcat + Apache para la replicación de la sesión. ¿Qué es más común en las implementaciones? sesión de replicación o sesión de palo? ¿Hay algún inconveniente para la replicación de la sesión?¿Cuáles son los inconvenientes de la replicación de sesión en Tomcat?
Gracias
puedo señalar las siguientes consideraciones si vas para la replicación de sesiones.
Rendimiento
El inconveniente principal estará en el rendimiento. Las sesiones replicadas implican la copia de datos de sesión en todos los servidores del clúster. Cuantos más servidores tenga en el clúster, más gastos adicionales implicados.
Tomcat ayuda con esta sobrecarga definiendo dos modos para la replicación de la sesión.
DeltaManager (por defecto) y BackupManager
De este URL http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
Usando la configuración anterior se permitir a todos a toda la replicación de sesiones utilizando el DeltaManager replicar deltas de sesión. Por todos-todos queremos decir que la sesión se replique en todos los otros nodos en el clúster. Esto funciona muy bien para el clúster más pequeño pero no lo recomendamos para clústeres más grandes (muchos nodos tomcat). También cuando se usa el administrador delta se replicará a todos los nodos, incluso a los nodos que no tengan implementada la aplicación .
Para solucionar este problema, , querrá utilizar BackupManager. Este administrador solo replica los datos de sesión en un nodo de copia de seguridad y solo en los nodos que tienen implementada la aplicación . Lo malo de la BackupManager: no tan batalla probado como el gerente Delta
Leer this URL para los buenos consejos de diseño para el clúster si permite la replicación de sesiones.
memoria
¿Cuántos usuarios concurrentes estará llegando a la aplicación? Cuantos más usuarios, más datos se almacenan en las sesiones y, por lo tanto, una sobrecarga para la replicación de la sesión.
consideraciones Código
Además es necesario asegurarse de que los datos sean puestos en la sesión por la aplicación es serializable. La serialización de datos de sesión tiene cierta sobrecarga para replicar el estado de la sesión. Es una buena idea mantener el tamaño de la sesión razonablemente pequeño, por lo que los desarrolladores deben verificar la cantidad de datos que se ingresan en la sesión.
pegajosa Sesiones
Dadas estas consideraciones, en realidad depende de la criticidad de los casos de uso. Si elige sesiones fijas solo, entonces existe la posibilidad de perder datos de los usuarios durante un viaje crítico.
¿Tiene medios para recuperarse de eso, por ejemplo, persistiendo datos críticos en la base de datos en cada paso de una orden o viaje de pago? Si no, el usuario debe iniciar sesión y comenzar de nuevo. Esto está bien para los sitios web que no son transaccionales, pero navegue por el tipo de datos del folleto o complete formularios para capturar datos que no sean pagos, etc.
Prefiero una sesión pegajosa con memcache.
¿Se está refiriendo a la "replicación de sesión" en varios servidores Tomcat en clúster para que la sesión pueda conmutarse por error? – JoseK
¡Sí! Me pregunto qué es mejor, la replicación de sesión o la sesión de stick y sus inconvenientes. –