grep 80
tcp LISTEN 0 128 *:80 *:* users:(("nginx",pid=4933,fd=6),("nginx",pid=4932,fd=6))
网页访问验证
4、使用tengine的负载均衡功能
因为tengine的其他功能和nginx配置差不多，就不在演示了；主要演示，我认为较为方便的反向代理配置。
4.1 配置反向代理
tengine配置反向代理格式和haproxy很相似；
后端两台服务器事先自己准备好网页服务（nginx/httpd等都可以）
[root@along tengine]# cd /app/tengine/conf/
[root@along conf]# vim nginx.conf
http {
... ...
#配置后端代理集群，默认是轮询算法
upstream srv {
server 192.168.10.101:80;
server 192.168.10.106:80;
check interval=3000 rise=2 fall=5 timeout=1000 type=http;
check_http_send "HEAD / HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
... ...
#在server端location反向代理
server {
location / {
proxy_pass http://srv;
}
}
... ...
}
4.2 重启服务器，验证
（1）验证配置是否有误
[root@along tengine]# ./sbin/nginx -t
nginx: the configuration file /app/tengine/conf/nginx.conf syntax is ok
nginx: configuration file /app/tengine/conf/nginx.conf test is successful
（2）重启服务器
[root@along tengine]# systemctl restart nginx
（3）网页访问验证
因为默认是轮询算法，所以刷新页面，就会轮询调度到后台2个网页服务器
5、nginx upstream模块调度算法详解
5.1 轮询
轮询是upstream的默认分配方式，即每个请求按照时间顺序轮流分配到不同的后端服务器，如果某个后端服务器down掉后，能自动剔除。
upstream srv {
server 192.168.10.101:80;
server 192.168.10.106:80;
}
5.2 weight加权轮询
加权轮询，轮询的加强版，即可以指定轮询比率，weight和访问几率成正比，主要应用于后端服务器异质的场景下。
upstream srv {
server 192.168.10.101:80 weight=1;
server 192.168.10.106:80 weight=2;
}
5.3 ip_hash
每个请求按照访问ip（即Nginx的前置服务器或者客户端IP）的hash结果分配，这样每个访客会固定访问一个后端服务器，可以解决session一致问题。
upstream srv {
ip_hash;
server 192.168.10.101:80;
server 192.168.10.106:80;
}
注意：
- 当负载调度算法为ip_hash时，后端服务器在负载均衡调度中的状态不能是weight和backup。
- 导致负载不均衡。
5.4 fair
fair顾名思义，公平地按照后端服务器的响应时间（rt）来分配请求，响应时间短即rt小的后端服务器优先分配请求。如果需要使用这种调度算法，必须下载Nginx的upstr_fair模块。
upstream srv {
fair;
server 192.168.10.101:80;
server 192.168.10.106:80;
}
5.5 url_hash（目前用consistent_hash替代url_hash）
与ip_hash类似，但是按照访问url的hash结果来分配请求，使得每个url定向到同一个后端服务器，主要应用于后端服务器为缓存时的场景下。
upstream srv {
server 192.168.10.101:80;
server 192.168.10.106:80;
hash $request_uri;
hash_method crc32;
}
- 其中，hash_method为使用的hash算法，需要注意的是：此时，server语句中不能加weight等参数。
- 提示：url_hash用途cache服务业务，memcached，squid，varnish。特点：每个rs都是不同的。
- 按访问url的hash结果来分配请求，让每个url定向到同一个后端服务器，后端服务器为缓存服务器时效果显著。在upstream中加入hash语句, server语句中不能写入weight等其他的参数，hash_ method是使用的hash算法。。
- url_ hash.按访问ur1的hash结果来分配请求，使每个url定向到同-一个后端服务器，可以进一步提高后端缓存服务器的效率命中率。Nginx 本身是不支持ur1_ hash的，如果需要使用这种调度算法，必须安装Nginx的hash软件包。
6、upstream段用法介绍
（1）参数说明
- server：关键字，必选。
- address：主机名、域名、ip或unix socket，也可以指定端口号，必选。
- parameters：可选参数，可选参数如下：
- down：表示当前的server暂时不参与负载均衡。
- backup：预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的压力最轻。
- weight：默认为1.weight越大，负载的权重就越大。
- max_fails：允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误。
- fail_timeout：在经历了max_fails次失败后，暂停服务的时间。max_fails可以和fail_timeout一起使用。
- max_fails和fail_timeout一般会关联使用：如果某台server在fail_timeout时间内出现了max_fails次连接失败，那么Nginx会认为其已经挂掉了，从而在fail_timeout时间内不再去请求它，fail_timeout默认是10s，max_fails默认是1，即默认情况是只要发生错误就认为服务器挂掉了，如果将max_fails设置为0