高并发系统设计之负载均衡
本文已收录至Github，推荐阅读 Java随想录
文章目录
- DNS负载均衡
- Nginx负载均衡
-
- 负载均衡算法
- 负载均衡配置
- 超时配置
- 被动健康检查与主动健康检查
- LVS/F5+Nginx
当我们的应用单实例不能支撑用户请求时，此时就需要扩容，从一台服务器扩容到两台、几十台、几百台。此时我们就需要负载均衡，进行流量的转发。下面介绍几种负载均衡的方案。
DNS负载均衡
一种是使用DNS负载均衡，将域名映射多个IP。
用户访问时是通过如 https://www.baidu.com 的方式访问，在请求时，浏览器首先会查询DNS服务器获取对应的IP，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。
DNS还可以设置权重，我们可以将配置比较好的机器设置为高权重。
具体配置可以参考阿里云官方文档：阿里云DNS负载均衡权重配置
- 优点：配置简单，将负载均衡的工作交给了DNS服务器，省去了管理的麻烦。
- 缺点：DNS会有一定的缓存时间，故障后切换时间长。
DNS存在一个问题，假设某台服务器重启或者出现故障，DNS会有一定的缓存时间，故障后切换时间长，而且没有对后端服务进行心跳检查和失败重试的机制。
例如：DNS缓存了A记录，假设我有一台服务器坏了需要下线，即使修改了A记录，要使其生效也需要较长的时间，这段时间，DNS仍然会将域名解析到已下线的服务器上，最终导致用户访问失败。
关于DNS缓存多久时间生效，可以参考阿里云的帮助文档：解析生效时间FAQ
Nginx负载均衡
负载均衡算法
一般用Nginx来做负载均衡比较多。
Nginx负载均衡是通过upstream模块来实现的，内置实现了三种负载策略，配置还是比较简单的。
-
轮循（默认）
Nginx根据请求次数，将每个请求均匀分配到每台服务器。
-
最少连接
将请求分配给连接数最少的服务器。Nginx会统计哪些服务器的连接数最少。
-
IP Hash
每个请求按访问IP的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session共享的问题。
-
fair（第三方模块）
根据服务器的响应时间来分配请求，响应时间短的优先分配，即负载压力小的优先会分配。
需要安装nginx-upstream-fair模块
-
url_hash（第三方模块）
按访问的URL的哈希结果来分配请求，使每个URL定向到一台后端服务器，如果需要这种调度算法，则需要安装nginx_upstream_hash模块。
-
一致性哈希（第三方模块）
ip_hash算法，在增加和服务器宕机时会导致会话和缓存丢失。如果需要使用一致性哈希，则需要安装ngx_http_consistent_hash模块。
负载均衡配置
示例配置如下：
http {
upstream myserve {
# ip_hash; 表示使用ip hash负载均衡策略
server 192.168.0.100:8080 weight=1 max_fails=2 fail_timeout=10;;
server 192.168.0.101:8080 weight=2;
server 192.168.0.102:8080 weight=3;
# server 192.168.0.102:8080 backup;
# server 192.168.0.102:8080 down;
# server 192.168.0.102:8080 max_conns=100;
}
server {
listen 80;
location / {
proxy_pass http://myserve;
}
}
}
- weight：weight是权重的意思，上例配置，表示6次请求中，分配1次，2次和3次。
- max_fails：允许请求失败的次数，默认为1。超过max_fails后，在fail_timeout时间内，新的请求将不会分配给这台机器。
- fail_timeout：默认为10秒，上诉代码配置表示失败2次之后，10秒内 192.168.0.100:8080不会处理新的请求。
- backup：备份机，所有服务器挂了之后才会生效，如配置文件注释部分，只有192.168.0.100和192.168.0.101都挂了，才会启用192.168.0.102。
- down：表示某一台服务器不可用，不会将请求分配到这台服务器上，该状态的使用场景是某台服务器需要停机维护时设置为down，或者发布新功能时。
- max_conns：限制分配给某台服务器处理的最大连接数量，超过这个数量，将不会分配新的连接给它。默认是0，表示不限制最大连接。它所起到的作用是防止服务器因连接过多而导致宕机，比如我给192.168.0.102分配100个连接请求，如果这台服务器正在处理100个请求，nginx将不会分配新的请求给它。也就是同时处理的最大连接数量。
超时配置
- proxy_connect_timeout：后端服务器连接的超时时间，默认是60秒。
- proxy_read_timeout：连接成功后等候后端服务器响应时间，也可以说是后端服务器处理请求的时间，默认是60秒。
- proxy_send_timeout：发送超时时间，默认是60S
被动健康检查与主动健康检查
Nginx负载均衡有个缺点，就是说Nginx的服务检查是惰性的，Nginx只有当有访问时后，才发起对后端节点探测。如果本次请求中，节点正好出现故障，Nginx依然将请求转交给故障的节点，然后再转交给健康的节点处理。所以不会影响到这次请求的正常进行。但是会影响效率，因为多了一次转发，而且自带模块无法做到预警。
也就是说Nginx自带的健康检查是被动的。
如果我们想主动的去进行健康检查，需要使用淘宝开源的第三方模块：nginx_upstream_check_module。
Nginx会定时主动地去ping后端的服务列表，当发现某服务出现异常时，把该服务从健康列表中移除，当发现某服务恢复时，又能够将该服务加回健康列表中。
示例配置如下：
upstream myserver {
server 192.168.0.100:8080;
server 192.168.0.101:8080;
check interval=5000 rise=2 fall=5 timeout=1000 type=http;
check_http_send"HEAD / HTTP/1.0\r\n\r\n"; check_http_expect_alive http_2xx http_3xx;
}
interval间隔5s，连续失败5次，连续成功2次，超时时间1s，使用http协议，发送一个请求头，如果是2xx或者3xx状态（比如200,302等）表示服务正常运行。
LVS/F5+Nginx
对于一般应用来说，有Nginx就可以了。但Nginx一般用于七层负载均衡，其吞吐量是有一定限制的。为了提升整体吞吐量，会在 DNS 和 Nginx之间引入接入层，如使用LVS（软件负载均衡器)、F5（硬负载均衡器）可以做四层负载均衡，即首先 DNS解析到LVS/F5，然后LVS/F5转发给Nginx，再由Nginx转发给后端真实服务器。
比较理想的架构是这样的：
对于一般业务开发人员来说，我们只需要关心到Nginx层面就够了，LVS/F5一般由系统/运维工程师来维护。Nginx目前提供了HTTP (ngx_http_upstream_module）七层负载均衡，而1.9.0版本也开始支持TCP(ngx_stream_upstream_module)四层负载均衡。
一般用到F5的公司不多，大部分LVS+Nginx就可以搞定。
另外我抱着好奇心去谷歌了下F5设备的价格
╮(╯▽╰)╭ 这玩意要几十万一台，看来不是一般人玩的起的。
本篇文章就到这里，感谢阅读，如果本篇博客有任何错误和建议，欢迎给我留言指正。