Before discussing the cross domain sharing of session, we should first understand what session has done and has not done

HTTP is stateless, that is to say, the server does not know who has visited it, but sometimes we need to keep this state. For example, if the user logs in every time, the user experience is really bad. Session solves this problem. It maintains the user login information on the server and generates a jsessionid for the customer The client will take this jsession ID with it the next time it visits the server, and the server will search the user information according to this ID. Of course, the disadvantages of session are also obvious. Session exists in the memory of the server. If there are too many sessions, the performance of the server will be affected. Because session is only in one server, when there are multiple servers, accessing other servers will definitely fail.

After making clear what session does and its defects, it is much easier to solve the problems existing in session. Let me briefly talk about five solutions

Session stickysession copy session centralized storage cookietoken

Session sticky: it means that requests from the same client will fall on the same server, because they will not fall on other servers, so cross domain problems will not occur. But the disadvantage of this scheme is very obvious, that is, no matter what algorithm is used, the user will decide which server the user’s request falls on, which may cause a single point of pressure, and if a server has problems, it may cause people in an area to be unable to access

Session replication: refers to the synchronization of session information between servers, that is, all session information is saved on each server. The disadvantages of doing so are also very obvious. As mentioned above, session is stored in memory, which will seriously affect the performance of the server. Of course, you can also store it in the database, but it will greatly affect the response speed. Another disadvantage is that when the traffic is too large, it will cause a lot of network overhead due to the problem of mutual synchronization

Session centralized storage: it refers to the centralized storage of sessions in a third-party server, which can be redis, database or other things. When you need to access it, go to this server. This also has some disadvantages. First of all, it is a single point problem. If the server goes down, all services are unavailable. Therefore, it is necessary to build a cluster here, which will waste server resources. Another point is that every time you verify, you need to check with this server, which will increase the network overhead and reduce the access speed

Cookie: the state information is no longer saved in the server, but in the client. Every time the client visits the server, it brings the information to the server. However, cookies also have many problems. The most concerned problem is security. Because information is stored on the client, it is easy to be stolen and tampered with. Of course, there are solutions to these security problems. This is not the main reason for restricting cookies. The real reason for restricting cookies is that many devices do not support * * cookies

Token: similar to cookie, token is maintained by client, and information is stored in client, which is platform independent. A token is essentially a string given by the server to the client, which contains some authentication information. It is equivalent to an identity token. You can get its service with this token. Compared with cookie, token is more flexible and can be generated anywhere. The permission system based on token is very easy to implement

Of course, the above five solutions are not the only ones. I just listed a few representative ones.

Solutions are used to solve problems. There is no good saying about the above solutions. Only the right one is the best.