为什么做负载均衡
|
1 |
当我们的Web服务器直接面向用户，往往要承载大量并发请求，单台服务器难以负荷，我使用多台Web服务器组成集群，前端使用Nginx负载均衡，将请求分散的打到我们的后端服务器集群中，实现负载的分发。那么会大大提升系统的吞吐率、请求性能、高容灾 |
|
1 2 3 |
往往我们接触的最多的是SLB(Server Load Balance)负载均衡，实现最多的也是SLB、那么SLB它的调度节点和服务节点通常是在一个地域里面。那么它在这个小的逻辑地域里面决定了他对部分服务的实时性、响应性是非常好的。 所以说当海量用户请求过来以后，它同样是请求调度节点，调度节点将用户的请求转发给后端对应的服务节点，服务节点处理完请求后在转发给调度节点，调度节点最后响应给用户节点。这样也能实现一个均衡的作用，那么Nginx则是一个典型的SLB |
公有云中负载均衡的叫法
|
1 2 3 4 |
1.SLB 阿里云产品 2.LB 青云产品 3.CLB 腾讯云产品 4.ULB ucloud产品 |
常见的负载均衡软件
|
1 2 3 4 5 6 7 8 9 |
Nginx Haproxy LVS #LVS是最快的负载均衡软件 #LVS四种网络模式 #LVS DR模式 #LVS NAT模式 #LVS FULLNAT模式 #LVS TUN原理 |
负载均衡类型
|
1 2 3 4 5 |
1.四层负载均衡 所谓四层负载均衡指的是OSI七层模型中的传输层，那么传输层Nginx已经能支持TCP/IP的控制，所以只需要对客户端的请求进行TCP/IP协议的包转发就可以实现负载均衡，那么它的好处是性能非常快、只需要底层进行应用处理，而不需要进行一些复杂的逻辑。 2.七层负载均衡 七层负载均衡它是在应用层，那么它可以完成很多应用方面的协议请求，比如我们说的http应用的负载均衡，它可以实现http信息的改写、头信息的改写、安全应用规则控制、URL匹配规则控制、以及转发、rewrite等等的规则，所以在应用层的服务里面，我们可以做的内容就更多，那么Nginx则是一个典型的七层负载均衡SLB |
Nginx 调度算法
| 调度算法 | 概述 |
|---|---|
| 轮询 | 按时间顺序逐一分配到不同的后端服务器(默认) |
| weight | 加权轮询,weight值越大,分配到的访问几率越高 |
| ip_hash | 每个请求按访问IP的hash结果分配,这样来自同一IP的固定访问一个后端服务器 |
| url_hash | 按照访问URL的hash结果来分配请求,是每个URL定向到同一个后端服务器 |
| least_conn | 最少链接数,那个机器链接数少就分发 |
负载均衡后端状态
| 状态 | 概述 |
|---|---|
| down | 当前的server暂时不参与负载均衡 |
| backup | 预留的备份服务器 |
| max_fails | 允许请求失败的次数 |
| fail_timeout | 经过max_fails失败后, 服务暂停时间 |
| max_conns | 限制最大的接收连接数 |
down状态配置测试
|
1 2 3 4 5 6 |
[root@lb01 ~]# vim /etc/nginx/conf.d/proxy.conf upstream web { server 172.16.1.7:80 down; server 172.16.1.9:80; } #一般在代码上线或维护服务器时使用该状态 |
backup状态测试
|
1 2 3 4 5 6 7 |
[root@lb01 ~]# vim /etc/nginx/conf.d/proxy.conf upstream web { server 172.16.1.7:80; server 172.16.1.9:80; server 172.16.1.10:80 backup; server 172.16.1.11:80 backup; } |
max_fails配置
|
1 2 3 4 5 |
[root@lb01 ~]# vim /etc/nginx/conf.d/proxy.conf upstream web { server 172.16.1.7:80 max_fails=3 fail_timeout=10s; server 172.16.1.9:80; } |
测试max_conns最大TCP连接数
|
1 2 3 4 5 |
[root@lb01 ~]# vim /etc/nginx/conf.d/proxy.conf upstream web { server 172.16.1.7:80 max_conns=10; server 172.16.1.9:80; } |