Synchronization and control of sessions used frequently in web clusters

with the function of the site more and more, the user volume is more and more large, the single node mode has been seriously unable to support the normal operation of the whole system, light user page access to ask time more and more slowly. Will cause the entire system to become 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., but also in a distributed way to the system according to the function of splitting into a very large number of systems, also some based on the region

Different from the network to achieve access to different nodes deployed systems. There are large-scale high-flow, high-load systems to load balance, distributed and based on the region, network and other methods are integrated to achieve the normal implementation of the system.

The use of Load balancer software is a more popular way to take now. However, the use of load balancing software will face the session synchronization problem.

Here are a few ways to solve this problem.

1. How to Clientcookie encryption

The session data is stored in a cookie when the request comes in. Gets the session data from the cookie. Such a way does not need to be whatever the storage system. There is no network operation delay and instability caused by read-write session data.

But there are the following disadvantages:

* The cookie has a length limit, which affects the length of the session data.

Security

Session data is originally stored on the server side, and this method is to transfer the session data to the external network or client. So there will be security issues. Only the session data that is written to the cookie can be encrypted.

* Bandwidth consumption. Because the session data is added. Bandwidth will of course add a bit.
* Performance consumption. Each HTTP request and response comes with session data. For webserver, the less output a response results in the same processing situation, the more concurrent requests are supported.

2. How Web server session is replicated

Most application servers provide session replication functionality to implement a cluster. This functionality is provided by Tomcat, JBoss, and was. Session replication is every app service. Sessions session data are saved.

Strengths:

The session is shared by the application container and is not dependent on the application. Assuming that the number of application services is not very large, can be considered.

Disadvantages:

* Synchronizing session data brings both network overhead.

Just to change the session data, you need to synchronize to all machines, the more machines, the greater the network overhead.
* Because each server holds session data, it is assumed that there is a lot of session data for the cluster. For example, 900,000 people are visiting the site. The content of each machine used to hold 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 visits is also larger. System resource consumption is also less. This is also the way that very many systems are used.

But there are drawbacks too:

* Read-write session introduces network operation. Compared with the local read-write session, it brings delay and instability.

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

5. Using Session Stick

In a stand-alone situation. Session saved on a single machine, the request is also to this machine, there will be no problem. After becoming more than one, assume that each request can be guaranteed to the same service. That's the same as a single machine. This needs to be changed on the load balancer device. This is the session Stick. There are also problems in this way:

* Assume that a server is down or restarted. Then the session data on this server is lost. Assume that the session data also has login status information. Then the user needs to reproduce the login.

* Load Balancer to process detailed session-to-server mappings.

6. Use Terracotta to save session

Similar to memcached, but data does not need to be serialized. And it's find-grained changes. Better performance.

The configuration is completely transparent to the original application, and the original program almost does not have to do whatever changes. and terracotta itself supports ha.

Sum up. I personally recommend using the 4th, 6 ways to solve the session sharing problem.

Synchronization and control of sessions used frequently in web clusters