Nginx for load balancing

  • Nginx configuration
Environment restrictions, Nginx load balancing under win10 test, the configuration is relatively simple, the simplest configuration is as follows:
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    upstream cluster_test{
	server 127.0.0.1:6080;
	server 127.0.0.1:7080;
	#ip_hash;
        #upstream_hash;
    }

    server {
        listen       80;
        server_name  localhost;

        location / {
            root   html;
            index  index.html index.htm	index.jsp;
	    proxy_pass	http://cluster_test;
	    proxy_set_header	Host	$host;
	    proxy_set_header	X-Real-IP	$remote_addr;
	    proxy_set_header	X-Forwarded-For	$proxy_add_x_forwarded_for;
        }
    }
}
ip_hash: Implement Session Sticky, select the same back-end server for clients in the same class C address segment, unless the back-end server is down, it will be replaced with an
upstream_hash: In order to solve some problems of ip_hash, you can use the third-party upstream_hash Module, this module is mostly used as url_hash
nginx_upstream_jvm_route: Nginx extension module, used to implement Cookie-based Session Sticky function


  • Nginx+tomcat+jeesite cluster
The ip_hash, upstream_hash, and nginx_upstream_jvm_route in Nginx can achieve the purpose of session sharing. The ip_hash has been verified, and you can try it if you are interested. This article uses an external cache to achieve the purpose of session sharing. Jeesite provides Ehcache and redis solutions by default, and uses Ehcache's RMI for cache synchronization to achieve session sharing. Choosing this solution is just to save trouble, and it is recommended to use redis.

In the actual test, every time I switch the node shiro's custom sessionid will become better, it took me a lot of time, and I almost collapsed. I searched various information and looked at the shiro source code. I also guessed that it might be a cache synchronization problem. I simply did the next test and found that there was synchronization. I went to check other problems, took a lot of detours, and finally found that it was still a cache problem. The default ehcache-rmi.xml configuration under jeesite needs to be adjusted. The parameters of the activeSessionCache listening factory replicateAsynchronously=true and replicateUpdatesViaCopy=false need to be adjusted. Adjust replicateAsynchronously=false, replicateUpdatesViaCopy=true, or replicateUpdatesViaCopy=true, asynchronousReplicationIntervalMillis=200. The reason is that there is a time interval for asynchronous replication between cache nodes, and the replication may not be completed when switching nodes. Therefore, synchronous replication or asynchronous replication should be used according to the actual application scenario of the cache, and the interval time should be paid attention to when asynchronous replication.

tomcat-redis-session-manager, memcached-session-manager can also achieve the purpose of session sharing,

using the session processing idea after load balancing
quote

Apache vs Nginx Comparison
quote

Comparative analysis of web server nginx and apache
quote

Why is Nginx's performance much higher than Apache's?
quote

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326869139&siteId=291194637