Interviewer psychoanalysis
The interviewer asked you a bunch of questions about how dubbo works. You can play Dubbo to make a single system into a distributed system, and then distributed comes a bunch of problems. The biggest problems are distributed transactions, idemidemality of interfaces, distributed locks, and finally distributed sessions.
Of course, the problems in distributed systems are more than that. They are numerous and complex. Here are just a few of the common questions that are often asked during interviews.
Analysis of interview questions
What is the session? The browser has a cookie, and that cookie stays there for a certain amount of time, and then every time you send a request, you put a special JsessionID cookie, and based on that, you can maintain a session field on the server, and you can put some data in it.
Normally if you don’t close the browser and the cookie is still there, then the session is still there, but if the cookie is gone, the session is gone. You see shopping carts and things like that, and login status saving and things like that.
I’m not going to go into this, but anyone who knows Java should know this.
It’s ok to play sessions like this on a monolithic system, but if you’re on a distributed system, where do you maintain the session state for so many services?
In fact, there are many methods, but the common ones are as follows:
Don’t use sessions at all
Use the JWT Token to store the user’s identity and then retrieve other information from the database or cache. It doesn’t matter which server the request is assigned to.
tomcat + redis
This is actually quite convenient, which is to use the session code, as before, based on tomcat’s native session support, and then use something called Tomcat RedisSessionManager, Just have all our Tomcat deployed store session data to Redis.
In the Tomcat configuration file:
Then specify redis host and port.
:26379,:26379,:26379″maxInactiveInterval=”60″/>
You can also use this method to save session data based on the Redis high availability cluster supported by Redis Sentinel, which is ok.
spring session + redis
The second option is recoupled to the Tomcat container. If I were to migrate the Web container to Jetty, would I have to configure Jetty all over again?
The tomcat + Redis approach works well, but it relies heavily on the Web container and is hard to port to other Web containers, especially if you switch tech stacks. What about spring Cloud or Spring Boot?
So the best solution for now is a Java-based one-stop shop solution, known as Spring. Spring basically contracts most of the frameworks we need to use, spirng Cloud does the microservices and Spring Boot does the scaffolding, so using Sping Session is a good choice.
Configure in POM.xml:
Configure in the Spring configuration file:
Configure in web.xml:
Sample code:
Sping Session is configured to store session data based on Redis, and then a Spring Session filter is configured. All session-related operations will be handled by Spring Session. Then in the code, we use the native session operation, which is directly based on Spring sesion to fetch data from Redis.
There are many ways to implement distributed sessions, but I’m only talking about the common ones. Tomcat + Redis was used in the early days, but was re-coupled to Tomcat; In recent years, this has been done through Spring Session.