Является ли кластеризация Tomcat единственным способом репликации сеансов? - PullRequest
3 голосов
/ 30 января 2012

Я протестировал Tomcat Clustering для session replication на серверах Ubuntu с Apache в качестве балансировщика нагрузки внешнего интерфейса.Из моего опыта тестирования я говорю, что лучше не использовать кластеризацию tomcat, а запускать каждый узел как отдельный, не зная друг друга без какой-либо репликации сеанса, поскольку я чувствовал, что это медленно, требует много времени для запуска сервиса tomcat и потребляет больше памяти.И FarmDeployer не всегда надежен при развертывании, и вся конфигурация должна быть помещена в элемент <Host></Host> для работы развертывателя фермы, а также для каждого виртуального хостинга и, следовательно, огромного файла server.xml.Ниже представлен виртуальный хостинг Tomcat с конфигурацией кластера с одного из использованных мной узлов.

<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>

Хорошо ли кластеризация Tomcat для использования в рабочей среде или есть альтернативный способ репликации сеансов?Или я что-то упускаю в вышеупомянутой конфигурации, которая может быть точно настроена?

Любые идеи приветствуются.Спасибо!

1 Ответ

6 голосов
/ 01 февраля 2012

Одним решением для восстановления сеанса / восстановления сеанса для tomcat является memcached-session-manager (мсм), поддерживающее как липкие, так и не липкие сеансы.msm использует memcached (или любой бэкэнд, говорящий по протоколу memcached) в качестве бэкэнда для резервного копирования / хранения сеансов.

В режиме слипания все еще хранятся в tomcat, а memcached используется только как дополнительныйрезервное копирование - для восстановления после отказа сеанса.

В неконтактном режиме сеансы хранятся только в memcached и больше не в tomcat, как и в несвязанных сеансах, хранилище сеансов должно быть внешним (чтобы избежать устаревших данных).

Также имеется специальная поддержка membase / * * * * * * * * * * * * * * * *, что полезно для хост-решений, где вы получаете доступ к определенному сегменту с соответствующей аутентификацией.

Сериализация сеанса является подключаемой, поэтому вы не привязаны к сериализации Java (и классам, реализующим Serializable).Например, доступен сериализатор kryo , который является одной из самых быстрых доступных стратегий сериализации .

Домашняя страница msm в основном описывает липкий сеансподход, подробности о нелипких сессиях вы можете искать или спрашивать в списке рассылки .

Подробности и примеры, касающиеся конфигурации, можно найти в вики msm (SetupAndConfiguration).

...