杭州网站程序开发公司页面访问升级老域名
负载均衡：将四层或者七层的请求分配到多台后端的服务器上。
从而分担整个业务的负载。提高系统的稳定性，也可以提高高可用（备灾，其中一台后端服务器如果发生故障不影响整体业务）.
负载均衡的算法
round robin 轮询 rr
负载均衡的默认算法，请求轮流分配给后端服务器。
轮询算法适合用于后端处理器能力相近的情况，默认的算法，可以不加。
默认
加权轮询-weight round robin
轮询的升级版，给每个后端服务器赋予不同的权重。
处理能力更强的服务器设置更高的权重，处理能力低的设置低权重。
高峰时间可以通过这个方法进行流量的优化，适用于服务器处理能力差异比较大的情况。
weight=number
ip_Hash
当我们访问后端服务器，根据客户端的IP地址，使用hash算法计算出IP地址的hash值，然后再根据请求发送到相应的后端服务器。
如果客户端访问的ip地址相同，通过hash算法，再一次的请求会分配到上一次访问的服务器，保证会话的稳定。
负载均衡的会话保持——>ip_Hash
会话保持到期之后，会话中断，重新请求会重新计算hash值。
ip_hash；
最小连接数
配合加权轮询一起使用，最小连接数的算法可以将请求发送到当前连接比较少的后端服务器。
这种算法适用后端服务器处理任务耗时不同的情况，可以有效的避免所有的请求集中在处理能力更强的后端服务器上。
least_conn；
weight=number
URL_Hash
根据请求当中url地址来计算hash值，如果客户端请求的url地址相同，客户端的请求会被分配到同一个服务器。
后台服务器的数量发生变化，会影响结果。（这个讨论无意义）
hash_$request_uri consistest；
负载均衡的特点
1、根据算法把请求分配到不同的服务器
2、客户端访问的是代理地址，响应也是代理服务器响应。
3、客户端并不了解后端服务器的情况
4、可以提高安全性，后端服务器是隐藏的。
5、负载均衡是有缓存的，可以直接访问缓存，提高响应的速度。
负载均衡的架构
我们做个实验，三台主机，具体配置如下：
zw4：192.168.254.14（代理服务器）
zw5：192.168.254.15（后端）
zw6：192.168.254.16（后端）
客户端：浏览器
配置流量分发，主要是依靠服务器完成的，主要配置在代理服务器完成配置算法。
七层代理
upstream：模块仅支持http协议，用来处理http的请求和响应。
upstream：只能写在http模块当中，不能在server也不能在全局。
基于IP的七层
轮询
配置完之后，我们访问主机（192.168.254.14）的nginx，会发现轮流访问的是设定的2台服务器的nginx，并且状态码为200，表示没有缓存。
加权轮询
这时候权重高的服务器被访问的次数多一点，状态码依然为200，没有缓存。
ip_hash
这时候第一次会根据hash算法匹配到一台服务器，之后再访问都是他了，并且状态码为304，表示访问缓存，这是根据IP地址的hash缓存，也是会话保持。
最小连接数配合轮询
这时候和轮询没什么区别，这是因为不好演示最小连接数，状态码依然为200。
URL_hash
这时候第一次会根据算法匹配到一台服务器，之后再访问都是他了，并且状态码为304表示缓存。注意：这里的缓存是url缓存，url地址不变才导致的访问服务器不变，并不是真正的会话保持。
最后我们停掉192.168.254.15的nginx后，会发现负载均衡依然再正常运行，并且只能访问192.168.254.16的nginx，证明了高可用。
基于域名的七层
基于域名的七层代理
首先配置代理服务器zw4的nginx主配置文件
注意：1、如果使用域名才做七层，需要把客户端访问的真实IP地址传递给服务端
2、如果经过代理，所有经过的代理地址也要传递给服务端
接着三台主机都配置域名解析，记得也要修改另外两台后端（zw5和zw6）的nginx上的localhost。
这时候我们发现负载均衡已正常工作，当然也是默认的轮询算法。
四层代理
stream：模块不支持http协议，仅支持tcp和udp，处理数据包流量分发。
四层代理只能写在全局模块当中。
根据上面的实验我们依然在代理服务器zw4上配置nginx的主配置文件，注意server中的端口号不能和下面http模块中server的端口号一样，所有这里我们随便定了个81。
重启nginx后，我们发现负载均衡的算法依然是轮询。
注意：
四层算法默认是轮询，也支持加权轮询和最小连接数支持。
ip_hash和uri_hash，不能在四层算法中使用，因为四层不能处理响应。