nginx upstream的几种配置方式

nginx upstream的几种配置方式

nginx 的upstream目前支持4种方式的分配 1、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器 ，如果后端服务器down掉，能自动剔除。 2、weight 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 例如：     upstream bakend {          server 192.168.0.14 weight=10;          server 192.168.0.15 weight=10;     } 2、ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session 的问题。 例如：     upstream bakend {          ip_hash;          server 192.168.0.14:88;          server 192.168.0.15:80;     } 3、fair（第三方） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。 upstream backend {     server server1;     server server2;     fair; } 4、url_hash（第三方） 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。 例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法 upstream backend {     server squid1:3128;     server squid2:3128;     hash   $request_uri;     hash_method crc32; } tips: upstream bakend{#定义负载均衡 设备的Ip及设备状态 ip_hash;     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; } 在需要使用负载均衡的server中增加 proxy_pass http://bakend/ ; 每个设备的状态设置为: 1.down 表示单前的server暂时不参与负载 2.weight 默认为1.weight越大，负载的权重就越大。 3.max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误 4.fail_timeout:max_fails次失败后，暂停的时间。 5.backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。 nginx支持同时设置多组的负载均衡，用来给不用的server来使用。 client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug client_body_temp_path 设置记录文件的目录 可以设置最多3层目录 location 对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡 ------------------------------------------------------------------------------------------------------- #############这个不错#####################3 转：http://salogs.com/2010/05/nginx-http负载均衡反向代理的相关参数测试/ upstream test  { server 192.168.108.163 ; server 192.168.108.164:80; } ·weight = NUMBER - 设置服务器权重，默认为1。 ·max_fails = NUMBER - 在一定时间内（这个时间在fail_timeout参数中设置）检查这个服务器是否可用时产生的最多失败请求数，默认为1，将其设置为0可以关闭检查， 这些错误在proxy_next_upstream或fastcgi_next_upstream（404错误不会使max_fails增加）中定义。 ·fail_timeout = TIME - 在这个时间内产生了max_fails所设置大小的失败尝试连接请求后这个服务器可能不可用， 同样它指定了服务器不可用的时间（在下一次尝试连接请求发起之前），默认为10秒，fail_timeout与前端响应时间没有直接关系， 不过可以使用proxy_connect_timeout和 proxy_read_timeout来控制。 ·down - 标记服务器处于离线状态，通常和ip_hash一起使用。 ·backup - (0.6.7或更高)只用于本服务器，如果所有的非备份服务器都宕机或繁忙。backup只有当该组中所有的主机都不可用时才会转到backup上来 关于max_fails参数的理解：根据上面的解释，max_fails默认为1，fail_timeout默认为10秒，也就是说， 默认情况下后端服务器在10秒钟之内可以容许有一次的失败，如果超过1次则视为该服务器有问题，将该服务器标记为不可用。 等待10秒后再将请求发给该服务器，以此类推进行后端服务器的健康检查。但如果我将max_fails设置为0，则代表不对后端服务器进行健康检查， 这样一来fail_timeout参数也就没什么意义了。那若后端服务器真的出现问题怎么办呢？上文也说了，可以借助proxy_connect_timeout和proxy_read_timeout进行控制。 下面介绍http proxy模块中的相关指令： proxy_next_upstream 语法： proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off] 确定在何种情况下请求将转发到下一个服务器。转发请求只发生在没有数据传递到客户端的过程中。 proxy_connect_timeout 后端服务器连接的超时时间_发起握手等候响应超时时间 proxy_read_timeout 连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间） proxy_send_timeout 后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据 proxy_pass 这个指令设置被代理服务器的地址和被映射的URI ----------------------------------------------------------------------－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ mbillion 注 max_fails=0 关闭后端服务器健康检查，不会标记服务器不可用，fail_timeout的值也失去意义。 proxy_next_upstream error timeout http_500 http_502 http_504 server 192.168.108.163 max_fails = 0; server 192.168.108.164 max_fails = 0; 关闭了后端服务器的健康检查（max_fails=0）因此判断后端服务器情况的唯一依据便是proxy_read_timeout参数 1、如果用户请求到192.168.108.163，只有在proxy_read_timeout超时才转到192.168.108.164服务器，但不会标记192.168.108.163不可用，因为max_fails=0 2、如果用户请求到192.168.108.163有报错，报错信息在proxy_next_upstream 中有定义的话nginx还会跳到下一台服务器 192.168.108.164，但不会标记192.168.108.163不可用，因为max_fails=0 3、后端服务器正常但执行超时的情况下nginx根据proxy_read_timeout和proxy_next_upstream的值来选择下一个服务器，那如果我后端服务器直接报错的情况呢？ 可以想到如果报错信息在proxy_next_upstream 中有定义的话nginx还会跳到下一台服务器。否则直接将保存信息返回给nginx从而最终呈献给用户 max_fails=1 打开后端服务器健康检查，会标记服务器不可用，根据fail_timeout的值不可有时间 proxy_next_upstream error timeout http_500 http_502 http_504 server 192.168.108.163 max_fails = 1 fail_timeout=10s; server 192.168.108.164 max_fails = 1 fail_timeout=10s; 1、如果用户请求到192.168.108.163，只有在proxy_read_timeout超时才转到192.168.108.164服务器，同时标记192.168.108.163不可用，同时标记192.168.108.163不可用，在fail_timeout=10s设置为10s(默认也是10S)    当在这10S内再有用户请求nginx就会直接转到192.168.108.164服务器，当过10S后会标记192.168.108.163可用 2、如果用户请求到192.168.108.163有报错，报错信息在proxy_next_upstream 中有定义的话nginx还会跳到下一台服务器 192.168.108.164，同时标记192.168.108.163不可用，在fail_timeout=10s设置为10s(默认也是10S)    当在这10S内再有用户请求nginx就会直接转到192.168.108.164服务器，当过10S后会标记192.168.108.163可用 总结： nginx的健康检查就是通过访问，如果访问出现超时，或出错时就会标记为不可用，如max_fails = 1，如果在后端192.168.108.163出现请求不可用，在后端192.168.108.163就会看到一条请求（当然大型网站可能在短时间内在大量的请求过来），在10S内不会有第二条请求过来，因为max_fails = 1设置为1 用户所花的访问时间，程序执行时间+proxy_read_timeout 时间，proxy_read_timeout设置为60s 如果在请求第一台时出现超时，就会跳到第二台，第台机器程序如果执行交时间为10s 那么用户花费的时间就60s 不管开不开启后端服务器健康检查，一次请求只能轮一遍服务器，不会出现重复。 如果多台后端服务器，难道要轮一遍吗，nginx还有一个参数client_body_timeout的值，客户端请求内容超时时间，默认是60秒，出现超时就会返回request time out,错误信息（http 状态码：408） 注意： max_fails有几次就会看到几个请求，一直达到max_fails的次数才会认为192.168.108.163是不可用的，此时请求才会到 192.168.108.164上。 这里要说明的是404错误，因为按照官方的文档404并不会使得max_fails次数增加如果设置这样一条规则： proxy_next_upstream  http_404; upstream  edt{                 server 192.168.16.80:81 max_fails=2 fail_timeout=60s;   #规则一                 server 192.168.16.196:80 backup;   #规则三       } 当出现404时候你会发现这是一个死循环，在16.80的日志中会不停的循环出现该404请求，直至资源耗尽。所以要注意。 但是当出现404就是想跳到另外的机器怎么实现呢？ 可以用这样的办法error_page  404 = @backup; 然后设置一个location backup的方法来迂回实现。具体配置如上。 ------------------------------------------------------------------------------------------------------------------------ 设备状态： Weight=NUMBER 设置服务器的权重，权重数值越高，被 分配到客户端的请求次数越多，默认值为1 Max_fails=BUMBER 在参数fail_timeout指定时间内对后端服务器请求失改的次数，如果检测到后端服务器无法连接及发生服务器错误（404错误除外），则标记为失败。如果没有设置，则默认值为1，设置为0将关闭这项检查。 Tail_timeout=TIME 在经历参数max_fails设置的失改次数后，暂停的时间。 Down 标记服务器为永久离线状态，用于ip_hash命令。 Backup 仅在非backup服务器全部宕机或繁忙的时候才启用，这台服务器的负载会最轻。 如：     server 127.0.0.1:8080 max_fails=2 fail_timeout=30s;     server 127.0.0.1:6060 max_fails=2 fail_timeout=30s;     默认情况下后端服务器在30秒钟之内可以容许有两次的失败，如果超过两次则视为该服务器有问题，将该服务器标记为不可用。     在之后的30秒之内，所有请求不会再发送给有问题的服务器，等待30秒后再将请求发给该服务器，以此类推进行后端服务器的健康检查    ------------------------------------------------------------------------------------------------------------------------------------------ nginx中，ip_hash和url_hash的区别 最近看nginx的负载均衡，发现为了解决nginx的session问题，有两种方法，就是ip_hash和url_hash，ip_hash是根据ip来维持session的，而url_hash是根据url地址的，url_hash的优点是能够提高后端缓存服务器的效率，比如提高squid的效率，但是缺点是当后端服务器宕机的时候，url_hash不会自动跳转的其他缓存服务器，而是返回给用户一个503错误，我想问的是，那ip_hash有没有解决这个问题，是不是会跳转到其他机器上，还是一样会返回一个503错误，那ip_hash和url_hash有什么区别啊，还有就是nginx能不能即解决session问题又解决后端服务器的健康检查问题。 我记得squid是可以健康检查和session保持的。 答： 你可以使用memcached来保持session，实现session共享，无需担心session掉线（这根本就不是一个答案）