nginx负载均衡中RR与ip_hash策略分析.docVIP

nginx负载均衡中RR和ip_hash策略分析 ： upstream tomcats { server 10.1.1.107:88 server 10.1.1.132:80 max_fails=3 fail_timeout=3s weight=9; } 2、ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 例如： upstream tomcats { ip_hash; server 10.1.1.107:88; server 10.1.1.132:80; } 3fair（） 4、url_hash（） 负载均衡策略no live upstreams while connecting to upstream”的记录（这就是no live产生的真正原因），并直接返回给请求的客户端一个502的错误。 2.2.3 当找到一个有效的server后，令该server的current_weight减一，然后，nginx就会尝试与该server建立连接。如果成功建立连接，跳转到2.2.4; 否则 跳转到2.2..3.1 2.2..3.1 如果nginx在等待了proxy_connect_timeout所设置的时间段后（如3秒），连接仍然没有建立成功，nginx就在错误日志中输出“upstream timed out (110: Connection timed out) while connecting to upstream”的记录（这就是 timed out（连接超时）产生的真正原因）. 2.2.3 .2 接着，让当前server的失败次数加一（peer-fails++; 如果该server最大失败次达到最大失败次数，将在一段时间内该server是无效的），如果当前nginx与后台服务器的尝试次数没有达到upstream中server的总个数，重新跳转到2.2.2, 轮循下一个server, 继续尝试。如果达到最大尝试次数，就表示uptream中所有的server都尝试了一遍，没有server可以提供服务，返回一个504的错误给客户端。 2.2.4 当nginx与server建立连接成功后，如果server响应请求，把处理结果返回给nginx, 跳转到2.2.5; 否则跳转到2.2.4.1 2.2.4.1 如果nginx在等待了proxy_read_timeout所设置的时间段后（如30秒），server仍然没有对nginx发送来的请求作出响应，nginx就在错误日志中输出“upstream timed out (110: Connection timed out) while reading response header from upstream”的记录（这就是 timed out（读超时）产生的真正原因）. 2.2.4.2 接着，让当前server的失败次数加一（peer-fails++; 如果该server最大失败次达到最大失败次数，将在一段时间内该server是无效的），如果当前nginx与后台服务器的尝试次数没有达到upstream中server的总个数，重新跳转到2.2.2, 轮循下一个server, 继续尝试。如果达到最大尝试次数，就表示uptream中所有的server都尝试了一遍，没有server可以提供服务，返回一个504的错误给客户端。 2.2.5 Nginx收到后台server传送过来的结果后，就会返回给客户端一个200的正确结果。这样，nginx作为反向代理的功能也就完成了。 Ip_hash策略 3.1 Ip_hash和RR 的策略有两点不同在于： 当一个客户请求到nginx后， nginx如何选择一个最初的server, 以及当前选择的server不能提供服务时，如何选择下一个server. 3.2 RR策略回顾 从第二部分对RR的介绍中，我们知道： 当一个客户请求到达后，RR策略是从upstream的所有server中选择一个当前权重（current_weight）最大的server作为最初的server. upstream的所有server是按照由高到低排序后存储在一个peers数组中，当最初选择的server不能提供服务时，RR策略就会选择peers数组中的下一个元素作为当前server，继续尝试， 如果已经达到数组的最大元素，就会从第一个元素再轮循。 3.3 ip_hash策略介绍 在ip_hash策略中，它选择最初的server的方法是根据请求客户端的IP计算出一个哈希值，再根据哈