nginx can not only be used as a powerful web server, but also a reverse proxy server, and nginx can also separate dynamic and static pages according to scheduling rules. This method balances the load on the back-end servers, and also supports the health check of the back-end servers.
Some basics of Nginx load balancing:
The upstream of nginx currently supports 4 ways of allocation
1), polling (default)
each request is allocated to different back-end servers one by one in chronological order, if the back-end server is down, it can be automatically eliminated.
2), weight
specifies the polling probability, and the weight is proportional to the access ratio, which is used when the performance of the back-end server is uneven.
2)
Each request of ip_hash is allocated according to the hash result of accessing the ip, so that each visitor can access a back-end server fixedly, which can solve the problem of session.
3), fair (third party)
allocates requests according to the response time of the back-end server, and priority is given to those with short response time.
4), url_hash (third party)
Configuration:
In the http node add:
#Define the IP and device status of the load balancing device
upstream myServer {
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
Add under the Server node that needs to use the load
proxy_pass http://myServer;
Status of each upstream device:
down means that the server before the order does not participate in the load temporarily. The
default weight is 1. The larger the weight, the greater the weight of the load.
max_fails : The default number of allowable requests to fail is 1. When the maximum number of times is exceeded, the error defined by the proxy_next_upstream module will be returned.
fail_timeout: The time to pause after max_fails failures.
backup: When all other non-backup machines are down or busy, request the backup machine. So this machine will be the least stressful.
Nginx also supports multiple groups of load balancing, and multiple upstreams can be configured to serve different servers.
Configuring load balancing is relatively simple, but the most critical issue is how to share sessions between multiple servers
There are several methods below (the following content comes from the Internet, and the fourth method is not practiced.)
1) Do not use session, replace with cookie
If you can change the session into a cookie, you can avoid some of the disadvantages of the session. In a J2EE book I read before, it also pointed out that the session cannot be used in the cluster system, otherwise it will be difficult to deal with trouble. If the system is not complicated, the priority should be given to whether the session can be removed. If it is very troublesome to change, then use the following method.
2) The application server realizes sharing by itself
ASP.NET can use database or memcached to save sessions, thus establishing a session cluster in ASP.Net itself. In this way, sessions can be guaranteed to be stable. Even if a node fails, sessions will not be lost. Strict but low-request occasions. However, its efficiency is not very high, and it is not suitable for occasions that require high efficiency.
The above two methods have nothing to do with nginx. Let's talk about how to deal with nginx:
3) ip_hash
nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，ip_hash是在upstream配置中定义的：
upstream backend {
server 127.0.0.1:8080 ;
server 127.0.0.1:9090 ;
ip_hash;
}
ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用：
1/ nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。
2/ nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，或者再搭一个squid，然后指向应用服务器。最好的办法是用location作一次分流，将需要session的部分请求通过ip_hash分流，剩下的走其它后端去。
4) upstream_hash
为了解决ip_hash的一些问题，可以使用upstream_hash这个第三方模块，这个模块多数情况下是用作url_hash的，但是并不妨碍将它用来做session共享：
假如前端是squid，他会将ip加入x_forwarded_for这个http_header里，用upstream_hash可以用这个头做因子，将请求定向到指定的后端：
可见这篇文档：http://www.sudone.com/nginx/nginx_url_hash.html
在文档中是使用$request_uri做因子，稍微改一下：
hash $http_x_forwarded_for;
这样就改成了利用x_forwarded_for这个头作因子，在nginx新版本中可支持读取cookie值，所以也可以改成：
hash $cookie_jsessionid;
假如在PHP中配置的session为无cookie方式，配合nginx自己的一个userid_module模块就可以用nginx自发一个cookie，可参见userid模块的英文文档：
http://wiki.nginx.org/NginxHttpUserIdModule
另可用姚伟斌编写的模块upstream_jvm_route：http://code.google.com/p/nginx-upstream-jvm-route/
原文转至：http://blog.csdn.net/zljjava/article/details/47019331