DBMNG数据库管理与应用

抓住自己最有兴趣的东西,由浅入深,循序渐进地学……
当前位置:首页 > 服务器配置 > Resin

Resin 跨服务器的session传递

1.   基于文件的session持久化技术

Seesion能够被跨服务器持久化, 包含我们的web应用的Class发生变化, 譬如在开发期间,使用基于文件的持久化Seesion技术是非常便捷的, 尤其是我们在开发时, 当Servlet会发生经常变化


在resin.conf中配置如下


<web-app xmlns="http://caucho.com/ns/resin">

  <session-config>

    <file-store>WEB-INF/sessions</file-store>

  </session-config>

</web-app>

这样的配置是将Session写在一个在<file-store>中定义的文件目录中,当Session发生变化时,将会把session写入一个文件, 当web应用被加载时, resin会从文件里面加载session


但是,基于文件的session技术在做跨服务器的session传递时是没有作用的,有人提出使用NFS技术, 在多个服务器之间共享这个session持久文件, 但是NFS往往会从本地调用缓存, 这样一来, 实际存放session的文件发生变化时,不能及时在另一台服务器上得到体现


2.   分布式session

分布式session比文件持久session复杂得多, 文件持久session是一个简单的基于内存的session管理, 但是分布式session必须事先在多台服务器之间实现session变化的传递


多台机器的负载均衡, 使用的session技术不外乎sticky sessions (粘性session)或者symmetrical sessions(对称session)。前者关注的是负载均衡技术, 后者是关注JVM的技术。使用何种技术依赖于你有什么样的硬件,多少台机器,你要如何管理session.


2.1.      对称session

对称session技术多用于负载均衡,一个session可以从A机器中取出,存放在B机器里面,采用JDBC session技术的对称session ,需要描述resin.conf中的“always-load-session”属性。 每个请求都获得最新状态的session


对于对称的session来说, 一个完全一致的服务器环境是他可以工作的基础,所以较粘性session来说, 由于它每次web请求都需要更新session信息, 所以比较低效。


2.2.      粘性session

粘性的session依赖JVM来实现, 只要session开始工作,那么负载均衡将永远把相同的session存放于同一个机器上, 举个例子来说,有一个ID为aaaXXX的session永远放在A机器的JVM-A上, 而bbbXXX的session用于放在B机器的JVM-B上。


使用这种技术的是比较可靠的, 如果A机器宕机, 则可以从B机器上取得我们需要的session, 而使用者并无从查觉,另外使用粘性session是高效率的,只有session发生变更时才需要重写到服务器。


2.3.      always-load-session

正如上文提及的对称式的session技术需要使用<always-load-session>属性来标识是否每个请求都要从服务器更新session, 如果使用的是jdbc-session技术, 那么这个标识是一定要在配置文件中加上的, 但是如果是基于tcp-session技术的话, 可以不用标识, 因为tcp-session的技术更为老练一些。


always-save-session属性强制了客户的每次web请求需要从服务器的session存储中获得更新,默认情况,用户只有在创建session才从服务器持久层取得session,但是使用了多个服务器的话, 就需要标识来强制每个请求都从服务器持久层取得session来保证每个服务器的session是一致的。


2.4.      always-save-session

默认情况, 当session发生变化时Resin会将session写入到服务器, 如:你在程序中调用了setAttribute()方法,但是假设你仅仅是更新了session中的对象的一个属性, 譬如存放的是一个用户对象, 你改变了这个用户对象的年纪, 这个时候resin并不能侦测到session的变化,也不会保存这个变化。


使用<always-save-session >属性, 可以确保在客户么个请求结束后, 都会在服务器保存session的变化, 尽管低效, 但是非常可靠。


 


3.   基于数据库的session同步技术

基于数据库的session技术非常容易理解, resin把session写入到数据库中, 每次请求session从数据库中来获得。


为了效率的考虑, jvm所在机器必须保存session的缓存,只有当session发生变化时,这个机器才会向数据库重新查询,如果另一个jvm里面的代码改变了session,将会通知这个机器向数据库请求获得更新。


这样的数据库同步技术会导致向一个已经存在session的机器分发变更了的session数据,这样数据库可能会成为瓶颈, 为了解决这样的问题, 采用便捷轻巧的mysql来存储session,使用Oracle来存放业务数据是一个不错的主意。


使用数据库技术<database>属性是必须的, 加上这个属性,resin会自动在制定数据库上创建session存储的表


<resin xmlns="http://caucho.com/ns/resin">

<server>

  <http id='a' port='80'/>

  <http id='b' port='80'/>

 

  <database jndi-name="jdbc/session">

    ...

  </database>

 

  <cluster>

    <srun id='a' host='host-a' port='6802'/>

    <srun id='b' host='host-b' port='6802'/>

  </cluster>

 

  <persistent-store type="jdbc">

    <init>

      <data-source>jdbc/session<data-source>

    </init>

  </persistent-store>

  ...

 

  <web-app-default>

    <session-config>

      <use-persistent-store/>

    </session-config>

  </web-app-default>

 


持久化的session必须在上文的<sever>中使用<persistent-store>来定义。而每一个web-app应用必须使用<use-persistent-store/>来表示需要分布式session技术


ata-source


数据源


table-name


存放session数据的表名


blob-type


 Blob类型


max-idle-time


 释放时间


 


CREATE TABLE persistent_session (


  id VARCHAR(64) NOT NULL,


  data BLOB,


  access_time int(11),


  expire_interval int(11),


  PRIMARY KEY(id)


)


下面是一个使用持久层session的web-app定义示例:


<web-app xmlns="http://caucho.com/ns/resin">

  <session-config>

    <use-persistent-store/>

    <always-save-session/>

  </session-config>

</web-app>

4.   基于集群session技术

基于集群的session技术应用在服务器集群领域, 在一些案例中采用数据库的session分布技术是高效的, 有些场合,采用集群的session是高效的。


在集群的session每一个服务器拥有一个jvm和一个备份jvm, session同时保存在自己的jvm和备份jvm里面。


同样地, 你必须修改<sever>中的<cluster>下面的<srun>属性来达到集群session的效果, 在web-app中使用<use-persistent-store>属性来标识这个应用采用session持久化技术


配置如下:


<resin xmlns="http://caucho.com/ns/resin">


  ...


 


<server>


  <cluster>


    <srun id="a" host="192.168.0.1" port="6802" index="1"/>


    <srun id="b" host="192.168.0.2" port="6802" index="2"/>


  </cluster>


 


  <persistent-store type="cluster">


    <init path="cluster"/>


  </persistent-store>


  ...


 


<web-app xmlns="http://caucho.com/ns/resin">

  <session-config>

    <use-persistent-store="true"/>

  </session-config>

</web-app>

 


<srun>和<srun-backup>都被视为一个集群服务器, 当一个服务器上的session发生变化时, 它会自动寻找其他的备份服务器, 并把备份服务器上的session更新, 当这个服务器重新启动时, 他会向备份服务器请求session,并获得备份。


<resin xmlns="http://caucho.com/ns/resin">

<server>

  <http id='a' port='80'/>

  <http id='b' port='80'/>

 

  <cluster>

    <srun id='a' host='host-a' port='6802'/>

    <srun id='b' host='host-b' port='6802'/>

  </cluster>

 

  <persistent-store type="cluster">

    <init path="cluster"/>

  </persistent-store>

 

  <host id=''>

  <web-app id=''>

 

  <session-config>

    <use-persistent-store="true"/>

  </session-config>

 

  </web-app>

  </host>

</server>

</resin>


本站文章内容,部分来自于互联网,若侵犯了您的权益,请致邮件chuanghui423#sohu.com(请将#换为@)联系,我们会尽快核实后删除。
Copyright © 2006-2023 DBMNG.COM All Rights Reserved. Powered by DEVSOARTECH            豫ICP备11002312号-2

豫公网安备 41010502002439号