Last article SpringSession: Integrating SpringBoot introduced how to integrate SpringSession in SpringBoot, the whole process is very simple, but also a simple analysis of the role of SpringSession principle. After the previous practice, this article mainly analyzes the principle of SpringSession.
1. Start with the session consistency scheme
To learn more about sessions and cookies, you can refer to my previous post about sessions and cookies.
Session, as a mechanism used by the server to record the client status, is transparent to the client. However, the Session still needs to be supported by the client browser. As we all know, THE HTTP protocol is stateless, and the Session cannot determine whether it is the same client based on the HTTP connection. Therefore, the server needs to send an identification id (sessionId) to the client browser, which is completed through the Cookie mechanism.
1.1 Origin of session consistency problems
When a user accesses our Servlet for the first time, the application server creates a separate Session for the user and stores it in memory. This situation can be satisfied in a single application server scenario (one of the disadvantages of this is the stress on the server caused by memory usage that is not discussed here). In a cluster scenario, this mechanism presents problems:
1.1.1. Single-node scenario
Because it is an application server, every request from the user is processed by this machine, so there is no session sharing problem.
1.1.2 Cluster scenario
Suppose there are now three machines in the cluster (top to bottom: A->B->C). When the current user initiates access for the first time, the request is allocated to machine A for processing, and the Session data is written into the memory of machine A. When the next access is made, the request is processed by B, but B does not have any data in memory for the current user, so session inconsistency occurs.
1.2. Solution of Session consistency problem
In the current era of service-oriented and unitized applications, a simple memory Session can no longer meet our requirements. Then we need to find a solution to replace the current stand-alone memory storage implementation.
1.2.1 Implementation mechanism based on IP-hash
In 1.1.2, session inconsistencies occurred because there was no way to know which machine the request would be assigned to. If we could solve the problem of each user’s request being fixed to a certain machine, then the above problem would not exist. Ip-hash is one such solution. By hashing the client IP address of the request and mapping the result to a specific machine, the request can be assigned to a certain machine, effectively avoiding session consistency problems.
The benefits of this scheme are:
- No need to modify any application code, 0 intrusion.
- High security, does not rely on the risk of other three-party cache framework
- The cost is low
However, the problem is also obvious. In fact, this approach avoids the occurrence of session consistency problem, rather than the solution to the session consistency problem. Main issues:
- Based on the application memory, the application server will put a certain amount of pressure
- Service restart causes
session
Data loss - It’s not good for horizontal scaling, and horizontal scaling can be lost
session
- There are high single-point loads where most requests pass through
HASH
The calculation is followed by a call to the same machine while the other machines are idle.
1.2.2 session replication
In this mode, the application server creates a session and sends the session to other application servers in the multicast address. This method is more reliable than ip-hash:
- Again, no business code changes are required
- Can adapt to multiple load strategies
- The machine is not afraid of loss after restart or downtime, because there are redundant backup
But there are big problems with this approach:
- The first is synchronization between servers
session
It takes up some network resources, and at the same timesession
There is a delay in synchronizing between different machines. - Or based on memory storage, limited to the impact of machine memory capacity, horizontal expansion ability is poor
- Server memory needs to be stored on other machines
session
Data, memory consumption will increase as the size of the cluster increases, which may cause the machine to trigger frequentlyGC
.
1.2.3 Achieve centralized session management with the help of three-party cache framework
In both cases, the server manages the session itself, but the main problem is the impact on performance and memory. The principle of this approach is to host the session to three software (such as Redis) for unified management. This approach can effectively solve the performance, memory footprint and horizontal scaling problems. However, due to the introduction of three-party software, the implementation complexity, operation and maintenance costs will increase.
At present, most of the distributed session implementation schemes are based on this way. SpringSession is no exception.
2. Functional structure analysis of SpringSession
The Session consistency problem in distributed scenarios has been explained before, and several strategies to solve the Session consistency problem have been analyzed (a little rough, there are a lot of knowledge online). With that background in mind, let’s look at how SpringSession works.
2.1 introduction
Spring Session provides apis and implementations for managing user Session information, making it easier to support clustered sessions without depending on the solution of the application container. It also provides transparent integration:
- Allows application containers (
Tomcat
Etc.) in a neutral wayHttpSesseion
To support theheaders
Provided in thesession IDs
To use theRESTful API
. - Offer in receipt
WebSocket
Message time holdHTTP
The ability to survive a session - Allow substitution in an application container neutral manner
Spring WebFlux
的WebSession
.
Spring Session
2.2 module
Spring Session consists of four modules:
spring-session-core
: provides theSpring Session
Core functions andAPI
spring-session-data-redis
To:redis
As a storage mechanismSessionRepository
implementationspring-session-hazelcast
To:Hazelcast
As a storage mechanismSessionRepository
implementationspring-session-jdbc
: using a relational database as a storage mechanismSessionRepository
implementation
In general, the core API+ storage implementation; The screenshot of the engineering module is as follows:
2.3 Function Structure
SpringSession as a whole can be divided into three parts:
- For Web layer processing, including request rewriting, adding custom filter to filter chain, cookie processing, HTTP header processing and so on
- Common base encapsulation, such as top-level abstract interface definitions for storage classes, custom configurations, event handling, and so on.
- The storage part, which is actually the implementation of the common base encapsulation interface, provides a rich storage implementation, including REDis, memory storage, JDBC, etc.
2.4 Multi-session support
Commonly used distributed sessions rely on cookies for implementation. However, in springsession there is a policy implementation that passes the session id based on headers. Prior to version 2.0.4, SpringSession supported multiple sessions for the same browser and website, but has since dropped support for sessions. For more information about multi-session support, see the official documentation for SpringSession.
summary
This paper briefly introduces several implementation strategies of distributed session. For distributed sessions, how to solve the consistency problem is the key. At present, most of the solutions I have seen are based on centralized session management with the help of three-party caching framework, including SpringSession introduced in this series of articles.
In addition to the introduction of distributed session consistency solution, as the second article of SpringSession, the functional modules of SpringSession are simply analyzed here, so as to facilitate the subsequent analysis of the source code.