Thanks: http://blog.csdn.net/u010028869/article/details/50773174?ref=myread
foreword
After building the cluster environment, one of the issues that has to be considered is how to deal with the session generated by user access. If no processing is done, the user will log in frequently. For example, there are two servers A and B in the cluster. When the user visits the website for the first time, Nginx forwards the user request to the A server through its load balancing mechanism. A server will create a Session for the user. When the user sends the request for the second time, Nginx will load balance it to the B server. At this time, the B server does not have a session, so the user will be kicked to the login page. This will greatly reduce the user experience and lead to the loss of users, which should never occur in the project.
We should process the generated Session and ensure the user's experience through sticky Session, Session replication or Session sharing.
Below I will explain 5 kinds of Session processing strategies, and analyze their advantages and disadvantages.
The first: sticky session
Principle: Sticky Session refers to locking the user to a certain server. For example, in the above example, when the user requests for the first time, the load balancer forwards the user's request to the A server. If the load balancer sets a sticky session , then each subsequent request of the user will be forwarded to the A server, which is equivalent to sticking the user and the A server together. This is the sticky session mechanism.
Advantages: simple, no need to do any processing on the session.
Disadvantages: lack of fault tolerance. If the currently accessed server fails, when the user is transferred to the second server, his session information will be invalid.
Applicable scenarios: failures have little impact on customers; server failures are low-probability events.
Implementation method: Take Nginx as an example, configure the ip_hash attribute in the upstream module to implement a sticky session.
upstream mycluster{
#这里添加的是上面启动好的两台Tomcat服务器
ip_hash;#粘性Session
server 192.168.22.229:8080 weight=1;
server 192.168.22.230:8080 weight=1;
}- 1
- 2
- 3
- 4
- 5
- 6
The second: server session replication
Principle: If the session on any server changes (adds, deletes, or changes), the node will serialize all the content of the session, and then broadcast it to all other nodes, regardless of whether other servers need the session or not, so as to ensure the synchronization of the session.
Advantages: fault-tolerant, sessions between servers can respond in real time.
Disadvantages: It will cause a certain pressure on the network load. If the session volume is large, it may cause network congestion and slow down the server performance.
Method to realize:
① Set tomcat, server.xml to enable tomcat cluster function
Address: Just fill in the local ip, set the port number, and prevent port conflicts.
② Add information in the application: Notify that the application is currently in a cluster environment, support distributed
options to add in web.xml <distributable/>
The third type: session sharing mechanism
Use distributed caching solutions such as memcached and redis, but require that Memcached or Redis must be a cluster.
There are also two mechanisms for using Session sharing. The two situations are as follows:
① Sticky session processing method
Principle: Different tomcats specify access to different main memcached. Information between multiple Memcached is synchronized, master-slave backup and high availability. When a user accesses, a session is first created in tomcat, and then a copy of the session is placed on its corresponding memcahed. Memcache only plays a backup role, and reads and writes are all on tomcat. When a tomcat hangs, the cluster locates the user's access to the standby tomcat, and then finds the session according to the SessionId stored in the cookie. If it cannot find it, it goes to the corresponding memcached to go to the session, and after it is found, it is copied to the standby tomcat. superior.
② Non-sticky session processing method
Principle: memcached is master-slave replication, writing sessions are written to the slave memcached service, and reads are read from the master memcached, tomcat itself does not store sessions
Advantages: fault-tolerant, session real-time response.
Implementation method: use the open source msm plug-in to solve the session sharing between tomcat: Memcached_Session_Manager (MSM)
a. Copy the relevant jar package to the tomcat/lib directory
JAVA memcached客户端：spymemcached.jar
msm项目相关的jar包：
1. 核心包，memcached-session-manager-{version}.jar
2. Tomcat版本对应的jar包：memcached-session-manager-tc{tomcat-version}-{version}.jar
序列化工具包：可选kryo，javolution,xstream等，不设置时使用jdk默认序列化。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
b. Configure Context.xml and add the Manager that handles Session
Sticky Mode Configuration:
Non-sticky configuration:
Fourth: session persistence to the database
Principle: Needless to say, take out a database dedicated to storing session information. Ensure session persistence.
Advantages: There is a problem with the server, and the session will not be lost
Disadvantages: If the website has a large number of visits, storing the session in the database will put a lot of pressure on the database, and additional overhead will be required to maintain the database.
The fifth terracotta implements session replication
Principle : The basic principle of Terracotta is that for data shared between clusters, 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 seen as an optimization of the second scheme.
Advantages : In this way, the pressure on the network is very small, and each node does not have to waste CPU time and memory for a large number of serialization operations. Applying this inter-cluster data sharing mechanism to session synchronization not only avoids the dependence on the database, but also achieves the effect of load balancing and disaster recovery.
Implementation method : For reasons of space, we will discuss it in the next article.
summary
The above describes the five processing strategies for sessions in a cluster or distributed environment. Among them, in terms of wide application, the third method, that is, sharing session based on a third-party caching 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, it can also do distributed caching, POJO clustering, and JVM across clusters to achieve distributed application coordination, etc. It is also worth learning.