Липкие сеансы и сохранение сеансов

Imagine you're shopping online and add items to your cart. If the website uses multiple servers, how does it remember your cart as you browse?

This is where sticky sessions come in! They ensure your requests consistently go to the same backend server.

Without sticky sessions, a load balancer might send each new request from your browser to a different server.

• Server A gets your login.
• Server B gets your "add to cart" request.
• Server C gets your "checkout" request.

Each server might not know about your session on the others, leading to a broken user experience.

Session persistence (or sticky sessions) is a mechanism that binds a user's entire session to a specific backend server.

Once a user establishes a session with a server, all subsequent requests from that user during the same session are sent to that exact server.

This is crucial for applications that store user-specific data in memory or local server storage.

Nginx provides a simple way to achieve sticky sessions using the ip_hash load balancing method.

The ip_hash directive uses the client's IP address to determine which backend server to send the request to. It's a deterministic method, meaning the same IP will always go to the same server.

Here's how you can configure Nginx to use ip_hash for your upstream servers:

When a client connects:

1. Nginx takes the client's IP address.
2. It computes a hash value from this IP.
3. This hash value is then used to select one of the backend servers from the upstream group.

As long as the client's IP address doesn't change, they will consistently be routed to the same server, ensuring session continuity.

While effective, ip_hash has limitations:

• Changing IPs: Mobile users often switch networks, getting new IPs. This breaks stickiness.
• NAT/Proxies: Multiple users behind a single NAT gateway or corporate proxy will appear as one IP, all going to the same backend.
• Server Failure: If a sticky server fails, all sessions tied to it are lost and users might be redirected to a new server, losing their context.

ip_hash is best suited for scenarios where:

• Clients have stable IP addresses (e.g., internal networks).
• Simplicity is preferred over perfect load distribution.
• Backend applications rely on in-memory session state and don't have shared session storage.

For more robust session management, consider shared session storage (like Redis) or more advanced load balancing methods (often in commercial Nginx Plus).

You've configured Nginx with ip_hash for your backend servers. A user connects, and their requests are consistently routed to backend1.example.com. What happens if this user's public IP address suddenly changes?

In this lesson, we learned about sticky sessions and session persistence, which are vital for maintaining user context across multiple requests.

We explored how Nginx's ip_hash directive provides a straightforward way to achieve this by routing requests from the same client IP to the same backend server.

We also discussed its limitations, especially with dynamic IP addresses and NAT environments. Keep these in mind when designing your load balancing strategy!