实现nginx的负载均衡

现在很多企业都采用多台服务器来共同支撑企业的网站，这样不仅可以加快企业网站的访问速度，还可以避免突发情况造成的灾难，但是会由于服务器本身原因或者某些外界因素会造成各个服务器的访问速度不一，这时候我们就需要配置http服务器的负载均衡来降低资源的浪费，下文就为大家介绍一下主流http服务器之一的nginx如何配置负载平衡。

一、Nginx负载均衡原理简介：

  能实现nginx负载均衡的好处有很多，其中有如果您的服务器中的一台坏了，他可以自动识别，可以让您在第一时间了解情况，还有可以实现服务器访问速度均衡，比如说你有两个服务器甲和乙，甲的响应时间为2，乙的响应时间为1，这时候nginx就会自动调整访问乙的概率是甲的两倍，真正做到最大程度的降低资源的浪费。

二、nginx负载均衡配置基础知识简介：

如果只有一台服务器时,这个服务器挂了,那么对于网站来说是个不小的损失.因此，这时候的负载均衡就会大显身手了,它会自动剔除挂掉的服务器.

nginx 的 upstream目前支持 4 种方式的分配

1、轮询（默认）

  每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

2、weight

  指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

3、ip_hash

  每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 

4、fair（第三方）

  按后端服务器的响应时间来分配请求，响应时间短的优先分配。 

5、url_hash（第三方）



配置：

在http节点里添加:

#定义负载均衡设备的 Ip及设备状态

[html]  view plain  copy

1. upstream myServer {    
2.   
3.     server 127.0.0.1:9090 down;  
4.   
5.     server 127.0.0.1:8080 weight=2;  
6.   
7.     server 127.0.0.1:6060;  
8.   
9.     server 127.0.0.1:7070 backup;  
10.   
11. }  

在需要使用负载的Server节点下添加

proxy_pass http://myServer;

upstream 每个设备的状态:

down 表示单前的server暂时不参与负载

weight  默认为1.weight越大，负载的权重就越大。

max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误

fail_timeout:max_fails 次失败后，暂停的时间。

backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

Nginx还支持多组的负载均衡,可以配置多个upstream  来服务于不同的Server.

配置负载均衡比较简单,但是最关键的一个问题是怎么实现多台服务器之间session的共享



下面有几种方法(以下内容来源于网络,第四种方法没有实践.)

1、不使用session，换作cookie

  能把session改成cookie，就能避开session的一些弊端，在从前看的一本J2EE的书上，也指明在集群系统中不能用session，否则惹出祸端来就不好办。如果系统不复杂，就优先考虑能否将session去掉，改动起来非常麻烦的话，再用下面的办法。

2、应用服务器自行实现共享

  asp.net可以用数据库或memcached来保存session，从而在asp.net本身建立了一个session集群，用这样的方式可以令 session保证稳定，即使某个节点有故障，session也不会丢失，适用于较为严格但请求量不高的场合。但是它的效率是不会很高的，不适用于对效率 要求高的场合。

以上两个办法都跟nginx没什么关系，下面来说说用nginx该如何处理：

3、ip_hash

  nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，ip_hash是在upstream配置中定义的：

[html]  view plain  copy

1. upstream backend {  
2.   
3.   server 127.0.0.1:8080 ;  
4.   
5.   server 127.0.0.1:9090 ;  
6.   
7.    ip_hash;  
8.   
9. }  

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共享。

三、nginx.conf配置文件的配置：

  配置负载均衡最重要的是要配置好nginx配置文件，下文就举一个实例说明nginx.conf配置文件如何配置：

[html]  view plain  copy

1. user  www www;  
2.   
3. worker_processes 10;  
4.   
5. #error_log  logs/error.log;  
6.   
7. #error_log  logs/error.log  notice;  
8.   
9. #error_log  logs/error.log  info;  
10.   
11. #pid  logs/nginx.pid;  
12.   
13. #最大文件描述符  
14.   
15. worker_rlimit_nofile 51200;  
16.   
17. events {  
18.   
19.   use epoll;  
20.   
21.   worker_connections 51200;  
22.   
23. }  
24.   
25. http {  
26.   
27.   include conf/mime.types;  
28.   
29.   default_type  application/octet-stream;  
30.   
31.   keepalive_timeout 120;  
32.   
33.   cp_nodelay on;  
34.   
35. upstream  www.hws.com  {  
36.   
37.    server   192.168.1.2:80;  
38.   
39.    server   192.168.1.3:80;  
40.   
41.    server   192.168.1.4:80;  
42.   
43.    server   192.168.1.5:80;  
44.   
45. }  
46.   
47. upstream  blog.hws.com  {  
48.   
49.     server   192.168.1.7:8080;  
50.   
51.     server   192.168.1.7:8081;  
52.   
53.     server   192.168.1.7:8082;  
54.   
55.     }  
56.   
57. server{  
58.   
59.         listen  80;  
60.   
61.         server_name  www.hws.com;  
62.   
63. location / {  
64.   
65.             proxy_pass        http://www.hws.com;  
66.   
67.             proxy_set_header   Host    $host;  
68.   
69.             proxy_set_header   X-Real-IP    $remote_addr;  
70.   
71.             proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;  
72.   
73.               }  
74.   
75. log_format  www_s135_com  '$remote_addr - $remote_user [$time_local] $request '  
76.   
77. ''$status' $body_bytes_sent '$http_referer' '  
78.   
79. ''$http_user_agent' '$http_x_forwarded_for'';  
80.   
81. access_log  /data1/logs/www.log  www_hws_com;  
82.   
83.      }  
84.   
85. server{  
86.   
87.         listen  80;  
88.   
89.         server_name  blog.hws.com;  
90.   
91. location / {  
92.   
93.             proxy_pass   http://blog.hws.com;  
94.   
95.             proxy_set_header   Host             $host;  
96.   
97.             proxy_set_header   X-Real-IP        $remote_addr;  
98.   
99.             proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;  
100.   
101.             }  
102.   
103. log_format  blog_s135_com  '$remote_addr - $remote_user [$time_local] $request '  
104.   
105. ''$status' $body_bytes_sent '$http_referer' '  
106.   
107. ''$http_user_agent' '$http_x_forwarded_for'';  
108.   
109. access_log  /data1/logs/blog.log  blog_hws_com;  
110.   
111.       }  
112.   
113. }  

转载地址

https://blog.youkuaiyun.com/andong154564667/article/details/52121765