Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "how to solve distributed session problems". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

When session talks about session, I'm sure every programmer is familiar with it and has more or less used it in a project. The word session is actually an abstract concept, which is not as clearly defined as Cookie. When most programmers talk about session, they may refer to the session object in which the server stores data, for example, a program like this that stores user information in session after a successful login.

Session ["UserName"] = new User (); public class User {public int UserId {get; set;} public string UserName {get; set;}}

In computers, especially in network applications, session is defined as a "session", which can be regarded as a channel connection between the client and the server, and the request of the same user uses the same session session. In most applications, it is mainly used for user identification. Generally speaking, the server can record the status information of each user through session. Then let's talk about the most commonly used server-side session object.

Stand-alone session

Session is stored on the server side, which is a very important concept. This means that it takes up the server's memory, and it needs a release mechanism to ensure that the server's memory does not burst (for example, LRU).

At the beginning of the project, in order to get online quickly, there is only one server in many cases, and the session mechanism is generally used to record the login status of users. Please don't say that this is unreasonable, at least at the beginning of the project, it is the simplest and fastest solution. With the continuous iterative upgrading of the project and the continuous increase in the number of users, you will find that the stand-alone system has become the biggest performance bottleneck of the project. At this time, most architects will choose horizontal scaling solutions.

In fact, in the final analysis, the improvement of system performance revolves around the word "sub-database". Whether it is the sub-database and sub-table of the database, or the rising micro-services, it is always segmented around a field.

When the session mechanism of a stand-alone machine is expanded horizontally, it is faced with a problem that must be solved: how to solve the affinity (stickiness) of session?

Distributed session

If a stand-alone system is extended to a distributed system, it will be faced with the choice of AP and CP in the distributed CAP theory.

When it comes to the consistency of distributed session, it is mainly to solve the affinity of user session. How can the request of the same user reach the server that correctly stores session information?

Session replication

The initial solution is to use the session replication scheme, and the overall process is very simple: suppose there are three servers now, and when a session is created on one of the servers, the session is replicated to the other two servers at the same time. In this way, no matter which server the user's request arrives at, there will be corresponding session data.

The advantage of this scheme is that the server can be expanded at any level, and each server retains all the session information. When joining a server, you only need to copy all the session information. But the disadvantages are more obvious.

All the session information is stored on each server, and the resources occupied by the server are greatly increased.

Session synchronization needs to take up network bandwidth, the most important thing is that if the asynchronous replication method is used, the data will be temporarily inconsistent, which may lead to user access failure.

The session replication scheme is now rarely used.

Load balancing scheme

When a server is expanded to multiple servers, the most commonly used solution is to add a load balancer at the entrance of the traffic. The general deployment diagram looks like this.

Image

If the load balancer can use some means to achieve the stickiness of session, it can achieve distributed session. At present, the mainstream nginx can fix the requests of the same IP to a server according to the "hash_ip" algorithm, so that the session requests from the same ip are always requested to the same server.

This method is much better than session synchronization, each server only stores the corresponding session data, which greatly saves memory resources, and there is no data synchronization process between servers. When a new server joins, you only need to modify the configuration of the load balancer, which is convenient to support server horizontal scaling. However, there are also some shortcomings at the same time.

Server restart means that the corresponding session information is lost, which is not allowed in some important business scenarios

The horizontal expansion of the server needs to modify the configuration of the load balancer, which may lead to the redistribution of the previous session, which will cause some users not to route to the correct session.

Session stripping

Now the more widely used distributed session technology is to completely split the session data from the business server and store it separately in other external devices, which can use master-slave or master-slave mode, or even cluster mode to achieve high availability. For example, the most commonly used solution is to store session data in redis. Although it takes a certain amount of network time to read and write session data from redis, it is acceptable for general applications.

The advantage of this scheme is that the overall architecture is clearer and more flexible, and the overall scalability of the application server no longer has to consider the impact of session, while the problems of session are transferred to external devices, which can usually use memory NOSql to solve performance problems, and these external devices generally have corresponding distributed clustering solutions, such as redis. Master-slave or sentinel mode or even clustering can be used to provide larger data support capabilities.

Actor model

The Actor model is more elegant to solve this kind of user stickiness problem, and it comes with object recognition function. In short, the request of the same key can always reach the correct actor instance. Isn't that what we want? And the actor model can deal with concurrency without locking, so why doesn't anyone use it? And the acotr model can be used in the form of in-process cache, which is much lower than the network latency of requesting LAN redis.

This is the end of "how to solve the distributed session problem". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.