How Nginx Load Balancing Powers a High‑Availability Tomcat Cluster

A Tomcat cluster consists of multiple machines that provide parallel services; if any server fails, the others continue serving users without interruption.

Nginx, a widely used reverse‑proxy, can be extended with custom modules to forward requests and perform load balancing; for high availability, a dual‑machine hot‑standby setup is also recommended.

1. Load Balancing Only (No Session Sharing)

If the service only delivers static pages without per‑user sessions or authentication, configuring Nginx’s load‑balancing strategy is sufficient.

Nginx Load‑Balancing Strategies

Round‑robin (default) : Requests are distributed sequentially across backend servers; failed servers are automatically excluded.

ip_hash : Requests are assigned based on the hash of the client IP, ensuring a client always reaches the same backend.

fair : Requests are sent to the backend with the shortest response time.

url_hash : Requests are routed according to a hash of the URL, useful when backends act as caches.

2. When Sessions Are Involved

For applications that store user sessions, authentication data, or temporary information, Tomcat session sharing becomes necessary. Two main approaches exist:

Tomcat’s built‑in multicast replication : Configuring several Tomcat files enables session copying across nodes, but this method can be unreliable and may cause session loss.

Third‑party session stores : Common solutions include integrating Memcached or Redis. Redis offers high‑performance access, though its clustering feature is still evolving, requiring additional research to avoid single‑point failures.

Conclusion : The need for session sharing is tightly linked to the chosen Nginx load‑balancing method. Round‑robin requires session replication because clients may hit any server, whereas ip_hash can avoid it—though ip_hash has its own limitations, such as issues with multiple clients sharing the same external IP.

Recently, an Nginx sticky‑session module (similar to session stickiness) has emerged as a fifth strategy. It writes a

route

parameter into a client cookie, ensuring subsequent requests consistently reach the same backend, effectively addressing session‑sharing concerns.