[toc]
负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
语法配置
upstream uuclass {
server 192.168.205.10:80 weight=2;
server 192.168.205.11:80 weight=4;
}
server {
listen 81;
server_name localhost;
location / {
proxy_pass http://uuclass;
include proxy_params;
}
}
在线演示
可选参数调度状态
| 参数 | 说明 |
|---|---|
| down | 当前的server暂时不参与负载均衡 |
| backup | 预留的备份服务器 |
| max_fails | 允许请求失败的次数 |
| fail_timeout | 经过max_fails失败后，服务暂停的时间 |
| max_conns | 限制最大的接收连接数 |
调度算法
| 调度算法 | 说明 |
|---|---|
| 轮询（默认） | 每个请求按时间顺序逐一分配到不同的后端服务，如果后端某台服务器死机，自动剔除故障系统，使用户访问不受影响。 |
| weight（加权轮询） | weight的值越大分配到的访问概率越高，主要用于后端每台服务器性能不均衡的情况下。或者仅仅为在主从的情况下设置不同的权值，达到合理有效的地利用主机资源。 |
| ip_hash | 每个请求按访问IP的哈希结果分配，使来自同一个IP的访客固定访问一台后端服务器，并且可以有效解决动态网页存在的session共享问题。 |
| url_hash | 按访问的URL的哈希结果来分配请求，使每个URL定向到一台后端服务器，可以进一步提高后端缓存服务器的效率。Nginx本身不支持url_hash，如果需要这种调度算法，则必须安装Nginx的hash软件包。 |
| least_conn | 最少连接数，根据当前后端服务器所响应的客户端情况，把当前访问请求调度到后端服务器响应相对较少服务器上。 |
你以为这样就完事了吗，错，万物都是两面性的，当你解决了一个问题，就会产生另一大堆问题，呵呵
负载均衡引发的一系列问题
session一致性问题
如果你的网站有登录，那就要面临session的问题
方法一：基于nginx的ip_hash策略
upstream uuclass {
ip_hash; <-------here
server 192.168.205.10:80 weight=2;
server 192.168.205.11:80 weight=4;
}
方法二：session集中管理
比较靠谱的解决方案是，把session存到Redis里，单独开一台服务器作为Redis服务器，Laravel可以很方便的配置session存储的driver，原生PHP可以修改php.ini
- 存储到memcache
session.save_handler = memcache
session.save_path = "tcp://192.168.56.11:11211"
- 存储到redis
session.save_handler = redis
session.save_path ="tcp://localhost:6379"
提醒：别忘了给PHP安装memcache或者redis插件
参考文章
代码同步问题
机器多的话，总不能一台一台去手动更新代码吧
rsync，缓存、日志等文件过滤
多台服务器环境搭建问题
要保证每一台服务器的配置都一样，难道要手动一台一台去配置吗，这时候可以用到docker了
日志排查麻烦
反向代理隐藏了真实的IP地址，排查日志需要逐台排查
吐槽
负载均衡这种东西，云平台已经很成熟了，花点钱去买个现成的吧，如果是个人学习的可以自己搭建玩一玩，商用的还是用别人的产品比较靠谱，各种问题都替你考虑好了，配置起来也简单
