nginx+tomcat configure load balancing cluster

、 、 Hello world

1. Preliminary environmental preparation

1. Prepare two decompressed versions of tomcat, how to start two tomcats at the same time, please see my other article "one machine starts multiple tomcats at the same time" .
2. Download the decompressed version of nginx from the nginx official website .
3. Create a simple web project. In order to visually distinguish which tomcat is accessed, mark 8081 and 8082 on the page.
4. Deploy to the corresponding tomcat respectively. Pictured:​​​​

​

2. Configure nginx

Enter the nginx-1.10.1\conf path and modify the configuration file nginx.conf .

1. Configure the server group and add upstream configuration between http{} nodes. ( Be careful not to write localhost, otherwise the access speed will be very slow )

upstream nginxDemo {
    server 127.0.0.1:8081;   #服务器地址1
    server 127.0.0.1:8082;   #服务器地址2
}

2. Modify the port number 80 monitored by nginx to 8080.

server {
    listen       8080;
    ......
}

3. In location\{}, use proxy_pass to configure the reverse proxy address; here "http://" cannot be missing, and the following address must be consistent with the name defined by upstream in the first step.

    location / {
            root   html;
            index  index.html index.htm;
            proxy_pass http://nginxDemo; #配置方向代理地址
        }

As shown below:

3. Start nginx and tomcat, access

I am a Windows system, so double-click nginx.exe directly in the nginx-1.10.1 directory.

Can be viewed in task manager

Finally, enter the address in the browser: http://localhost:8080/nginxDemo/index.jsp, each visit will take turns to access tomcat (if F5 refresh does not work, it is recommended to try placing the mouse pointer in the address bar and click the Enter key ).

At this point, a very simple load balancing configuration is completed, isn't it very simple, O(∩_∩)O haha~

Second, nginx load balancing strategy

1. Polling (default)

Each web request is allocated to different back-end servers one by one in chronological order. If the back-end server goes down, it can be automatically eliminated.

    upstream nginxDemo {
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
    }

2. Minimal Links

Web requests are forwarded to the server with the fewest connections.

    upstream nginxDemo {
        least_conn;
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
    }

3. weight

Specifies the polling probability. The weight is proportional to the access ratio. It is used when the performance of the backend server is uneven. The default weight is 1.

    #服务器A和服务器B的访问比例为：2-1;比如有3个请求，前两个会访问A，三个访问B，其它规则和轮询一样。
    upstream nginxDemo {
        server 127.0.0.1:8081 weight=2; #服务器A
        server 127.0.0.1:8082; #服务器B
    }

4、ip_hash

Each request is allocated according to the hash value of the access ip, so that consecutive web requests from the same client will be distributed to the same server for processing, which can solve the problem of session. When the background server is down, it will automatically jump to other servers.

    upstream nginxDemo {
        ip_hash;
        server 127.0.0.1:8081 weight=2; #服务器A
        server 127.0.0.1:8082; #服务器B
    }

Weight-based load balancing and ip_hash-based load balancing can be used in combination.

5. url_hash (third party)

url_hash is a third-party module of nginx, which is not supported by nginx itself and needs to be patched.

Nginx allocates requests according to the hash result of accessing urls, so that each url is directed to the same back-end server, which is more effective when the back-end server is a cache server, file server, or static server. The disadvantage is that when the backend server is down, url_hash will not automatically jump to other cache servers, but will return a 503 error to the user.

    upstream nginxDemo {
        server 127.0.0.1:8081; #服务器A
        server 127.0.0.1:8082; #服务器B
        hash $request_url;
    }

6. fair (third party)

Requests are allocated according to the response time of the backend server, and those with short response times are allocated first.

    upstream nginxDemo {
        server 127.0.0.1:8081; #服务器A
        server 127.0.0.1:8082; #服务器B
        fair;
    }

 

3. Session processing strategy in cluster/distributed environment

Because many friends mentioned the problem of session management, I decided to write a session processing strategy in a cluster/distributed environment.

1. Why do we need to deal with the session?

       Most of my friends must know this problem. After building a cluster or distributed environment, if no treatment is done, the website will frequently appear that users are not logged in. For example: There are two servers A and B in the cluster. When the user visits the website for the first time, Nginx distributes the user request to the A server. At this time, the A server creates a Session for the user. When the user visits the website for the second time, suppose Nginx distributes user requests to the B server, and at this time, the B server does not have the user's Session, so there will be a situation where the user is not logged in, which is unbearable for the user.

        Therefore, after building a cluster/distributed environment, a problem that must be considered is how to deal with the session generated by user access, that is, the sharing mechanism of the session.

       We roughly divide the ways of handling sessions into three types: session retention (some people call sticky sessions), session replication , and session sharing .

2. Session retention (or sticky Session)

        Session retention (session retention) is to lock the user to a certain server . For example, in the example above, when the user requests for the first time, the load balancer (Nginx) distributes the user's request to the A server. If the load balancer (Nginx) sets the session retention, then every subsequent request of the user will be Distributing to the A server is equivalent to sticking the user and the A server together, which is the principle of session retention. The session retention scheme has corresponding implementations in all load balancers. And this is the load balancing layer to solve the Session problem.

Advantages: very simple, do not need to do any processing of the session.

Disadvantages: 1. The responsibility is not absolutely balanced: due to the use of session retention, it is obvious that the absolute load balance cannot be guaranteed.

          2. Lack of fault tolerance: If a server in the backend goes down, the session of this server is lost, and the user assigned to this service request still needs to log in again, so the problem is not completely solved.

Applicable scenarios: failures have little impact on customers; server failures are low-probability events.

Implementation method: Take Nginx as an example, configure the ip_hash attribute in the upstream module to implement a sticky session. For details, please refer to chapter 2.4.

3. Session replication

       In view of the fault-tolerance shortcomings of session retention, we can save a user's session information on all servers. This process of copying the session information from each server to other servers is called session replication . When the session on any server changes, the node will serialize all the contents of the session, and then broadcast it to all other nodes, regardless of whether other servers need the session or not, so as to ensure the synchronization of the session.

Advantages: fault-tolerant, Sessions between servers can respond in real time.

Disadvantage: Synchronizing session broadcast to members will cause certain pressure on network load;

          If the amount of sessions is large, it may cause network congestion and slow down the server performance, especially when the objects saved in the session are large and the objects change rapidly; thus, the horizontal expansion of the application is limited;

          The serialization of session content also consumes system performance;

          The implementation is limited and must be implemented between the same components (for example, if you use tomcat, you must use tomcat for all).

Implementation method: tomcat itself already supports this function, you can refer to the official documentation . The introduction on the official website has been very detailed, and will not be introduced here. Moreover, this processing method is not recommended for production environments in large clusters.

There are two types of session replication in tomcat:

• Global Replication (DeltaManager): Replicates changes in a session to all other nodes in the cluster.

• Non-global replication (BackupManager): It will replicate the session to a specified backup node.

4. Session sharing