黑历史
那一年，手头可以用作服务器的终端设备还比较紧俏。
那一年，某人认识了HAProxy。
那一年，某人用HAProxy，搞出了这样的操作👇
<-> Nginx1
用户 <-> HAProxy <-> Nginx2
<-> Nginx...
DUCK不必啊！！
Nginx自己就有负载均衡功能。配置案例如下👇
# 省略一万行
http{
# 待选服务器列表(注意一定要写在server外面)
upstream myproject{
# ip_hash指令，将同一用户引入同一服务器。
ip_hash;
server 192.168.1.1;
server 192.168.1.2 down;
server 192.168.1.3 weight=2;
server 192.168.1.4 backup;
}
server{
listen 80;
location / {
proxy_pass http://myproject;
}
}
}
关于配置案例中IP地址后的参数
| 参数 | 说明 |
|---|---|
| down | Server不参与负载均衡 |
| backup | 当其他的server（非backup）出现故障或者忙的时候，才会请求backup机器 |
| max_fails=N | 允许请求失败的次数，默认为1。当失败次数达到该值，就认为该机器down掉了。 失败的指标是由proxy_next_upstream模块定义 |
| fail_timeount=N | 定义失败的超时时间，也就是说在该时间段内达到max_fails，才算真正的失败。默认是10秒 |
| proxy_next_upstream | 通过后端服务器返回的响应状态码，表示服务器死活。语法：proxy_next_upstream error / timeout / invalid_header / http_500 / http_502 / http_503 / http_504 / http_404 / off |
其中关于proxy_next_upstream后接的参数
| 参数 | 说明 |
|---|---|
| error | 和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现错误 |
| timeout | 和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现超时 |
| invalid_header | 后端服务器返回空响应或者非法响应头 |
| http_500 | 后端服务器返回的响应状态码为500 |
| http_502 | 后端服务器返回的响应状态码为502 |
| http_503 | 后端服务器返回的响应状态码为503 |
| http_504 | 后端服务器返回的响应状态码为504 |
| http_404 | 后端服务器返回的响应状态码为404 |
| off | 停止将请求发送给下一台后端服务器 |
参考&摘录：
https://segmentfault.com/a/1190000014483200
https://www.huaweicloud.com/articles/c8bae49910f7e96a5d0575d6d163c884.html