高并发高负载高可用（高并发系统设计之负载均衡）
本文已收录至Github ，推荐阅读 ? Java随想录
微信公众号：Java随想录
CSDN： 码农BookSea
当我们的应用单实例不能支撑用户请求时 ，此时就需要扩容 ，从一台服务器扩容到两台 、几十台 、几百台 。此时我们就需要负载均衡 ，进行流量的转发 。下面介绍几种负载均衡的方案 。
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设备的价格
╮(╯▽╰)╭ 这玩意要几十万一台 ，看来不是一般人玩的起的 。
本篇文章就到这里 ，感谢阅读 ，如果本篇博客有任何错误和建议 ，欢迎给我留言指正 。文章持续更新 ，可以关注公众号第一时间阅读 。
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！