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

In micro‑service and distributed deployments, a user's session may be stored on one server while subsequent requests are routed to other servers, causing repeated logins and a poor user experience; therefore, session sharing becomes essential.

Solution 1: Nginx ip_hash Load Balancing

By hashing the client IP address to select a specific backend server, Nginx ensures that a user’s requests are consistently routed to the same server, keeping the session in that server’s JVM memory.

Implementation: Modify nginx.conf to define an upstream with ip_hash and list the backend 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 approach is simple but ties session affinity to client IP, which may not work well with NAT or mobile users.

Solution 2: Tomcat Session Replication

This method copies the generated session ID to all Tomcat nodes in the cluster, ensuring that any server can retrieve the session data without forcing the user to re‑authenticate.

Advantages include true session failover; disadvantages involve increased network traffic and memory consumption.

Solution 3: Redis Centralized Session Cache

Each server stores the session ID and related data in a Redis instance, which acts as a shared, fast, in‑memory store with configurable expiration, eliminating the need for local session storage.

Implementation: Configure the web application to use Redis as the session manager (e.g., via Spring Session or Tomcat’s RedisManager).

Pros: high performance, scalability, and centralized control; cons: adds a dependency on Redis and requires proper clustering for high availability.

Solution 4: Cookie‑Based Session Sharing

By storing the session identifier in a client‑side cookie, every request automatically carries the session token, allowing any backend server to retrieve the session from a shared store (e.g., Redis) without additional server‑side replication.

While simple, this approach must handle security concerns such as cookie theft and ensure that the session data itself remains protected.