关于后端:高并发系统设计之负载均衡

本文已收录至 Github，举荐浏览 👉 Java 随想录

微信公众号：Java 随想录

CSDN：码农 BookSea

当咱们的利用单实例不能撑持用户申请时，此时就须要扩容，从一台服务器扩容到两台、几十台、几百台。此时咱们就须要负载平衡，进行流量的转发。上面介绍几种负载平衡的计划。

一种是应用 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 负载平衡是通过 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 等）示意服务失常运行。

对于个别利用来说，有 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 设施的价格

╮(╯▽╰)╭ 这玩意要几十万一台，看来不是个别人玩的起的。

本篇文章就到这里，感激浏览，如果本篇博客有任何谬误和倡议，欢送给我留言斧正。文章继续更新，能够关注公众号第一工夫浏览。

关于后端:高并发系统设计之负载均衡

DNS 负载平衡

Nginx 负载平衡

负载平衡算法

负载平衡配置

超时配置

被动健康检查与被动健康检查

LVS/F5+Nginx