Integrated session sharing issues

2.1 Client Cookie Saving

Introduction

Save the cookie on the client side in an encrypted manner. The advantage is to reduce the pressure on the server side. Each time the session information is written on the client side, then Submit it again to the server via the browser. Even if two requests are completed on two servers in the cluster, the session share can be reached.

The advantage of this solution is that session information does not need to be stored on the server side, which greatly reduces the pressure on the server. Another advantage is that two or more requests in a session can be completed on multiple servers in a cluster, avoiding single points of failure. Currently, Taobao adopts this solution.

There are several disadvantages. First, when passing cookies, the length limit of the http information header allows us to only store part of the user information in the cookie; second, additional work is required to encrypt session information; third, , if this method is adopted, every time you access the second-level domain name of the website, the session information stored in the form of cookies will be included in the http information header, which will occupy a certain amount of bandwidth; finally, because this method is to process information on the client Storage, users can completely disable cookies or delete cookies, not very reliable.

2.2 Session synchronization between servers

Introduction

Using the master-slave server architecture, when the user logs in on the master server, through a script or daemon process, Pass the session information to each slave server, so that when the user accesses other slave servers, the session information can be read.

Disadvantages: For example, slow speed, instability, etc. In addition, if the session information transmission is master->slave one-way, there will be some risks. For example, if the main server is down, other servers will not be able to obtain session information

2.3 Use a cluster to manage sessions uniformly

Introduction

Provide a cluster to save session shared information. All other applications store their session information in the session cluster server group. When the application system needs session information, it directly reads it from the session cluster server. At present, most of them use Memcache to store Session.

There are currently two popular implementation solutions for using Memcache to implement Session sharing. These two solutions are mainly introduced below.

2.3.1 Using Filter method

This method uses the filter method to repackage the httpRequest object and adds the memcached client. The advantage of this method is: it is simple to use and filters Just configure it into the server. In addition, it is more flexible because it is implemented on the client, the configuration is more flexible, and it is server-independent. You can deploy it on any container that supports servlets.

2.3.2 memcached-session-manager (MSM)

memcached-session-manager, commonly known as MSM, is an open source solution used to solve the problem of session sharing in a distributed tomcat environment. . Its implementation principle is to deploy it on the server as a tomcat plug-in, modify the session-related code in the servlet container code, connect it to memcached, and create and update the session in memcached. MSM has the following features:

Supports Tomcat6, Tomcat7

Supports sticky and non-sticky Session

No single point of failure

Can handle tomcat failover

Can handle memcached failover

Plug-in session serialization

Allows session to be saved asynchronously to improve response speed

Only when the session is modified, Only then will the session be written back to memcached

JMX Management & Monitoring

MSM (memcached-session-manager) supports tomcat6 and tomcat7, and uses Value (Tomcat valve) to track Request. When the Request request arrives, the session is loaded from memcached. When the Request request ends, the tomcat session is updated to memcached to achieve the purpose of session sharing. Sticky and non-sticky modes are supported.

Advantages: Developers no longer need to consider the issue of session sharing. They can focus on program development and just use it like a normal session. There is no need to write code explicitly, you only need to configure the server to use it.

Disadvantages: If you want to change the session policy, you must redeploy the servlet container of each server.

For details, please refer to: http://code.google.com/p/memcached-session-manager/

2.4 Persisting the Session to the database

Introduction

This method of sharing session stores the session information in the database, and other applications can check the session information from the database. The database currently used when using this solution is generally mysql.

The solution of using the database to share the session has certain practicality, but it also has the following shortcomings: First, the concurrent reading and writing of the session is completed in the database, which requires relatively high performance for MySQL; secondly, we need to additionally implement the session Eliminate the logic code, that is, regularly update and delete session information from the database table, which increases the workload

2.5 Configure the load balancing server so that a user's session can be completed on one server .Regularly back up session information to the salve. After a server goes down, the user's request is transparently forwarded to other servers in the cluster through the balancing server. At this time, the backed up session information needs to be read from the salve.

The above is the detailed content of Integrated session sharing issues. For more information, please follow other related articles on the PHP Chinese website!