nginx集群

集群四层负载均衡七层负载均衡DNS地域负载均衡 负载均衡配置负载均衡-轮询负载均衡-加权轮询upstream 指令参数使用Keepalive提高吞吐量负载均衡 之 ip_hashhash算法hash算法带来的问题 一致性哈希算法负载均衡之url_hash负载均衡之least_conn

集群

四层负载均衡

基于IP＋端口的四层负载均衡，基于TCP/IP，通过转发请求到后台的服务器。 分类： 1. F5硬负载均衡 2. LVS四层负载均衡 3. Haproxy四层负载均衡 4. Nginx四层负载均衡

七层负载均衡

基于URL或IP，基于应用层的，HTTP协议的负载均衡 分类： 1. Nginx七层负载均衡 2. Haproxy七层负载均衡 3. apache七层负载均衡

DNS地域负载均衡

就近原则IP地址

负载均衡配置

#配置上游服务器 upstream nginxs { server 172.16.44.4; server 172.16.44.5; server 172.16.44.6; } server { listen 80; server_name www.zk03.com; location / { proxy_pass http://nginxs; } } 其中本虚拟机为172.16.44.3，起到反向代理的功能

负载均衡-轮询

默认为轮询:平均分配

负载均衡-加权轮询

#配置上游服务器 upstream nginxs { server 172.16.44.4:80 weight=1; #默认为1 server 172.16.44.5:80 weight=2; server 172.16.44.6:80 weight=5; } server { listen 80; server_name www.zk03.com; location / { proxy_pass http://nginxs; } }

upstream 指令参数

max_conns 限制一台服务器的最大连接数，用于保护避免过载,限流作用 #配置上游服务器 upstream nginxs { server 172.16.44.4:80 max_conns=2; server 172.16.44.5:80 max_conns=2; server 172.16.44.6:80 max_conns=2; } server { listen 80; server_name www.zk03.com; location / { proxy_pass http://nginxs; } } 仅测试为max_conns=2，实际生产环境设置要大 slow_start 缓慢的开启，而不是一下启动起来，让所有的流量都能够访问到。假设权重是10，会从0开始慢慢升值到10. 不适用单个server，用集群，需要配置权重 该参数不能使用在hash和randomloadbalancing中。 如果在 upstream 中只有一台 server，则该参数失效。 #配置上游服务器 upstream nginxs { server 172.16.44.4:80 weight=6 slow_start=60s; server 172.16.44.5:80 weight=2; server 172.16.44.6:80 weight=2; } server { listen 80; server_name www.zk03.com; location / { proxy_pass http://nginxs; } }

报错原因：商业版的nginx才可以使用这个参数

down down表示服务器不可用backup 表示服务器是备用机，表示其他全部服务器挂掉之后，才会使用到max_files 表示失败几次，则标记server已宕机，剔出上游服务fail_timeout 表示失败的重试时间max_fails=2 fail_timeout=15s 则代表在15秒内请求某一server失败达到2次后，则认为该server已经挂了或者宕机了，随后再过15秒，这15秒内不会有新的请求到达刚刚挂掉的节点上，而是会运作的server，15秒后会再有新请求尝试连接挂掉的server，如果还是失败，重复上一过程，直到恢复

使用Keepalive提高吞吐量

keepalive：设置长连接处理的数量 proxy_http_version：设置长连接http版本为1.1 proxy_set_header：清除connection header 信息

#配置上游服务器 upstream nginxs { server 172.16.44.3:80; # server 172.16.44.4:80 backup; # server 172.16.44.5:80 weight=1; # server 172.16.44.6:80 weight=1; keepalive 32; } server { listen 80; server_name www.zk03.com; location / { proxy_pass http://nginxs; proxy_http_version 1.1; proxy_set_header Connection ""; } }

负载均衡 之 ip_hash

ip_hash可以保证用户访问可以请求到上游服务中的固定的服务器，前提是用户ip没有发生更改。会话会到同一台服务器中，不会打到其他服务器中的。 使用ip_hash的注意点：不能把后台服务器直接移除，只能标记down

#配置上游服务器 upstream nginxs { ip_hash; server 172.16.44.3:80; server 172.16.44.4:80; server 172.16.44.5:80 down; server 172.16.44.6:80; } server { listen 80; server_name www.zk03.com; location / { proxy_pass http://nginxs; } }

hash算法

hash(ip) % node_counts = index

hash算法带来的问题

如果有个服务器发生宕机，节点发生更改，之前的取模都要重新计算。无论是增加或者减少节点，都要进行重新计算，用户里面的会话全部都会丢失。用户请求的时间比原先更多。解决：一致性哈希算法

一致性哈希算法

定义一个水平线，开头和结尾为0和2的32次方-1，相当于是地址，0是起始位置，本质是一个环形，从0开始形成一个闭环，服务器进行hash算法放到环形一个地址，按照环的顺时针方向一个一个去放，服务器都有一个特定的位置，都是顺时针的方向，用户也是通过一个hash去算的，也是环上的一个节点，有一个规则，用户顺时针去访问服务器的节点，可以保证用户访问特定的节点，并且是就近原则。 如果减少、增加服务器(宕机、挂掉)，只会影响少量的用户，他们的会话、缓存对丢失。 作用：保证绝大部分的用户还是访问原先的计算机节点，仅仅影响部分用户

负载均衡之url_hash

hash(url) % node_counts = index 缺点：大量请求一个接口，会导致服务器过热 注意：www.zk03.com/hello 才会用到url_hash算法www.zk03.com/hello/不会用到

#配置上游服务器 upstream nginxs { hash $request_uri; server 172.16.44.3:80; server 172.16.44.4:80; server 172.16.44.5:80; server 172.16.44.6:80; } server { listen 80; server_name www.zk03.com; location / { proxy_pass http://nginxs; } }

负载均衡之least_conn

最少的连接数

#配置上游服务器 upstream nginxs { least_conn; server 172.16.44.3:80; server 172.16.44.4:80; server 172.16.44.5:80; server 172.16.44.6:80; } server { listen 80; server_name www.zk03.com; location / { proxy_pass http://nginxs; } }