mod_cluster advantages over other httpd-based load balancers mod_jk and mod_proxy
Server-side load balance factor calculation
In contrast with traditional httpd-based load balancers, mod_cluster uses load balance factors calculated and provided by the application servers, rather than computing these in the proxy. Consequently, mod_cluster offers a more robust and accurate set of load metrics than is available from the proxy.
Dynamic configuration of httpd workers
Traditional httpd-based load balancers require explicit configuration of the workers available to a proxy.
Like mod_jk maintain the static worker list in worker.properties but mod-cluster allow dynamic worker list means whenever the user load increases you can add Application server nodes dynamically to balance the load. In mod_cluster, the bulk of the proxy’s configuration resides on the application servers. The set of proxies to which an application server will communicate is determined either by a static list or using dynamic discovery via the advertise mechanism.
The application server relays life-cycle events (e.g. server startup/shutdown) to the proxies allowing them to effectively auto-configure themselves. Notably, the graceful shutdown of a server will not result in a fail-over response by a proxy, as is the case with traditional httpd-based load balancers.
Fine grained web-app lifecycle control
Traditional httpd-based load balancers do not handle web application undeployments particularly well.
From the proxy’s perspective requests to an un-deployed web application are indistinguishable from a request for an non-existent resource, and will result in 404 errors. In mod_cluster, each server forwards any web application context lifecycle events (e.g. web-app deploy/un-deploy) to the proxy informing it to start/stop routing requests for a given context to that server.
mod_cluster advantages over mod_jk
AJP is optional
Unlike mod_jk, mod_cluster does not require AJP. httpd connections to application server nodes can use HTTP, HTTPS, or AJP.