Session Sharing Solutions in Distributed Environments: Nginx ip_hash, Tomcat Replication, Redis Cache, and Cookie

As internet companies adopt micro‑services and distributed deployments, a single project may run on multiple server clusters, leading to session consistency problems when a user logs in.

When Nginx reverse proxies requests, the user's session ID is stored in the JVM of the server that handled the request; subsequent calls to other servers may miss the session, forcing the user to log in again.

Solution 1: Nginx ip_hash Load Balancing

ip_hash hashes the client IP to a specific backend server, ensuring that all requests from the same IP are routed to the same instance, thus keeping the session on the same server.

Implementation example (modify nginx.conf according to your available servers):

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;
    }
}

The diagram below shows the pros and cons of this approach.

Solution 2: Tomcat Session Replication

This method copies the generated session ID to all Tomcat nodes, ensuring that any server can retrieve the session without requiring the user to log in again.

Implementation details and workflow are illustrated in the following diagram.

Solution 3: Centralized Session Cache with Redis

Store each session ID in Redis and set an expiration time; all application instances read/write the session from Redis, eliminating repeated logins.

The code implementation flow is shown in the diagram below.

Solution 4: Cookie‑Based Session Sharing

Place the session identifier in a cookie so that every request automatically includes it, ensuring session continuity across distributed services.