Shulou(Shulou.com)06/02 Report--

Preface

Generally speaking, one of the problems we have to consider after building a cluster environment is how to deal with the session generated by user access. If no processing is done, users will log in frequently. For example, there are two servers An and B in the cluster. When a user visits the website for the first time, Nginx forwards the user's request to server A through its load balancing mechanism. Then server A will create a Session for the user. When the user sends the request for the second time, Nginx balances its load to server B, which does not have a Session, so it kicks the user to the login page. This will greatly reduce the user experience and lead to the loss of users, which should never happen to the project.

We should deal with the generated Session and ensure the user's experience through sticky Session,Session replication or Session sharing.

Below I will explain five Session processing strategies and analyze their advantages and disadvantages. Say no more, let's take a look at the detailed introduction.

The first kind: sticky session

Principle: sticky Session refers to locking users to a server. For example, when a user requests for the first time, the load balancer forwards the user's request to server A. If the load balancer sets sticky Session, then every subsequent request of the user will be forwarded to server A, which is equivalent to gluing the user and server A together. This is the sticky Session mechanism.

Pros: it is simple and does not require any processing of session.

Disadvantages: lack of fault tolerance, if the current access to the server failure, the user is transferred to the second server, his session information will be invalid.

Applicable scenario: failure has little impact on the customer; server failure is a low-probability event.

Implementation: taking Nginx as an example, the sticky Session can be realized by configuring the ip_hash attribute in the upstream module.

Upstream mycluster {# what is added here are the two Tomcat servers started above ip_hash;# sticky Session server 192.168.22.229 ip_hash;# 8080 weight=1; server 192.168.22.230 ip_hash;# 8080 weight=1;}

Second: server session replication

Principle: when the session on any server changes (add, delete, modify), the node serializes all the contents of the session and broadcasts it to all other nodes, regardless of whether the other servers need session or not, to ensure Session synchronization.

Advantages: fault-tolerant, session between servers can respond in real time.

Disadvantages: it will cause some pressure on the network load, and if the amount of session is large, it may cause network congestion and slow down the server performance.

Implementation method:

① sets tomcat, server.xml enables tomcat cluster function

Address: just enter the native ip and set the port number to prevent port conflicts.

② adds information to the application: notifies the application that it is currently in a clustered environment and supports distributed

Add options in web.xml

The third kind: session sharing mechanism

Use distributed caching schemes such as memcached and redis, but require that Memcached or Redis be clustered.

There are also two mechanisms for using Session sharing, which are as follows:

① viscous session treatment

Principle: different tomcat specifies to access different master memcached. Information between multiple Memcached is synchronized, capable of master-slave backup and high availability. When the user accesses, first create a session in the tomcat, and then put a copy of the session on its corresponding memcahed. Memcache only serves as a backup, and all reads and writes are on tomcat. When a tomcat is hung up, the cluster locates the user's access to the slave tomcat, and then finds the session according to the SessionId stored in the cookie. If it cannot be found, it goes to the corresponding memcached to session, and then copies it to the slave tomcat.

② non-viscous session treatment

Principle: memcached master and slave copy, write session all write to slave memcached service, read from master memcached, tomcat itself does not store session

Advantages: fault tolerance, session real-time response.

Implementation: using open source msm plug-ins to solve the session sharing between tomcat: Memcached_Session_Manager (MSM)

a. Copy the relevant jar package to the tomcat/lib directory

JAVA memcached client: spymemcached.jarmsm project related jar package: 1. Core package, memcached-session-manager- {version} .jar2. Tomcat version of the corresponding jar package: memcached-session-manager-tc {tomcat-version}-{version} .jar sequence chemical kit: optional kryo,javolution,xstream, etc., if not set, use jdk default serialization.

b. Configure Context.xml to join the Manager that handles Session

Sticky mode configuration:

Non-sticky configuration:

Fourth: session persistence to database

Principle: needless to say, take out a database specifically used to store session information. Ensure the persistence of session.

Pros: if there is a problem with the server, session will not be lost

Disadvantages: if the site has a large number of visitors, storing session in the database will put a lot of pressure on the database and require additional overhead to maintain the database.

The fifth terracotta to achieve session replication

Principle: the basic principle of Terracotta is that when a node changes, Terracotta only sends the changed part to the Terracotta server, and then the server forwards it to the node that really needs the data. It can be regarded as the optimization of the second scheme.

Advantages: this puts very little pressure on the network, and each node does not have to waste CPU time and memory to do a lot of serialization operations. This mechanism of data sharing among clusters is applied to session synchronization, which not only avoids the dependence on database, but also achieves the effect of load balancing and disaster recovery.

The way of realization: the reason of the length, which will be discussed in the next part.

Summary

The above are the five processing strategies of session in a cluster or distributed environment. In terms of widespread application, the third way, that is, sharing session based on the third-party cache framework, is the most widely used, both in terms of efficiency and scalability. As a JVM-level open source cluster framework, Terracotta not only provides HTTP Session replication, but also can do distributed caching, POJO clustering, JVM across clusters to achieve distributed application coordination, etc., it is also worth learning.

Summary

The above is the whole content of this article, I hope that the content of this article can bring some help to your study or work, if you have any questions, you can leave a message and exchange, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.