weblogic multi-server cluster seesion replication

转至： 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—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 can only be deployed on a cluster, while replicated_if_clustered, async-replicated-if-clustered can also be deployed on an independent instance. Neither can be deployed only on some instances of the cluster.
Reference: http://docs.oracle.com/cd/E23943_01/web.1111/e13712/weblogic_xml.htm#i1071981
For example:
<?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_if_clustered</persistent-store-type>
    
    <timeout-secs>60</timeout-secs>
</session-descriptor>
</weblogic-web-app>
1.       Load Blanace和Session Affinity
Since the mechanism here is master-slave backup, only two instances in the cluster will have the same HTTP session data. When there are more than two instances in the cluster, in order to ensure that subsequent HTTP requests can access the session data, it is necessary to request The load balancer for pre-distributing requests supports session affinity (sticky session/seamless session). Session Affinity is able to route all requests for a specific session to the same physical machine where the session was created for the first time; otherwise, subsequent requests may not be The session data can be accessed.
If it is set to non-Replication mode, that is, memory mode, the generated JSESSIONID is similar to:
gGMWQy2LcSTHTSyLdyLpqYGskYpXPpRJkc2VB618mSKSQC9rgsCv!-1274119771!1353236040031 It
can be seen that this session has been replaced by two! divided into three parts. The first part should be the real sessionid, -1274119771 is the instance ID. And 1353236040031 is the session creation time.
Once configured in Replicated mode, Weblogic will generate a SessionID similar to:
sHkLQyQTnJQQ217Js7SmQL2x9hBb0JQ5hFm7n4QpNkZL7wMnLbPn!-9326295!959096067!1353236595093
There are three!, the second and third parts are the identifiers of the primary and secondary instances.
SessionID format: sessionid!primary_server_id[!secondary_server_id]!creationTime
2．Configure weblogic Load Blanche
Configuration method reference: http://guojuanjun.blog.51cto.com/277646/748768
1) Access through http://localhost/Cluster/cluster.jsp, the page displays:
session Id:
KSW2QyJFzVcnFxQTWpSLJLhJTTQsCzLGqlM1ShnCvSyKm2r4k29h!-1458785082!
21138912937 CreateTime: 1353238917906
current instance: Server1
You can see that the primary_server_id of the session is -1458785082, which is Server1. (The id of each server is generated at startup, so it also changes, so your test may be different from mine.) The secondary_server_id is 2113129367, which is server3. That is, server3 is the backup point of Server1.
2) Stop Server1, visit again, the page displays:
session Id:
KSW2QyJFzVcnFxQTWpSLJLhJTTQsCzLGqlM1ShnCvSyKm2r4k29h!2113129367!-481865348!1353238917906
session CreateTime :1353238917906
current instance :Server3
It can be seen that the sessionId has not changed, and the primary_server_id of the session is 2113129367, which is Server3. The secondary_server_id is -481865348, which is server0. That is, Server0 is the backup point of Server3.
3) Stop Server3, access again, the page display:
session Id:
KSW2QyJFzVcnFxQTWpSLJLhJTTQsCzLGqlM1ShnCvSyKm2r4k29h -481 865 348 1353238917906 NONE!!!
Session CreateTime: 1353238917906 Current
instance: Server0
can see sessionId not changed, the session's primary_server_id as -481 865 348, that is Server0. The secondary_server_id is NONE, that is, the session has no backup point.
Through testing, we can roughly guess the basic idea of weblogic session replication:
1) Each instance has two Session data. Primary data and backup data.
2) When the primary_server_id of the requested sessionId is the current instance, get the session response request from the primary data, otherwise go to 3).
3) When the secondary_server_id of the requested sessionId is the current instance, get the session response request from the backup data. And amend the primary_server_id/secondary_server_id of the session to be itself and its backup point.

3. Load balancing supported by
       Weblogic Weblogic supports two mechanisms for load balancing
1) Proxy plug-ins
Weblogic built-in plug-ins, namely mod_wl mentioned in http://guojuanjun.blog.51cto.com/277646/748768.
If an instance If it fails, the plug-in will locate the secondary_server of the session and send the request to it.
2) Hardware load balancers
Hardware load balancers, such as F5. These third-party products cannot locate the secondary_server of the session according to the wishes of weblogic. He will randomly select an available instance and send it to him. Then the instance obtains data through the secondary_server_id in the session id, like secondary_server.
Although weblogic allows this kind of random forwarding of requests, it is not recommended to use session incompatibility because it will bring data concurrency and consistency issues.
References:
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

weblogic multi-server cluster seesion replication

Guess you like