一、集群介绍
1、传统web访问模型
（1）传统web访问模型完成一次请求的步骤
1）用户发起请求
2）服务器接受请求
3）服务器处理请求（压力最大）
4）服务器响应请求
（2）传统模型缺点
- 单点故障；
- 单台服务器资源有限（客户端则是无限的）；
- 单台服务器处理耗时长（客户等待时间过长）；
（3）传统模型优化——单点故障解决方案
- 优化方案一：部署一台备份服务器，宕机直接切换
该方案可以有效解决服务器故障导致的单点故障，但且服务器利用率低、成本高，切换不及时，且无法解决服务器业务压力问题。 - 优化方案二：部署多台服务器，根据DNS的轮询解析机制去实现用户分发
优势是用户处理速度得到了提升，但是当其中一台故障，dns并不会知道它故障了，依然将请求分给这个服务器，导致一部分用户访问不了业务。
2、并行处理解决方案
1）DNS轮询解析方案
2）多机阵列——集群模式
图中，前面两台服务器负责接受请求和分发请求，它自己并不处理请求，将请求分发给后面的业务服务器来处理。业务服务器处理完请求后，将请求发还给分发器，再由分发器将请求发送给客户，因此分发器还承担了响应请求的任务。
由此可见之前传统模型中服务器端需要承担的服务器接收请求和响应请求都交给分发器处理了，而业务压力最大的处理请求则交给业务服务器完成。
分发器和dns虽然都是进行了分发的工作，但不同点在于分发器是自己部署的服务器，而DNS都是使用的运营商的，因此可以调整分发器的逻辑判断规则。
3、集群
- 计算机集群简称集群，是一种计算机系统， 它通过一组松散集成的计算机软件或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。 (百度解释)
- 将多个物理机器组成一个逻辑计算机，实现负载均衡和容错。
组成要素：
1）VIP： 给分发器的一个虚IP
2）分发器：nginx
3）数据服务器：web服务器
4、Nginx集群原理
在Nginx集群中Nginx扮演的角色是：分发器。
任务：接受请求、分发请求、响应请求。
功能模块：
1）ngx_http_upstream_module：基于应用层（七层）分发模块
2）ngx_stream_core_module：基于传输层（四层）分发模块（1.9开始提供该功能）
（1）Nginx集群的实质
Nginx集群其实是：虚拟主机+反向代理+upstream分发模块组成的。
虚拟主机：负责接受和响应请求。
反向代理：带领用户去数据服务器拿数据。
upstream：告诉nginx去哪个数据服务器拿数据。
（2）数据走向（请求处理流程）
1）虚拟主机接受用户请求
2）虚拟主机去找反向代理（问反向代理去哪拿数据）
3）反向代理让去找upstream
4）upstream告诉一个数据服务器IP
5）Nginx去找数据服务器，并发起用户的请求
6）数据服务器接受请求并处理请求
7）数据服务器响应请求给Nginx
8）Nginx响应请求给用户
二、使用Nginx分发器构建一个WEB集群
1、环境准备
网段:192.168.31.0/24
准备四台实验机：都安装nginx服务，两台当作分发器，两台当作web服务器。
| IP | 角色 |
|---|---|
| 192.168.88.131 | 请求分发服务器 |
| 192.168.88.128 | 业务处理服务器1 |
| 192.168.88.129 | 业务处理服务器2 |
| 192.168.88.130 | 业务处理服务器3 |
2、配置分发器（轮询方式分发）
# 配置nginx.conf
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
# 配置上游服务器
upstream tomcats {
server 192.168.88.128:8080;
server 192.168.88.129:8080;
server 192.168.88.130:8080;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
三、Nginx分发算法
集群分发算法：如何将用户请求按照一定的规律分发给业务服务器。主要分为Nginx集群默认算法和基于请求头分发算法。
1、Nginx集群默认算法
nginx的upstream 目前支持4种方式的分配
（1）轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
（2）weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
（3）ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务，好处是可以解决session的问题。
因此前两种只能处理静态页面，而这种方式可以处理动态网站。
（4）fair(第三方)
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
（5）url_hash(第三方)
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务 ，后端服务器为缓存时比较有效。
2、Nginx业务服务器状态
每个设备的状态设置参数：
down
表示当前的server暂时不参与负载；
upstream tomcats {
server 192.168.88.128:8080 down;
server 192.168.88.129:8080 weight=1;
server 192.168.88.130:8080 weight=2;
}
weight
默认为1，weight越大，负载的权重就越大；
upstream tomcats {
server 192.168.88.128:8080 weight=1;
server 192.168.88.129:8080 weight=1;
server 192.168.88.130:8080 weight=2;
}
slow_start
将服务器慢启动，避免该服务器刚加入集群后，大量流量涌入。实际上就是将权重0 ==> 指定weigth值。注意该模式只对权重weight模式有效
upstream tomcats {
server 192.168.88.128:8080 weight=1;
server 192.168.88.129:8080 weight=1;
server 192.168.88.130:8080 weight=2 slow_start=60s;
}
max_fails
允许请求失败的次数默认为1，当超过最大次数时，返回proxy_next_upstream模块定义的错误；一般与fail_timeout一起使用
fail_timeout
失败超时时间，在连接Server时，如果在超时时间之内超过max_fails指定的失败次数，会认为在fail_timeout时间内Server不可用，且不再参与负载均衡，默认为10s
upstream tomcats {
server 192.168.88.128:8080 max_fails=2 fail_timeout=2s;
server 192.168.88.129:8080 weight=1;
server 192.168.88.130:8080 weight=2;
}
backup
备用，其他所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
3、Nginx集群默认算法测试
集群环境与之前完全相同。
（1）轮询算法分发
upstream tomcats {
server 192.168.88.128:8080;
server 192.168.88.129:8080;
server 192.168.88.130:8080;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
访问测试验证：
前面已经测试验证了轮询算法分发。配置backup参数如下所示：
upstream tomcats {
server 192.168.88.128:8080;
server 192.168.88.129:8080;
server 192.168.88.130:8080 backup;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
关停第一个节点情况，访问尝试：
（2）基于权重的分发
# 1.配置上游服务器 www.tomcats.com
upstream tomcats {
server 192.168.88.128:8080 weight=1;
server 192.168.88.129:8080 weight=1;
server 192.168.88.130:8080 weight=2;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
}
访问测试验证：
通过权重比例的分配，可以让性能更强的服务器承担处理更多的请求。
（3）基于ip_hash分发
ip_hash算法能够保证来自同样源地址的请求都分发到同一台主机。
需要注意：ip_hash算法不支持backup、weight设置。默认权重为1。
# 1.配置上游服务器 www.tomcats.com
upstream tomcats {
ip_hash;
server 192.168.88.128:8080;
server 192.168.88.129:8080;
server 192.168.88.130:8080 down;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
}
访问测试验证：
（4）基于url_hash分发
# 1.配置上游服务器 www.tomcats.com
upstream tomcats {
hash $request_uri;
server 192.168.88.128:8080;
server 192.168.88.129:8080;
server 192.168.88.130:8080 down;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
}
四.keepalive 提高系统吞吐量
upstream tomcats {
server 192.168.88.128:8080;
server 192.168.88.129:8080;
server 192.168.88.130:8080;
keepalive 32;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
五.一致性Hash算法
传统hash算法的弊端
此时各种session等信息各种节点都能完全能够获得。不会有任何问题
当移除tomcat3节点后，由于节点的数量改变，其取模之后的值就会改变，导致不同的用户会进入不同的tomcat节点，此时session等信息，将会无法获取。
当减少服务器节点时，大部分的用户请求，仍然能够正常的访问，少部分的用户请求会因为session丢失，而发生异常
当增加一个服务器节点时，，大部分的用户请求，仍然能够正常的访问，少部分的用户求因为session丢失，而发生异常
