Nginx sticky session

  nginx

The load balancing scheduler allows users not to care about the back-end servers to the greatest extent. We know that when RR scheduling policy is adopted, even multiple requests for the same content by the same user may be forwarded to different back-end servers, which sounds fine, but sometimes it may bring some problems.
After a certain back-end server has enabled Session to locally save some user data, the next time the user’s request is forwarded to other back-end servers, the previous Session data cannot be accessed.
The back-end server implements a certain dynamic content cache, and the irregular forwarding makes the utilization rate of these caches decrease.
How to solve these problems? On the surface, what we need to do is to adjust the scheduling policy so that all requests of users in a session cycle are always forwarded to a specific back-end server. This mechanism is also called Sticky Sessions. The key to realize this mechanism lies in how to design a persistent scheduling algorithm.
Since the scheduler should be able to identify the user, it is most appropriate to use the user’s IP address as the identification mark. Some reverse proxy servers support this, such as Nginx and HAProxy, which can Hash the user’s IP address to different back-end servers.
For Nginx, you only need to declare ip_hash in upstream, as follows:
upstream backend {

ip_hash;
server 10.0.1.200:80;
server 10.0.1.201:80;

}

In addition, you can also use Cookies mechanism to design a persistence algorithm. For example, the scheduler appends the number of a back-end server to Cookies written to the user, so that the scheduler can know which back-end server should be forwarded in the user’s subsequent request. In this way, every user can be tracked more finely. Imagine that when many users are hiding behind a public IP address, the persistence algorithm using Cookies will be more effective.
We have already implemented sticky sessions, but as a result, sticky sessions may more or less destroy the equilibrium strategy. At least dynamic strategies such as weight distribution can no longer work. We cannot turn a blind eye to this, or the previous efforts will soon be wasted.
Of course, the crux of the problem lies in whether we should accommodate the special needs of the system by implementing sticky conversations. After weighing the costs, do you think it is worth it? The most crucial question is whether the two problems mentioned above can be fundamentally avoided. If so, it is worth considering.
In fact, it is really unwise to save Session data and localized cache on the back-end server. It makes the back-end server appear too personalized to fit the whole system. If allowed, we should try our best to avoid such design, such as adopting distributed Session or distributed cache, etc., so that the application of the back-end server is as independent of the local as possible and can better adapt to the environment.