• weblogic 12C集群环境下的session复制


    做过weblogic集群环境的人应该都清楚,要想实现session同步,必须满足两个条件:第一,在weblogic.xml里面增加session同步相关的代码;第二,所有放入session的类都要序列化。

        但是,我终于还是栽了。两个条件明明都满足了,但就是“有些”对象就是不能同步。

        我以前使用session是这样的:

    Java代码 
        REYO reyo = (Customer)session.getAttribute(KEY_REYO);  
        reyo.setName("reyo");  

        这样写完以后,在单机环境下,session中的变量customer的name属性就被更改了。然而在集群环境下,仅仅这样做是不能触发session同步机制的。必须要把customer变量在重新放入session中,即:

    Java代码 
    session.setAttribute(KEY_REYO, customer);  

       后来我从weblogic的售后工程师那里也确认了这一点。一点点经验,和大家分享。

    在weblogic的文档中又翻出了以下内容,要是之前认真看了就好了:

    Use setAttribute to Change Session State:
    In an HTTP servlet that implements javax.servlet.http.HttpSession, use HttpSession.setAttribute (which replaces the deprecated putValue) to change attributes in a session object. If you set attributes in a session object with setAttribute, the object and its attributes are replicated in a cluster using in-memory replication. If you use other set methods to change objects within a session, WebLogic Server does not replicate those changes. Every time a change is made to an object that is in the session, setAttribute() should be called to update that object across the cluster.

    下面是补充说明:

    在Weblogic中,HttpSession Replication的方式是通过在weblogic.xml中的session- descriptor的定义persistent-store-type来实现的. persistent-store-type可选的属性包括memory, replicated, replicated_if_clustered, async-replicated, async-replicated-if-clustered, file, async-jdbc, jdbc, cookie, coherence-web.

    • memory—Disables persistent session storage.
    • replicated—Same as memory, but session data is replicated across the clustered servers.
    • replicated_if_clustered—If the Web application is deployed on a clustered server, the in-effect persistent-store-type will be replicated. Otherwise, memory is the default.
    • async-replicated—Enables asynchronous session replication in an application or Web application. See "Asynchronous HTTP Session Replication" in Performance and Tuning for Oracle WebLogic Server.
    • async-replicated-if-clustered—Enables asynchronous session replication in an application or Web application when deployed to a cluster environment. If deployed to a single server environment, then the session persistence/replication defaults to in-memory. This allows testing on a single server without deployment errors.
    • file—Uses file-based persistence (See also session-descriptor).
    • async-jdbc—Enables asynchronous JDBC persistence for HTTP sessions in an application or Web application. See Configuring Session Persistence.
    • jdbc—Uses a database to store persistent sessions. (see also session-descriptor).
    • cookie—All session data is stored in a cookie in the user's browser.
    • Coherence*-web For more information, see User's Guide for Oracle Coherence*Web.

    Replicated,async-replicated只用部置集群在集群上,而replicated_if_clustered,async-replicated-if-clustered也可以部署在独立实例上。都不能只部署在集群的部分实例中上。

    参考:http://docs.oracle.com/cd/E23943_01/web.1111/e13712/weblogic_xml.htm#i1071981

    例如:

    <?xml version="1.0" encoding="UTF-8"?>

    <weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"

      <session-descriptor> 

        <!-- <persistent-store-type>replicated</persistent-store-type> -->

        <persistent-store-type>replicated_if_clustered</persistent-store-type>

        <!--<persistent-store-type>memory</persistent-store-type>   -->

        <timeout-secs>60</timeout-secs> 

      </session-descriptor> 

    </weblogic-web-app>

    1. Load Blanace和Session Affinity

    由于这里的机制是主从备份, 所以集群中只有两个实例会有同一HTTP Session的数据. 当集群里的实例多于2个以上时,为了确保后续的HTTP请求能访问到Session数据, 必须要求前置分发请求的load balancer支持session affinity(sticky session/seamless session). Session Affinity就是能够把特定Session的所有请求都路由到第一次创建Session的同一物理机器上;否则后续的请求就有可能不能够访问 Session数据了.

    如果设置成非Replication方式即memory模式, 生成的JSESSIONID类似:

    gGMWQy2LcSTHTSyLdyLpqYGskYpXPpRJkc2VB618mSKSQC9rgsCv!-1274119771!1353236040031

    可以看出这个session被二个!分隔成三部分。第一部分应该是真正的sessionid, -1274119771是实例标识。而1353236040031为session创建时间。

    一旦配置成Replicated模式,Weblogic会生成的SessionID类似:

    sHkLQyQTnJQQ217Js7SmQL2x9hBb0JQ5hFm7n4QpNkZL7wMnLbPn!-9326295!959096067!1353236595093

    这里出现三个!,第二,三部分为主备实例的标识。

    SessionID格式的: sessionid!primary_server_id[!secondary_server_id]!creationTime

    2.配置weblogic Load Blanace

    配置方式参考: http://guojuanjun.blog.51cto.com/277646/748768

    1)       通过http://localhost/Cluster/cluster.jsp访问,页面显示:

    session Id:

    KSW2QyJFzVcnFxQTWpSLJLhJTTQsCzLGqlM1ShnCvSyKm2r4k29h!-1458785082!2113129367!1353238917906

    session CreateTime :1353238917906

    current instance :Server1

    可以看到该session的primary_server_id为-1458785082,即Server1。(每个server的id是启动时生成的,所以也是变化,所以你的测试可能与我不一样。) secondary_server_id为2113129367,即server3. 即server3是Server1的备点。

    2)       停止Server1,再次访问, 页面显示:

    session Id:

    KSW2QyJFzVcnFxQTWpSLJLhJTTQsCzLGqlM1ShnCvSyKm2r4k29h!2113129367!-481865348!1353238917906

    session CreateTime :1353238917906

    current instance :Server3

    可以看到sessionId没有变化,而该session的primary_server_id为2113129367, 即Server3。secondary_server_id为-481865348,即server0.即Server0是Server3的备点。

    3)       停止Server3,再次访问, 页面显示:

    session Id:

    KSW2QyJFzVcnFxQTWpSLJLhJTTQsCzLGqlM1ShnCvSyKm2r4k29h!-481865348!NONE!1353238917906

    session CreateTime :1353238917906

    current instance :Server0

    可以看到sessionId没有变化,该session的primary_server_id为-481865348, 即Server0。secondary_server_id为NONE,即该session没有备点.

    通过测试我们大致可以猜出weblogic session复制的基本思路:

    1)       每个实例都有两份Session数据。主数据和备份数据。

    2) 当请求的sessionId的primary_server_id为当前实例时,从主数据里获取session响应请求,否则进行3).

    3) 当请求的sessionId的secondary_server_id为当前实例时,从备份数据里取session响应请求。并修正该session的primary_server_id/secondary_server_id为自已及其的备点。

      3. Weblogic支持的负载均衡

           Weblogic支持两种机制的负载均衡

    1)       Proxy plug-ins

    Weblogic内置插件,即http://guojuanjun.blog.51cto.com/277646/748768中提到的mod_wl.

    如果一个实例失败,plug-in会定位该session的secondary_server,将请求发给它。

    2)       Hardware load balancers

    Hardware load balancers,比如F5. 这些第三方产品并不能按weblogic的意愿,定位session的secondary_server。他会随机选机选择一个可用实例发给他。然后该实例通过session id里的secondary_server_id,像secondary_server获取数据。

    虽然weblogic允许这种请求的随机转发,但并不建议使用会话不亲和方式,因为这将带来数据并发和一致性问题。

    参考文献:

      1. http://blog.csdn.net/mobicents/article/details/7067957
      2. http://docs.oracle.com/cd/E23943_01/wls.htm
      3. http://stackoverflow.com/questions/6429990/weblogic-jsessionid
  • 相关阅读:
    头像点击预览代码
    知识总结和记录——Bootstrap
    知识总结和记录——HTML
    知识总结和记录——面向对象
    知识总结和记录——递归
    知识总结和记录——迭代器和生成器
    知识总结和记录——内置函数
    zap 学习笔记
    2020年总结
    学习笔记_Linux常用指令
  • 原文地址:https://www.cnblogs.com/interdrp/p/4109748.html
Copyright © 2020-2023  润新知