Processing of the post session of Nginx+tomcat cluster

In the case of a single node low load, we usually put a Web application into a war package to put the Web application server, such as Tomcat under the line (1). However, with the increase of user volume, the system load is increasing, at this time we usually use multiple Web application servers to form a cluster to share load (TOMCAT1, TOMCAT2 on the deployment of application Application1; Application Application3 is deployed separately on the TOMCAT3, a user's access to the same app may be assigned to access the app from different tomcat (2, Session1 and Session2 simultaneously access Application1). Assuming that our Web access requests are stateless, there is no difference between multiple background applications and the processing of a background app, which can be handled logically based on the parameters of each request. But usually we will user information, authentication data into the session to do user authentication, user status data and other basic framework of processing, then each time we assign to the Web server background access requests need to record session status and data, to ensure that each user access, The data retrieved from the session in the background is consistent.

Here, we can clearly see that in the cluster environment, a user request access to APPLICATION1, the first request was Nginx forwarded to TOMCAT1, generated SESSION1, at this time, APPLICATION1 saved a certain data into SESSION1. Then, the user makes a second request, then, Nginx forwarded the request to TOMCAT2, then TOMCAT2 generated a new SESSION2 to access the APPLICTION1, if APPLICTION1 from the session to take the data just deposited, Because SESSION2 is a new generation of TOMCAT2, not just the SESSION1 of the data, it will not take the data we want.

So, naturally, we think of the need to keep session1 and session2 consistent.

There are two obvious ways to maintain consistency between session1 and Session2, one is to keep the data in Session1 and session2 consistent, and the other to make Session1 and session2 a session, That is, if the same user accesses Applcation1, TOMCAT1 and TOMCAT2 produce a shared session. Here are the two ways to handle this.

1. Session replication between Tomcat.

As the name implies, the changed data is distributed to other Tomcat when a Tomcat session is changed. 3

Tomcat is the data that is sent as an IP group advertisement to send the data to other members of the cluster group. Here, the same user accesses the APPLICATION1 session data is synchronized with each other, their data is the same, the App1sesson is expressed.

The configuration method is to configure the Manager,Channel, and the Distributable property of Web. XML in the Conf/server.xml file. There are a lot of configuration introduced on the net, here is not verbose.

2. Share session with memcached session Manager.

Here, the Session1 and Session2 generated by TOMCAT1 and TOMCAT2 are used by the shared session in the cache under the management of Session Mananger, The session that is uploaded to the Application1 application when the app is accessed is the shared session in the diagram.

This shared session program can be used by Google's memcached session manager, noting that the version of Tomcat corresponds to the download. It is cached with memcached, and all Tomcat nodes need to be installed Memcached-session-manager when they are installed. Support Sticky session and Non-sticky session. The approximate principle is that when a request is completed, the session is sent back to memcached for backup. When the next request starts, the local session is available, the direct service, and after the request is completed, the session is returned to the memcached backup. If the next request is routed to another Tomcat. The tomcat responsible for handling this request is not clear about the session. At this point it will find the session from Memcached, update the session and save it in the native content. The request ended, the session was modified, sent back to memcached backup. Such as:

The configuration method on the net also has a lot of introduction, mainly modify Tomcat under Conf/server.xml, Memcachednodes can specify multiple memcached nodes, separated by commas.

<manager classname= "De.javakaffee.web.msm.MemcachedBackupSessionManager"
Memcachednodes= "n1:localhost:11211"
Requesturiignorepattern= ". *\. (PNG|GIF|JPG|CSS|JS) {1}quot; "
Sessionbackupasync= "false"
sessionbackuptimeout= "1800000"
Copycollectionsforserialization= "false"
Transcoderfactoryclass= "De.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>

If non-sticky, configure sticky= "false":

<manager classname= "De.javakaffee.web.msm.MemcachedBackupSessionManager"
Memcachednodes= "n1:localhost:11211"
Sticky= "false"
Requesturiignorepattern= ". *\. (PNG|GIF|JPG|CSS|JS) {1}quot; "
Sessionbackupasync= "false"
Lockingmode= "Uripattern:/path1|/path2"
Transcoderfactoryclass= "De.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>

Processing of the post session of Nginx+tomcat cluster