Distributed Consistent Session Solutions for Multi‑Node Web Applications

Afeng's company originally deployed a Tomcat‑based web management system on a single machine, requiring users to log in before accessing any functionality.

As usage grew, a second server was added and Nginx was placed as a reverse proxy using its default round‑robin load‑balancing strategy, which caused users to be redirected between Tomcat1 and Tomcat2.

The problem manifested as users being forced to log in repeatedly because the session created on one Tomcat instance was not visible to the other.

Distributed Consistent Session is needed. Four common solutions are presented:

Session Replication

Tomcat can be configured to copy session data from one instance to another, keeping the sessions synchronized.

Configuration examples exist online; they are omitted here.

Drawbacks: consumes internal bandwidth, does not scale well with many nodes (potential network storm), and session data resides in memory, limiting horizontal scaling.

Session Front‑End Storage

Instead of storing session data on the server, user information is placed in a browser cookie and sent with each request.

Advantages: eliminates server‑side session replication.

Drawbacks: requires encryption to protect sensitive data, increases outbound bandwidth, and is limited by cookie size.

Sticky Sessions (IP Hash / Layer‑7 Hash)

Modify Nginx to use IP‑hash (layer‑4) or application‑level attributes (layer‑7) so that all requests from the same client are routed to the same Tomcat instance.

Advantages: simple configuration, no code changes.

Drawbacks: fails when all clients share a single external IP (e.g., corporate NAT), sessions are lost on Tomcat restart, and adding new nodes changes the hash distribution, causing some users to lose their sessions.

Backend Centralized Storage

Store session data in an external store such as Redis (or MySQL). Redis is preferred because sessions need expiration but not persistence.

Benefits: sessions survive Tomcat restarts and horizontal scaling; Redis can be clustered for high load.

Costs: each request incurs an extra Redis lookup, and application code must be modified to read/write sessions.

Conclusion

The four approaches are:

Session replication via Tomcat.

Client‑side cookie storage.

Sticky sessions using Nginx IP‑hash or layer‑7 hash.

Backend centralized storage (Redis).

The fourth method is recommended as the primary solution, with the sticky‑session approach serving as an interim step during migration.

Future work includes adopting spring‑session to simplify Redis‑based session management.