Tomcat cluster

  • The basic concept
  • Environment to prepare
    • Configuring the Tomcat Cluster
    • Configure Nginx
  • Load balancing
    • polling
    • The weight
    • ip_hash
  • Sharing Session
    • Ip_hash strategy
    • Session replication
    • SSO SSO

The basic concept

  • The bearing capacity of a single Tomcat server is limited. When the system has a large number of users and the request pressure is high, a single Tomcat server cannot bear the request pressure. In this case, a Tomcat cluster needs to be built
  • Through the reverse proxy serverNginxCan be implementedTomcatLoad balancing of servers

Environment to prepare

Configuring the Tomcat Cluster

  • On the server, install multiple Tomcat servers and configure the Tomcat server using server.xml

Configure Nginx

  • On the Nginx reverse proxy server, install the Nginx reverse proxy server and configure the Nginx reverse proxy server through nginx.conf:
upstream serverpool { server localhost:8888; server localhost:9999; } server { listen 6666; server_name localhost; Location / {proxy_pass http://serverpool/; }}Copy the code

Load balancing

polling

  • Polling: The basic configuration method, which is the default load balancing policy of the Upstream module. Each request is allocated to a different backend server one by one in chronological order
upstream serverpool {
	server localhost:8888;
	server localhost:9999;
}
Copy the code
  • Parameter Description:
parameter instructions
fail_timeout The failure timeout can be used in conjunction with max_FAILS
max_fails Configure fail_timeout Maximum number of failures within the specified time. If all requests for the service fail within the specified time, the server is considered to be down
fail_time The length of time the server is considered to be down. The default is 10 seconds
backup Mark the server as the standby server When the primary server stops, requests are sent to the standby server
down Mark the server as permanently down

The weight

  • Weiht weight: Specifies the probability of polling based on the polling strategy
upstream serverpool {
	server localhost:8888 weight=3;
	server localhost:9999 weight=1;
}
Copy the code
  • Weight parameter: specifies the probability of polling. The default value is 1. The value of the weight parameter is proportional to the probability of access
  • Weight The weight policy applies to servers with large hardware configurations

ip_hash

  • Ip_hash: specifies the client IP address assignment mode for load balancing requests

    • This method ensures that the same request from the client is always sent to the same server, thus guaranteeing session session
    • Each fixed client access is fixed access to the same server, can solve the problem of session cannot cross server
upstream serverpool {
	ip_hash;
	server 192.168.6.33:8080;
	server 192.168.6.35:8080;
}
Copy the code

Sharing Session

  • In a Tomcat cluster, if the application requires users to perform post-login operations, if Tomcat is load balanced, and requests are sent to different Tomcat servers, access problems may occur

  • To solve the Session sharing problem, the following solutions are available:

    • Ip_hash strategy
    • Session replication
    • SSO SSO

Ip_hash strategy

  • Using the IP_hash policy, all requests from the same user will be sent to the same Tomcat server through Nginx, thus avoiding Session sharing problems

Session replication

  • Add the following configuration to Tomcat’s conf/server.xml:
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" />
Copy the code
  • Add the following configuration to the WEB. XML file in the Web-INF of the Tomcat deployment project:
<distribute />
Copy the code

  • After the configuration is complete, restart Tomcat to complete Session replication among Tomcat servers in the cluster

  • Note:

    • The Session replication scheme is only applicable to a cluster environment with a small number of nodes. The number of nodes cannot exceed four
    • If a cluster has a large number of nodes, Session replication in this broadcast mode consumes a large amount of network bandwidth, affecting service performance

SSO SSO

  • Single sign-on (SSO) is one of the most popular solutions for Session sharing in a cluster environment
  • SSODefined in multiple application systems, users can log in once to access all trusted application systems, used to solve the cluster environmentSessionSharing problem