Session sharing in distributed architecture, also known as distributed Session consistency; Let’s take a look at the problems and solutions of Session sharing in distributed architecture.
The role of the Session
If you’ve done Web application development, you’re probably familiar with sessions; The server creates a session for each user and stores information about the user so that subsequent requests can be directed to the same context.
➤ ➤ ︎ for example
After a user logs in, the information stored in the Session will always be saved when the user switches to the page.
If the user does not have a Session, the server creates a Session object and does not terminate the Session until the Session expires or terminates.
Session issues in distributed architectures
➤ ︎ configure your organization
In the days of singleton servers, sessions were stored directly on the server, were no problem, and were easy to implement.
– Distributed Architecture
However, with the popularity of distributed architecture, a single server can no longer meet the needs of the system. The system is usually deployed on multiple servers, and the requests are distributed to one of the servers through load balancing.
Therefore, it is very likely that the first request to access server A creates A Session, but the second access to server B, in this case, there will be no Session;
Therefore, Session sharing becomes a big problem in distributed architectures.
The solution
1. Don’t have sessions
You may think that I said nonsense, but it is true that in some scenarios, it is possible to have no Session. In fact, in many interface systems, stateless service is advocated; That is, each interface access is independent of the Session, independent of the previous interface access;
2. Save the cookies
Session can be stored in cookies, but the disadvantages are also obvious, for example, each request has to carry the Session, data stored in the client local, it is risky;
3. The Session synchronization
Session synchronization between servers ensures that all Session information is available on each server. However, when a large number of servers are deployed, synchronization may be delayed or even fail.
4. IP binding policies
Using THE IP binding policy in Nginx (or other complex balancing hardware and software), the same IP address can only be accessed on the same machine, but this loses the significance of load balancing, when the failure of a server, will affect the use of a group of users, a great risk;
5. Use Redis for storage
Our current system stores sessions in Redis. Although it becomes architecturally complex and requires more access to Redis, the benefits of this solution are also great:
- Realizing Session sharing;
- Horizontal scaling (adding Redis servers);
- The Session is not lost when the server restarts (note the Session refresh/invalidation mechanism in Redis).
- It can be shared not only across server sessions, but also across platforms (e.g. web and APP).
Uncle will point code | article “original”
