How to Share Sessions Across Distributed Servers: Nginx, Tomcat, Redis, and Cookie Solutions

When a micro‑service or distributed system deploys across multiple server clusters, a user's session may be stored only on the server that initially handled the request, causing repeated logins if subsequent requests are routed to other servers. Sharing sessions across all nodes is therefore essential.

Common Nginx reverse‑proxy strategies

Round‑robin

Weighted ratio

ip_hash

Custom strategies

Solution 1: Nginx ip_hash load balancing

Requests are assigned to a server based on the hash of the client IP, ensuring that the same client consistently reaches the same backend node.

Configuration example:

upstream backend {
    ip_hash;
    server 192.168.128.1:8080;
    server 192.168.128.2:8080;
    server 192.168.128.3:8080 down;
    server 192.168.128.4:8080 down;
}
server {
    listen 8081;
    server_name test.csdn.net;
    root /home/system/test.csdn.net/test;
    location ^~ /Upload/upload {
        proxy_pass http://backend;
    }
}

Advantages and disadvantages are illustrated below:

Solution 2: Tomcat session replication

This approach copies the generated session ID to all servers in the cluster, so any server can retrieve the session without forcing the user to log in again.

Implementation details (code diagram) are shown below:

Pros and cons of session replication:

Solution 3: Redis‑based unified session cache

Each request's session ID is stored in Redis with an expiration time, allowing any server to retrieve the session while it remains valid.

Sample configuration diagram:

Advantages and disadvantages of using Redis for session sharing:

Solution 4: Cookie‑based session sharing

By storing the session identifier in a cookie, every request automatically carries the session information, eliminating the need for additional server‑side synchronization.

Reference: NetEase Cloud Classroom Source: blog.csdn.net/qq_36520235/article/details/87830929