Distributed session management of large Web sites

Web applications deployed by single-machine services are no longer supported as the site becomes more functional and user-ready. This time, it is necessary to optimize or adjust the current architecture, how to optimize, or optimize the first part, depending on the specific situation of the site, not always a routine.

If according to the use of information, the database pressure, you can first facilities read and write separation, sub-database sub-table, is vertical division (can be easily understood as a business function division), or horizontal division (such as user table data volume, you can according to a certain rules of the table design, table structure is still the same). If the Web application server is under pressure, you can add a service deployment application that changes from a single service to a cluster. After becoming a cluster, the user visits the website, in the end is to choose which server? This requires a load-balancing device to be added to the application server before it can be resolved. It is also a bit of a session management problem, which will be explained in detail next.

The specific question

When an HTTP request with a session representation is to the Web server, the requirement finds the session data during the processing of the request. The problem is that the session is stored on a single machine. Suppose we have application A and application B, and now a user visits the site for the first time, the session data is saved in app a. If we do not handle, how to ensure that the next request to apply each time to application a? If you request to application B, you will find that there is no session data for this user, which is absolutely intolerable.

Solution Solutions

The solution has session stick,session replication, session centralized management, cookie-based management, below one by one instructions.

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 goes down or restarts, 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 Balancing to handle specific session-to-server mappings.

Session Copy

The session copy as the name implies, is each application service, all the sessions are saved data, the general application container is supported. Compared to session stick, Sessioon replication does not require much load balancing. But there are drawbacks to this scheme:

• 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.

• Because each server saves session data, if the session data of the cluster is many, for example, 900,000 people visit the website, each machine used to save the session data is very serious.

This is the session replication, the solution is done by the application container, do not rely on the application, if the number of application services is not many, you can consider.

Session Centralized Management

This is also very good understanding, plus a service, specifically to manage the session data, each application service from the dedicated Session management service to take sessions data. You can use databases, NoSQL databases, and so on. Compared with session replication, the memory usage of each application service is reduced, and the network overhead caused by the session is synchronized. But there are drawbacks:

• The read-write session introduces network operation, which brings delay and instability relative to the local read-write session.

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

Cookie-based management

The last one is based on cookie management, where we store the session data in a cookie and then request it to retrieve the session data from the cookie. Compared with centralized management, this scheme does not depend on external storage system, and reads and writes the network operation delay and instability caused by the session data. But there are still drawbacks:

• 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 comes with session data, and for a Web server, the less output a response results in the same processing, the more concurrent requests are supported.

Summarize

These 4 scenarios are available, I prefer to use session centralized management, but these 4 kinds of programs have their pros and cons, need to make the right choice according to the actual situation.

Distributed session management of large Web sites