weblogic多服务器集群 seesion复制
转至：http://blog.csdn.net/mobicents/article/details/7067957
在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—Disablespersistentsessionstorage.
·replicated—Sameasmemory,butsessiondataisreplicatedacrosstheclusteredservers.
·replicated_if_clustered—IftheWebapplicationisdeployedonaclusteredserver,thein-effectpersistent-store-typewillbereplicated.Otherwise,memoryisthedefault.
·async-replicated—EnablesasynchronoussessionreplicationinanapplicationorWebapplication.See"AsynchronousHTTPSessionReplication"inPerformanceandTuningforOracleWebLogicServer.
·async-replicated-if-clustered—EnablesasynchronoussessionreplicationinanapplicationorWebapplicationwhendeployedtoaclusterenvironment.Ifdeployedtoasingleserverenvironment,thenthesessionpersistence/replicationdefaultstoin-memory.Thisallowstestingonasingleserverwithoutdeploymenterrors.
·file—Usesfile-basedpersistence(Seealsosession-descriptor).
·async-jdbc—EnablesasynchronousJDBCpersistenceforHTTPsessionsinanapplicationorWebapplication.SeeConfiguringSessionPersistence.
·jdbc—Usesadatabasetostorepersistentsessions.(seealsosession-descriptor).
·cookie—Allsessiondataisstoredinacookieintheuser'sbrowser.
·Coherence*-webFormoreinformation,seeUser'sGuideforOracleCoherence*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
例如：
<?xmlversion="1.0"encoding="UTF-8"?>
<weblogic-web-appxmlns="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-apphttp://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.LoadBlanace和SessionAffinity
由于这里的机制是主从备份,所以集群中只有两个实例会有同一HTTPSession的数据.当集群里的实例多于2个以上时,为了确保后续的HTTP请求能访问到Session数据,必须要求前置分发请求的loadbalancer支持sessionaffinity(stickysession/seamlesssession).SessionAffinity就是能够把特定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．配置weblogicLoadBlanace
配置方式参考:http://guojuanjun.blog.51cto.com/277646/748768
1)通过http://localhost/Cluster/cluster.jsp访问，页面显示:
sessionId:
KSW2QyJFzVcnFxQTWpSLJLhJTTQsCzLGqlM1ShnCvSyKm2r4k29h!-1458785082!2113129367!1353238917906
sessionCreateTime:1353238917906
currentinstance:Server1
可以看到该session的primary_server_id为-1458785082，即Server1。(每个server的id是启动时生成的，所以也是变化,所以你的测试可能与我不一样。)secondary_server_id为2113129367,即server3.即server3是Server1的备点。
2)停止Server1,再次访问,页面显示:
sessionId:
KSW2QyJFzVcnFxQTWpSLJLhJTTQsCzLGqlM1ShnCvSyKm2r4k29h!2113129367!-481865348!1353238917906
sessionCreateTime:1353238917906
currentinstance:Server3
可以看到sessionId没有变化，而该session的primary_server_id为2113129367,即Server3。secondary_server_id为-481865348,即server0.即Server0是Server3的备点。
3)停止Server3,再次访问,页面显示:
sessionId:
KSW2QyJFzVcnFxQTWpSLJLhJTTQsCzLGqlM1ShnCvSyKm2r4k29h!-481865348!NONE!1353238917906
sessionCreateTime:1353238917906
currentinstance:Server0
可以看到sessionId没有变化，该session的primary_server_id为-481865348,即Server0。secondary_server_id为NONE,即该session没有备点.
通过测试我们大致可以猜出weblogicsession复制的基本思路：
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)Proxyplug-ins
Weblogic内置插件，即http://guojuanjun.blog.51cto.com/277646/748768中提到的mod_wl.
如果一个实例失败，plug-in会定位该session的secondary_server,将请求发给它。
2)Hardwareloadbalancers
Hardwareloadbalancers，比如F5.这些第三方产品并不能按weblogic的意愿，定位session的secondary_server。他会随机选机选择一个可用实例发给他。然后该实例通过sessionid里的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