First, the introduction of the Session problem
During the evolution of the website, when our single application server can no longer handle many requests and responses, we will consider whether to build a server cluster. We have added a load balancing device to distribute requests and responses with a certain weight. We thought it was perfect! However, just like fixing bugs, if one bug is fixed, it is very likely that new bugs will be created.
When the new middle tier was introduced, we seemed to have solved the server's inability to handle more requests and responses due to its own performance issues. However, there is a very detailed problem here. Take the above figure as an example, every time the client opens a session, a session will be generated, representing a session between the current client and the application server, and a unique identifier - sessionId will be generated.
now imagine when you are surfing with your chrome, you open a tab , enter a url: at this time you generate a request object, this object carries your sessionid (identifying the session), along the blue line on the way, to the server on the left Go up, after the server on the left has finished processing, I will give you a response, and then your client (your chrome) will show you a result, you say: (⊙o⊙) Oh, the price of the mini skirt that I collected two days ago has dropped! buy buy buy! ! !
Then you submit the order, your request first arrives on the load balancing device, then it sends your request to a server in the application server cluster, now, the problem occurs here, the last time I had a session with the server When the first application server is used, but since I have not specified how the load balancing device should distribute the request, if the load balancing device sends your request to the second application server, but I am in this session The session is still on the first application server, (⊙o⊙)... Find something. . .
After typing so many words, I actually want to explain a problem. You have introduced a load balancing device, and you have to configure the load balancing device so that my same session falls on the same application server.
Second, how to ensure my Session
1,session sticky
Before there is no load balancing device, because we only have one application server, each of our requests falls on the same server, the session is also on this server, and each of our session requests is processed on this server. .
Following this simple idea, if we set up such rules on the load balancing device: let each request response be sent to the same server for processing by the load balancing device, so that our session can be guaranteed.
shortcoming:
1. In an application server cluster, if a web server goes down or restarts, the session on this machine will be lost. For example, if there is a user's login status in the session, the user will be prompted to make a request again. re-register.
2. The session identifier is the information of the application layer, so if the load balancing device wants to save the same session request to the same web server, it needs to parse the application layer, and the overhead is larger than that in the transport layer.
3. At this point, the load balancer becomes a stateful node. To save the mapping of sessions to specific web servers, compared with stateless nodes, the memory is larger and disaster recovery is more troublesome.
2，session replication
If you have done database read-write separation, you should know that when reading and writing is separated, you actually read the slave library and write to the master library, but the information of the master library will be updated to the slave library, regardless of the read and write time, we can The data of the task slave library and the master library are consistent, and this consistency is mainly achieved by synchronization.
When dealing with sessions, we can also adopt such a strategy. On the load balancing device, there is no need to do anything, and only stateless distribution is performed. Anyway, which server is distributed to, I have all the previous sessions.
shortcoming:
1. Synchronizing sessions causes network bandwidth overhead. As long as the session data changes, the data needs to be synchronized to other servers. The more machines there are, the greater the network overhead caused by synchronization.
2. Each web server needs to save all session information. If there is a lot of session data in the entire cluster, each application server will save a lot of session data, which takes up a lot of memory.
3. Centralized storage of session data
Since you don’t like synchronization, you should take out all session data and put it in a separate place, which can be a separate database or other distributed storage system. The front load balancer is still stateless forwarding, and the application server reads and writes the session every time. , all to the same place to pick up.
A recent project is like this. The load balancing uses nginx. Every time a user accesses, a sessionid is generated, and then the information in the session is serialized and stored in the Redis library. The application uses it through my redis . Access the module to access, after the session ends, delete session.
shortcoming:
1. Network operations are introduced to read and write session data. Compared with local data reading, the problem lies in the existence of delay and instability. However, considering that the communication between the application server and the session storage device occurs in the content, so, take it easy!
2. If the session storage is centralized, it is necessary to consider that when the session server has a problem, it will affect the use of our entire chain.
4，Cookie Based
If you don't want to introduce additional nodes to process the session, we can consider putting the session data in cookies, and carry it with each request and response. Every time the server needs to read and write the session, it only needs to be generated from the cookie.
shortcoming:
1. Cookie length limit: Because the length of data that a cookie can carry is limited, it also limits the length of the session to a certain extent.
2. Security: The session data is originally server data, and this solution allows the session data to go to the external network and the client, so there is a security problem. In actual operation, the session needs to be encrypted.
3. Bandwidth consumption
4. Performance: Each HTTP request and response carries session data. For the web server, under the same circumstances, the less the result output of the response, the more concurrent requests it supports.