Le clustering Tomcat est-il le seul moyen de réplication de session?

Question

J'ai testé Tomcat Clustering pour session replication sur des serveurs ubuntu avec apache comme équilibreurs de charge frontaux. De mon expérience de test, je dis qu'il est préférable de ne pas utiliser Tomcat cluster mais d'exécuter chaque nœud comme autonome sans se connaître, sans aucune réplication de session car je trouve qu'il est lent, prend beaucoup de temps pour démarrer le service tomcat et consomme plus de mémoire. Et le FarmDeployer n'est pas toujours fiable en déploiement et toute la configuration doit être placée sous <Host></Host> pour que le déployeur de la ferme fonctionne et aussi pour chaque hébergement virtuel et donc un énorme fichier server.xml. Ci-dessous l'hébergement virtuel Tomcat avec la configuration de cluster de l'un des nœuds que j'ai utilisé.

<Host name="site1.mydomain.net" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true"> 
<Logger className="org.apache.catalina.logger.FileLogger" 
directory="logs" prefix="virtual_log1." suffix=".log" timestamp="true"/> 
<Context path="" docBase="/usr/share/tomcat/webapps/myapp" debug="0" reloadable="true"/> 

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"> 
<Manager className="org.apache.catalina.ha.session.DeltaManager" 
      expireSessionsOnShutdown="false" 
      notifyListenersOnReplication="true"/> 

     <Channel className="org.apache.catalina.tribes.group.GroupChannel"> 
      <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver" 
        address="192.168.1.8" 
        port="4001" 
        selectorTimeout="100" 
        maxThreads="6"/> 
      <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> 
      <Interceptor className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor"> 
       <Member className="org.apache.catalina.tribes.membership.StaticMember" 
         port="4002" 
         securePort="-1" 
         host="192.168.1.9" 
         domain="staging-cluster" 
         uniqueId="{0,1,2,3,4,5,6,7,8,9}"/> 

      <!-- <Member className="org.apache.catalina.tribes.membership.StaticMember" 
         port="4002" 
         securePort="-1" 
         host="192.168.1.9" 
         domain="staging-cluster" 
         uniqueId="{0,1,2,3,4,5,6,7,8,9}"/> --> 

      </Interceptor> 
     </Channel> 
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/> 
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/> 

<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/> 
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/> 

    <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer" 
      tempDir="/usr/share/tomcat/temp/" 
      deployDir="/usr/share/tomcat/webapps/" 
      watchDir="/usr/share/tomcat/watch/" 
      watchEnabled="true"/> 
    </Cluster> 
</Host> 

Le clustering Tomcat est-il bon à utiliser en production ou existe-t-il un autre moyen de réplication de session? Ou je manque quelque chose dans la configuration ci-dessus qui pourrait être affinée?

Toutes les idées sont les bienvenues. Merci!

Answer 1

Une solution de basculement de session/réplication de session pour tomcat est memcached-session-manager (msm), prenant en charge les sessions collantes et non collantes. msm utilise memcached (ou tout backend qui parle le protocole memcached) comme backend pour la sauvegarde/le stockage de session.

En mode collant les sessions sont toujours conservées dans tomcat, et memcached n'est utilisé que comme une sauvegarde supplémentaire - pour le basculement de session. En mode non collant, les sessions ne sont stockées que dans memcached et non plus dans tomcat, car dans les sessions non collantes, la session-store doit être externe (pour éviter les données obsolètes).

Il existe également un support spécial pour membase/membase buckets, ce qui est utile pour les solutions hébergées où vous avez accès à un certain compartiment avec l'authentification appropriée.

La sérialisation de session est connectable, donc vous n'êtes pas lié à la sérialisation java (et aux classes implémentant Serializable). Par exemple. il y a un sérialiseur kryo disponible, qui est one of the fastest serialization strategies available.

Le msm home page décrit principalement l'approche de session persistante, pour plus de détails concernant les sessions non collantes que vous pourriez rechercher ou demander sur le mailing list. Les détails et exemples concernant la configuration peuvent être trouvés dans le msm wiki (SetupAndConfiguration).