TOMCAT7 Redis-based session sharing Combat II

Currently, in order for the web to adapt to large-scale access, the application cluster deployment needs to be implemented. The most effective scenario for a cluster is load balancing , and every request for a load balancer user can be assigned to an unstable server, so we first have to resolve the session's Unity To ensure that regardless of the user's request is forwarded to which server can guarantee the normal use of users, that is, the need to implement the session of the sharing mechanism .

There are several scenarios for implementing session unification under the cluster system:
(1) Session replication sharing between application servers (such as Tomcat's own session sharing)
(2) session sharing based on cache DB caching

One, session replication sharing between application servers (Tomcat comes with the feature)
Session replication sharing, mainly refers to the cluster environment, more than one application server synchronization between the session, so that the session is consistent, external transparency. If one of the servers fails, according to the principle of load balancing, the Web server (Apache/nginx) will traverse the search for available nodes, distribute the request, because the session is synchronized, so that the user's session information will not be lost.

Disadvantages of this scenario:
Technology is complex and must be done between the same middleware (e.g., tomcat-tomcat).
The performance penalty for session replication increases rapidly. Especially when large objects are saved in the session, and the object changes rapidly, the performance decreases more significantly. This feature limits the horizontal scaling of Web applications.
Session content serialization (serialize) consumes system performance.
The session content is synchronized to the member through the broadcast, will cause the network traffic bottleneck, even is the intranet bottleneck.

Second, session sharing based on Memcached cache
Even with cachedb access to the session information, the application server accepts the new request to save the session information in the cache db, and when the application server fails, the Web server (Apache/nginx) traverses the search for available nodes, distributes the request, When the application server discovers that the session is not in native memory, it goes to the cache db, and if it is found, it is copied to this machine, so that session sharing and high availability are realized.
There are currently open source MSM to solve the Session sharing between Tomcat: Memcached_session_manager (MSM)
http://code.google.com/p/memcached-session-manager/
A highly available Tomcat session sharing solution, in addition to the ability to quickly read session information from native memory (sticky session only), can also use memcached Access session for high availability.

Characteristics
Support TOMCAT6, TOMCAT7 support sticky, non-sticky session
No single point of failure
Can handle Tomcat failover
Can handle memcached failover
Plug-in session serialization
Allows the session to be saved asynchronously to increase response speed
The session will be written back to memcached only if the session has been modified.
JMX Management & Monitoring

Deficiencies of the programme:
Memcache supported data structures are relatively single
Memcache memory must be large enough otherwise the user session will be cleared from the cache
Need to refresh the cache periodically
Memcache data that exists in memory will be lost when the server fails

In order to solve the problem based on Memcache, the following solution is proposed:

Third, the session sharing based on Redis cache
In combination with the above analysis, Redis is responsible for the storage of session data , and our own session Manager will be responsible for the session life cycle management. With Redis's own key expiration time mechanism, we no longer need to refresh and do additional processing on a regular basis.

Until 2015-09-20 is not support Tomcat8, open source git address: Https://github.com/jcoleman/tomcat-redis-session-manager
Because we use Redis to store the session, it is only if Redis is installed and configured. (This article does not perform the installation configuration instructions for Redis)
Steps to use:

1. Copy the Tomcat-redis-session-manager-1.2.jar, Jedis-2.6.1.jar, Commons-pool2-2.2.jar three jar packages to the tomcat7/lib.
2. Add the following in Tomcat's Conf/context.xml file:

<valve classname= "Com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve"/><manager className = "Com.orangefunction.tomcat.redissessions.RedisSessionManager"                   host= "localhost" <!--optional, default is " localhost "-                   Port=" 6379 "<!--optional, default is" 6379 "--                   Database=" 0 "<!--optional, default is" 0 "-- >                   maxinactiveinterval= "60" <!--optional, default is "(Unit: Seconds)"--/>

3. Restart TOMCAT7 to see the session_id in Redis as follows:

127.0.0.1:6379> keys wj*1) "WJSESSIONID:6D5B0E0FD89E3A170B8BC5B8C112D3FD" 2) "Wjsessionid : 9546b26d78c99e8f0bf785535e319271 "3)" wjsessionid:839a35cfe17e900a81f50d629c104d2f "4)" WJSESSIONID : 1c287c797cf00c82bbbf37a617a3b55c "5)" wjsessionid:fa2822c5021139641760754242f73393 "6)" WJSESSIONID: E904369e5b24d39b4e25515d50650ea6 "127.0.0.1:6379>

Here's a special note:
Git open source project is to store SessionID as key directly into Redis, as follows:

1) "6D5B0E0FD89E3A170B8BC5B8C112D3FD" 2) "9546b26d78c99e8f0bf785535e319271" 3) "839a35cfe17e900a81f50d629c104d2f" 4) "1C287C797CF00C82BBBF37A617A3B55C" 5) "fa2822c5021139641760754242f73393" 6) "E904369e5b24d39b4e25515d50650ea6"

I made a little change to the project.
The reasons for the modification include several points:
1, the project also uses Redis to do other data storage, directly using such a key stored in Redis, it is not intuitive to distinguish which key is used for session sharing.
2, the project includes several services (web, WAP, CMS), each service needs to do load balancing session sharing, so that it is not possible to distinguish which session belongs to which service.
3, it is difficult to count the number of online users per service.

I have different sessioncookiename for each of my services in a cluster deployment (web = Wjsessionid, wap = Mjsessionid, CMS = Cmsjsessionid)
Do not know how to configure, here is a brief, directly in the tomcat7/conf/server.xml the bottom of the context to add the Sessioncookiename configuration can:

<context docbase= "F:\workspace\web" path= "" reloadable= "false" Sessioncookiename= "Wjsessionid"/>

My modified project has been shared to: http://download.csdn.net/detail/catoop/9122857 (Project is a MAVEN project)
Where Tomcat-redis-session-manager\target\tomcat-redis-session-manager-1.2.jar can be used directly.

TOMCAT7 Redis-based session sharing Combat II