First indicate the source: After reading the official account article of Java Zhiyin, I summarized it a little. (invasion and deletion)
1. Session concept:
At this stage, the website requires software to have a memory function for a transaction, which is often referred to as the state. The technical core of implementing web applications, http protocol, is a stateless protocol. In order to maintain the state of web application development, there are two technologies for maintaining the state of http links: one is cookie technology, and the other is session technology.
Cookie technology is a client-side solution (there are better alternatives after HTML5). Its main feature is that the special information sent by the server to the client is stored in the client in the form of text, and then the client sends each time to the server. This information will be included with all requests. Specific example: The client sends an HTTP request, provides some identity information such as username and submits it to the server; then the server returns the corresponding data and sends back the identity information (stored in the HTTP corresponding header Response Header); the client receives the response After the response is returned, the browser will save the information to a specific unified location; then when the client wants to send a request to the server, it will automatically send the corresponding cookie information (identity information) to the server again. The cookie information Stored in the HTTP request header (Request Header). In order to avoid repeated and cumbersome input, the "remember password" in the browser is implemented in this way.
The session technology is a server-side solution that saves the state through the server. We can call a series of actions of the server and the client browser as a Session, and the Session is the storage space opened up by the server for the client, and the information saved in it is to save the state.
So how to use session? Different programming languages create sessions in different ways, and the general principle of Java is this, created by calling the getSession() method of HttpServletRequest. After a successful session is created, the server will create something called Session id. This Session id is unique. Its function is that when the client sends a request again, it will carry this Session id to retrieve the corresponding Session on the server side. After the Session is created, you can call the relevant methods to add relevant content to the Session. These contents are saved on the server, and the Session id will be sent to the client to save, so that the user state will be saved.
Both cookie and session are methods of saving state. The main difference is that cookies are stored on the client side, and sessions are stored on the server side. However, the implementation of the session on the server side is dependent on the cookie on the client side. The session id mentioned earlier The container that is saved is the client's cookie. If cookies are disabled in your browser, cookies are also unavailable in most cases.
2. Session implementation principle:
All java web containers implement the session mechanism, and their logical ideas are the same. Tomcat is one of the most commonly used containers. Let's take a look at its session implementation mechanism.
The implementation package of session in Tomcat is in org.apache.catalina.session, while the package that provides the calling interface to the outside world is in HttpSession under javax.servlet.http. The StandardSession in the implementation package is the standard implementation provided by Tomcat. Tomcat also does not allow users to directly operate the StandardSession, but provides a StandardSessionFacade class. The specific component of the Tomcat container that operates the session is the servlet, and the servlet operates the session through the StandardSessionFacade, thereby preventing the security problems caused by directly operating the StandardSession. (StandardSessionFacad uses the Facad appearance pattern in the design pattern, and the appearance pattern enables the decoupling of different logic layers).
There is a Manager class in the implementation class, which is used to manage the creation and destruction of sessions. ManagerBase is the base class of all session management tool classes. It is an abstract class. Classes that implement the management function of session management must inherit this method. . One of the protected special methods is the method that creates the sessionId value. (The generation mechanism of Tomcat's sessionId value is a random number plus time plus the id value of the JVM, and the id value of different JVMs is certain). The StandardManager class is the default session management implementation class in the Tomcat container. It stores the session information in the memory of the server where the Web container is located.
3. Problems caused by session
The session mechanism is introduced to make up for the stateless characteristics of the http protocol. The server will occupy a certain amount of memory and cpu to handle the computational overhead of storing and processing sessions, which will lead to low concurrent connections of the web container (tomcat's official documentation shows the default number of connections). is 200). The more common solution is to add a static resource server in front of the web container in the production environment. The static resource server does not have the function of dealing with the stateless problem of http, and it will not give up memory and cpu computing resources to handle functions such as sessions. These memory and cpu can handle each http request more efficiently, thus increasing the number of concurrent connections. So, we can have requests that do not have state preservation requirements processed in the static server, and state preservation requirements that are processed in the web container. Improve the operating efficiency of the website.
Another problem is that in order to improve security and concurrency, Internet companies often deploy more than two servers on the server side. The services provided by multiple servers are equivalent, but there will definitely be different servers on the server. web container, resulting in different sessionId values generated by sessions in the web container. This will result in that the session saved in the A server will not be recognized by the B server. When the client sends a request again, if the B server receives it, the previously saved information will not be found. The solution is to synchronize the session between the two web containers, but this operation consumes a lot of system resources. When the traffic increases, it will seriously affect the efficiency and stability of the website.
Of course, you can also use a load balancing device before distributing the service to the server. The device can intercept the session id for judgment and distribution, but this will cause the system to become a single-point system. If a web container hangs up, the corresponding request also cannot be executed. And this practice interferes with the fairness of distribution. Large Internet companies will have the problem of session synchronization across sites, and the current single sign-on (SSO) solution is used, but it still cannot escape the problem of session sharing across sites.
To sum up, there are two problems in the session that need to be solved:
- The storage of the session should be independent of the web container and the server where the web container is deployed;
- How to perform efficient session synchronization.
The best choice when storing session data in memory, because the operation mode of hard disk is IO operation, and the efficiency of IO operation is much less than that of operating memory data. Therefore, the best solution is to use distributed caching technologies, such as memcached and redis. The independent storage of session information is also a way to solve the problem of session synchronization. Share two reference URLs:
Click to open the link : Solution using memcache;
Click to open the link : Implementing a distributed session scheme using zookeeper.