Session synchronization of Cluster Server and a session synchronization based on memcached

1 Session Cluster Management

In fact, the site always has a state. Each login information and user information is often stored inside the session. When a website is deployed on more than one server, the session synchronization problem is encountered. In fact even a very small site, but also to have at least two servers to each other for backup, the single traffic is necessary, more importantly, seamless cut traffic upgrade. In order to ensure uninterrupted service and the maintenance of the site to upgrade, cut traffic is the simplest. So how to ensure that the flow of the session will be synchronized with the past? In the cluster environment, there are several methods

1.1 Session Replication

This is a kind of server session management method which is used more in the early application system. The application server opens the copy function of the session of the Web container, synchronizing session objects between several servers in the cluster so that a server outage does not result in session data loss. That is, each server holds all the sessions in the cluster, and each access is only available from the local computer. Its working form is as follows:

A few lines copied from the session can be seen, this way only for small clusters. When the service cluster is large, replication between cluster servers requires a lot of traffic, consumes a large amount of network resources, and even the situation of insufficient memory

1.2 Session Binding

Session binding can be implemented using the load-balanced source address hash algorithm, and the Load Balancer server always distributes access from the same IP address to the same server. This allows all user requests to come from a single server during the entire session, ensuring that the session is always taken from this server. Its working form as shown in

But such a system clearly does not meet our needs for the system. If a server goes down, all requests processed by the session are lost, and the user cannot complete the business because there is no session after switching the server.

1.3 Using cookies to record session

This management method will record the session in the client, each time the request server, the session is placed in the request sent to the server, the server processing is completed before the modified session response to the client.

There are also drawbacks to using cookie records, such as cookie size restrictions and the limited amount of information that can be recorded, because many of the times we store in session are not string-type records. A cookie is required for each request, which affects performance and is not available if the user turns off the cookie function. But this approach is highly available and supports linear scaling of servers, which are used by many Web sites. This technique is also applied to my school website.

1.4 Session Server

If there is such a server, high availability, scalability, performance is good, there is no limit to the size of information, it is the session server. The session server can be accessed by the application server each time it reads and writes session by using the session servers which are deployed independently. Its working form is shown below.

This approach actually separates the state of the application server into a stateless application server and stateful session server, and then designs its architecture for the different characteristics of the two servers.

For stateful session servers, a simpler approach is to utilize distributed caches, databases, and so on.

2 Memcached-based session synchronization for 2.1 system architecture

I use memcached cluster simple to realize the synchronization management of Tomcat session. First, the structure of the system is posted

All servers in the system environment are CentOS6.5 environments

The system has two large memory servers with Memcached services installed as session cluster

Two servers deployed TOMCAT8 as application servers

One server deployed Apache2.4 as a load balancer server

2.2 Principle

This memcached-based session management (Memcached-session-manager SMS) utilizes Tomcat tracking for request. When request arrives, the session in Tomcat is updated to the memcached server when the corresponding session,request at the end of the memcached is obtained. Currently supports sticky and No-sticky modes:

• Sticky mode: The session in Tomcat is the backup session in the main session,memcached. When the request occurs, the container is first checked for changes, and the session is loaded from memcached to local, otherwise it is not loaded until the request is completed.

• Non-sticky mode: MEMCACHED1 is the primary session service, MEMCACHED2 for backup session in Session,tomcat. When request requests arrive, the session is loaded from memcached 2 to Tomcat, (when there is no session in the container, the main session is loaded from memcached1 to Tomcat, which is the case with only one memcached node, Or if there is a memcached1 error), when the request ends, the Tomcat session is updated to the master memcached1 and the standby memcached2, and the Tomcat session is cleared. To achieve the primary and standby synchronization purposes.

2.3 Configuration

I used the Kryo serialization of the way

(1) Modify the Context.xml file in the Conf directory of the two Tomcat servers, n1,n2 the address and port number of the two memcached server

[HTML]View plain copy

2. <Manager classname="De.javakaffee.web.msm.MemcachedBackupSessionManager"
4. memcachednodes="n1:172.20.201.191:50120 n2:172.18.124.5:50120"
6. lockingmode="Auto"
8. sticky="false"
10. requesturiignorepattern= ". *\. ( PNG|GIF|JPG|CSS|JS) $ "
12. sessionbackupasync= "false"
14. sessionbackuptimeout= "
16. copycollectionsforserialization="true"
18. transcoderfactoryclass="De.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
20. />

(2) The jar packages required to place the required jar packages in the Tomcat Lib directory are as follows:

asm-4.0

kryo-1.04 (must be this version)

kryo-serializers-0.11 (must be this version)

memcached-session-manager-1.8.3

memcached-session-manager-tc8-1.8.3 (corresponds to Tomcat version)

minlog-none-1.2

msm-kryo-serializer-1.8.3

reflectasm-1.07

spymemcached-2.10.3

Then start the Tomcat server and you're ready.

Note: Before you configure the above two steps, you need to ensure that the Apache server is already able to load-balance tomcat two servers.

2.4 Verification

(1) Access to Apache server address, load to one of the servers

(2) Stop the load to the server, refresh the page, you can see the server has switched, but the SessionID has not changed. The session synchronization function has been implemented.

Session synchronization of Cluster Server and a session synchronization based on memcached