Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "what are the implementation methods of distributed consistency Session". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Preface

Afan has a Web management system that uses Tomcat for deployment. As it is a background management system, all web pages need login authorization before the corresponding operation can be carried out.

At first, not many people used this system, and in order to save resources, the system was only deployed on a single machine. Later, as more and more people used it, the stand-alone machine was a little too much to handle, so A Fan decided to deploy another machine.

At this time, the backend system has two services, so we use Nginx as the reverse proxy. The overall architecture is as follows:

You should be familiar with this architecture diagram, and now the mainstream Web systems should be deployed in this way.

After some debugging, A Fan deployed the system to production in the dead of night. I thought there was nothing wrong, so I gave it to the test sister to start the test.

There is a big problem with this test! Test the little sister's feedback, after logging in, need to log in again after a while, the operation is like this several times.

A powder checked, the system application, the configuration of anything is not a problem, so what went wrong?

At this time, the team leader was just getting ready to get off work, when he saw that we had a problem here, so he came over to have a look. After a brief understanding of the basic situation, we quickly found the cause of the problem, then modified the configuration on the Nginx side, and rebooted to solve the problem.

Distributed consistent Session

After solving the problem, the team leader sat down and explained the cause of the problem to A Fan: distributed consistency Session.

Previously, after logging in, we will put the user login information in the Session. For each operation, the user first verifies whether the Session has user information, and if it does not exist, the user will be forced to log in first.

In the original architecture, we only have one application system, and all the operations are on one Tomcat, which is of course no problem.

But now we have deployed two systems, and because Nginx uses the default load balancing policy (polling), requests will be distributed to the back-end applications one by one in chronological order.

That is to say, after we log in to Tomcat1 at first, the user information is placed in the Session of Tomcat1. After a while, the request is distributed to Tomcat2 by Nginx. At this time, there is no user information in Session on Tomcat2, so you have to log in again.

In addition, because our system uses single sign-on, the Tomcat1 login information will be invalid after Tomcat2 login, so when Nginx distributes the traffic to Tomcat1, the user login information in Session has expired and has to log in again.

Knowing the problem, Ah Fan certainly wanted to know the solution, so the team leader taught Ah Fan four solutions to distributed consistency Session, and A Fan sorted it out for everyone:

Below, A Fan will explain the distributed consistency Session solution in the form of a dialogue between A Fan and the team leader.

Session replication

Team leader:

If user information exists on Tomcat1 Session at this time, but not on Tomcat2.

At this point, if we copy the Session of Tomcat1 to Tomcat2, and then Nginx forwards the request to Tomcat2, because Session exists in Tomcat2, there is no need to log in again.

The architecture diagram is as follows:

Consistent Session-Session replication

Tomcat Session copy of the configuration, there are more examples on the Internet, here A Fan is no longer posted, interested students can search on their own.

Ah Fan:

Yes, it's a good way. Tomcat supports this approach, we only need to modify the Tomcat configuration, we do not need to modify the application code.

Team leader:

That's right, but there are still many shortcomings in this approach.

First, Session replication transmission needs to occupy the bandwidth of the private network.

Second, there are only two machines in our example, and this replication performance is OK. But suppose we have N machines, then each copy has to be copied to NMel 1 machine, if there are many machines, it may cause a network storm, and the replication performance will decline exponentially.

Third, Tomcat needs to save all Session data, and the Session of this scheme is stored in memory and is easily limited by the total memory of the machine. We can't scale horizontally by adding machines, what we can do is to increase the machine memory. But the larger the memory of the machine, the price is really expensive!

Therefore, this scheme is not recommended.

Session front-end storage

Ah Fan:

Well, this plan is a little unreliable.

Hey, there it is! Our Session actually stores the user's information, so I don't store it in the Tomcat Session now. I take the information out and store it in the Cookie of the browser.

In this way, each user's browser stores its own Cookie information, and the server does not need to store it, which solves the defect of the Session replication scheme.

Then the user sends me this Cookie every time he requests, and I just judge that the user information in Cookie is not good.

The architecture diagram is as follows:

Consistent Session-Session front-end storage

Team leader, take a look at me:

Yes, your plan is really feasible.

However, if you use this scheme, you have to come up with an encryption scheme first.

User information is our sensitive data, so we can't let others steal or tamper with the data easily.

In addition to this, this scheme has to carry Cookie for transmission every request, which will take up the bandwidth of the external network. If the Cookie is too large, it will increase the cost of the network.

In addition, the size of the data we store is easily limited by Cookie.

So this is still not commonly used, but it is also a way of thinking.

I recommend the following two options.

Session stickiness (Sticky Sessions)

Team leader:

As you should have seen just now, I just made some changes to the configuration of Nginx, and then the problem was solved.

In fact, this is because I modified the default load balancing policy of Nginx to use IP Hash.

Nginx uses the requester's IP to do the Hash, and then distributes it to a machine, which ensures that all requests for the same IP fall on the same Tomcat.

The architecture diagram is as follows:

Session sticky-IP Hash

In this way, we use Nginx layer-4 load balancer. In fact, Nginx can also achieve layer-7 load balancing, that is, using some business attributes of Http protocol to do Hash, such as userId,loginId and so on.

The architecture diagram is as follows:

Consistent Session-Session stickiness-seven layers

Ah Fan:

This solution seems quite simple, we only need to modify the Nginx configuration, and there is no need to change the application configuration.

As long as the request source IP is random enough, the traffic on the two applications after the IP HASH will be random enough.

In addition, if the back of the two machines can not handle, we can also expand horizontally, plus the machine, as long as modify the Nginx configuration.

Team leader:

What you said is correct!

But have you ever thought that in the case of our company, everyone's export IP is the same? Then all our company's requests will only go to one machine, so our situation is tantamount to becoming a single point again.

In addition, if the Tomcat is restarted, this part of the Session will be lost because the Session is placed in memory, which causes these users to log in again.

Finally, if we temporarily add the machine, modify the Nginx configuration, and restart, Nginx will recalculate the Hash distribution request.

This situation will cause some users to reroute to a new machine and need to log in again because there is no Session.

However, there won't be many Tomcat restarts or new machines, so it's not a big problem, and the user experience is a little worse.

Today's solution to our problem will first use this.

But later, we will change it to the following way.

Back-end centralized storage

Team leader:

In all of the above ways, we store the Session in the application memory. As soon as the application machine is restarted, the Session will be lost.

To solve this problem, we save the Session separately and save it in Redis or MySQL.

However, since Session requires expiration and does not need to be persisted, I recommend using Redis to save it.

So the architecture looks like this:

Consistent Session-Session back-end storage

When we use this scheme, there is no risk of losing Session, of course, as long as there is no downtime for Redis.

In addition, if the application can be expanded horizontally in the later stage.

If the number of requests for the following applications is too large for a Redis, then we can actually do cluster expansion and route according to the cache Key.

Ah Fan:

Yes, yes, this is a good way.

Team leader:

Don't be happy too early, we have to pay a certain price to use this scheme.

First of all, we need to call Redis once for each request, which increases the overhead of the network.

In addition, the introduction of Redis, we need to make changes to the corresponding code, so the complexity becomes higher.

Therefore, this scheme has both advantages and disadvantages, of course, for our scenario, the advantages outweigh the disadvantages.

Ah Fan:

Yeah, it seems that way.

Team leader:

All right, it's so late, the problem is solved, let's go play a string, my treat!

Ah Fan:

Boss,?!

The team leader patted Ah Fan on the head:

I did not eat this meal for free. Next week, you will modify the current way and change it to the centralized storage mode of Session.

To give you a hint, you can use spring-session.

Ah Fan:

All right, cannibalism is short. I'll study it next week.

This is the end of the content of "what are the distributed consistent Session implementations". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.