This is the 10th day of my participation in Gwen Challenge

The concept of conversation

Session Session represents an interaction between the client and the server. This interaction can be continuous or intermittent. In the early Servlet era (JSP), once the user interacts with the server, the server Tomcat will create a session for the user, and at the same time, there will be a JsessionID in the front end, which will be carried every interaction. In this way, as long as the server receives the user request, it can get the JsessionID and find the corresponding session in memory according to the ID. After getting the session session, we can operate the session. During the lifetime of the session, we can assume that the user is still using the site. Once the session expires, we can assume that the user has left the site and stopped interacting with the site. The identity information of users is also determined by session, in which the information of different users can be saved.

@GetMapping("/setSession")
public Object setSession(HttpServletRequest request){
    HttpSession session = request.getSession();
    session.setAttribute("userInfo"."new user");
    session.getAttribute("userInfo");
    session.setMaxInactiveInterval(3600);
    // session.removeAttribute("userInfo");
	return "OK";
}
Copy the code

A more detailed introduction to sessions can be found in my previous JSP blog, JSP 3: Learning Sessions

Stateless session

HTTP requests are stateless. The user makes multiple requests to the server, and the server does not know that these requests are from the same user. This is stateless. Cookies were invented for stateful logging of users.

Common, ios and server interaction, Android and server interaction, front and back end separation, small program and server interaction, they all call the interface data by initiating HTTP, each interaction server will not get the state of the client, but we can deal with it through means, For example, each time a user initiates a request, it carries a userID or user-token. In this way, the server can obtain the corresponding data based on the user ID or token. Each user’s next request can be identified by the server as coming from the same user.

Stateful session

Once the user interacts with the server, there is a session. The session holds the user’s information, so the user is “stateful”. The server maintains a layer of relationship with each client, which is managed by the container (Tomcat). The session is stored in memory so that when different users access the server, their identity is known through the session. If the user no longer interacts with the server, the session disappears, ending its life cycle. In this way, each user actually has one session maintained, which is called a stateful session.

Scenario: The most used session in traditional or JSP projects, sessions exist to compensate for HTTP statelessness.

Note: Tomcat sessions can achieve state synchronization between multiple systems by means, but it takes a certain amount of time. Once multiple user requests are synchronized, they will wait. This is not advisable.

Why stateless sessions

Stateful sessions are stored in the server’s memory, and once there are too many user sessions, there will be a memory bottleneck. The stateless session can use media. The front end can use cookie(APP or small program can be put into the local cache) to save user ID or token, and the back end uses Redis. The corresponding user session can be put into Redis for management, so that the server where the application is deployed will not cause memory pressure. Users make HTP requests on the front end and carry AN ID or token. The server can identify the user based on the ID or token provided by the front end, which increases scalability.

Single Tomcat session

The session is created when the user accesses the server for the first time, and the JsessionID is set in a cookie. Each subsequent request carries the JsessionID to maintain the user’s state.

Static and static separation session

When the user requests the server, the front-end initiates an HTTP request without any state due to the separation of dynamic and static. When the user requests for the first time, we manually set a token and put it into redis as a user session, which is called Redis-session. And after the token is set, it is put into the front-end cookie (app or small program can be put into the local cache), so that in the subsequent interaction, the front-end only needs to pass the token to the back end, and the back end can identify who the user request comes from.

Clustered distributed system sessions

Cluster or distributed system is more, if two server nodes, respectively is AB system, they can be A cluster, also can be A distributed system, and A system user interaction at the beginning, so when the user state, we can save to redis, session information as A system, then the user’s request into the system, B Then THE session in system B will also be associated with Redis, so the session in system AB will be unified. Cookies, of course, are carried along with the user’s access. So this is actually a distributed session, using Redis to save the user’s state.