A common synchronization solution of session in Web cluster and its comparison

with the function of the website more and more, the user volume is more and more huge, the single node mode has been unable to support the normal operation of the whole system, and the user page access time is more and more slow, the heavy will cause the whole system to be paralyzed. This time

The need to optimize or adjust the current architecture, most people will use a variety of load balancing software such as Nginx, Hproxy, LVS, etc., some use a distributed approach to the system according to the function of splitting into many systems, also some based on the region

and the network to achieve access to different node deployment of the system, but also some large high-traffic, high-load system to load balance, distributed and based on the region, network and other methods are integrated to achieve the normal operation of the system.

The use of load balancing software is now a more than the way to take. However, the application of load balancing software will face the problem of session synchronization. Here are a few ways to solve the problem.

1. How client-side cookies are encrypted

The session data is stored in a cookie, and the session data is obtained from the cookie when the request comes in. This method does not require any storage system, and does not appear to read and write session data caused by network operation delay and instability.

However, there are the following disadvantages:

* The cookie has a length limit, which affects the length of the session data.
Security Session data is stored on the server side, and this scenario is to have the session data transferred to the external network or client, so there is a security issue. However, the session data that is written to the cookie can be encrypted.
* Bandwidth consumption. Due to the addition of session data, bandwidth will of course increase a bit.
* Performance consumption. Each HTTP request and response with session data, for the Web server, in the same processing situation, the resulting output of the response less, the more supported concurrent requests.

2. How Web server session is replicated

Most application servers provide session copy functionality to enable clustering, which is provided by Tomcat, JBoss, and was. Session replication is the application service, which saves sessions data.

Advantages:

Rely on the application container to complete the session sharing, do not rely on the application, if the number of application services is not many, you can consider;

Disadvantages:

* Synchronizing session data brings both network overhead. As long as the session data changes, it needs to be synchronized to all machines, the more machines, the greater the network overhead.
* As each server saves session data, if the session data of the cluster is many, such as 900,000 people visiting the website, each machine used to save the session data is very serious.

3. Save session with a relational database

With MySQL, SQL Server and other databases to save the session, even if the server down the machine is OK, the session is still in.

Disadvantages:

* Procedures need to be customized;
* Database read/write overhead is not small per request (using a memory database can improve performance, and downtime loses data.) Available memory database with berkeleydb,mysql memory table);

4. Save session with NoSQL database

The use of Redis, MongoDB, memcached and other non-relational database to achieve session sharing. These non-relational database response data is very fast, and the number of supported accesses is also relatively large. System resource consumption is also relatively small. This is also the way many systems are used.

But there are drawbacks too:

* Read-write session introduces network operation, which brings delay and instability relative to local read-write session.

* If there is a problem with the session centralized service, it will affect the application.

5. Using Session Stick

In the case of a single machine, the session is saved on a single machine, the request is also to this machine, there will be no problem. After becoming more than one, if you can protect each request to the same service, it is the same as a single machine. This needs to be modified on the load Balancer device. This is the session Stick, which can also be problematic:

* If a server is down or restarted, the session data on this server is lost. If the session data also has login status information, then the user needs to reproduce the login.

* Load balancer to handle specific session-to-server mappings.

6. Use Terracotta to save session

Similar to memcached, but the data does not need to be serialized and is find-grained changes for better performance. The configuration is completely transparent to the original application, with almost no changes to the original program. and terracotta itself supports ha.

In summary, I personally recommend the use of 4th, 6 ways to solve the session sharing problem.

A common synchronization solution of session in Web cluster and its comparison