Weblogic Session复制策略与方式
在Weblogic中，HttpSession Replication的方式是通過在weblogic.xml中的session- descriptor的定義persistent-store-type來實現(xiàn)的. 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的數(shù)據(jù). 當(dāng)集群里的實例多于2個以上時,為了確保后續(xù)的HTTP請求能訪問到Session數(shù)據(jù), 必須要求前置分發(fā)請求的load balancer支持session affinity(sticky session/seamless session). Session Affinity就是能夠把特定Session的所有請求都路由到第一次創(chuàng)建Session的同一物理機器上;否則后續(xù)的請求就有可能不能夠訪問 Session數(shù)據(jù)了.
如果設(shè)置成非Replication方式即memory模式, 生成的JSESSIONID類似:
gGMWQy2LcSTHTSyLdyLpqYGskYpXPpRJkc2VB618mSKSQC9rgsCv!-1274119771!1353236040031
可以看出這個session被二個！分隔成三部分。第一部分應(yīng)該是真正的sessionid, -1274119771是實例標(biāo)識。而1353236040031為session創(chuàng)建時間。
一旦配置成Replicated模式,Weblogic會生成的SessionID類似:
sHkLQyQTnJQQ217Js7SmQL2x9hBb0JQ5hFm7n4QpNkZL7wMnLbPn!-9326295!959096067!1353236595093
這里出現(xiàn)三個!，第二，三部分為主備實例的標(biāo)識。
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復(fù)制的基本思路：
1)?????? 每個實例都有兩份Session數(shù)據(jù)。主數(shù)據(jù)和備份數(shù)據(jù)。
2） 當(dāng)請求的sessionId的primary_server_id為當(dāng)前實例時，從主數(shù)據(jù)里獲取session響應(yīng)請求,否則進行3).
3） 當(dāng)請求的sessionId的secondary_server_id為當(dāng)前實例時，從備份數(shù)據(jù)里取session響應(yīng)請求。并修正該session的primary_server_id/secondary_server_id為自已及其的備點。
?
? 3. Weblogic支持的負載均衡
?????? Weblogic支持兩種機制的負載均衡
1)?????? Proxy plug-ins
Weblogic內(nèi)置插件，即http://guojuanjun.blog.51cto.com/277646/748768中提到的mod_wl.
如果一個實例失敗，plug-in會定位該session的secondary_server,將請求發(fā)給它。
2)?????? Hardware load balancers
Hardware load balancers，比如F5. 這些第三方產(chǎn)品并不能按weblogic的意愿，定位session的secondary_server。他會隨機選機選擇一個可用實例發(fā)給他。然后該實例通過session id里的secondary_server_id,像secondary_server獲取數(shù)據(jù)。
雖然weblogic允許這種請求的隨機轉(zhuǎn)發(fā)，但并不建議使用會話不親和方式，因為這將帶來數(shù)據(jù)并發(fā)和一致性問題。
參考文獻：
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
?
?
?
總結(jié)
以上是生活随笔為你收集整理的Weblogic Session复制策略与方式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Hyper-V与VMware的技术特性对
- 下一篇： 【spring】【转】Spring 框架