vlambda博客
学习文章列表

本文的初衷是为了一边自己复习，一边为了各位读者写一点东西；

本文极度适合巩固基础，面试突击，之后我还会一边复习一边整理出多线程、分布式、高并发、Hadoop、微服务等一类的文章；

不管是大数据方向还是JAVA后端，JAVA、JVM、线程并发这些知识是少不了的。

如果在文章中发现错误，欢迎及时批评指正，若还有尚缺的知识点也可及时提出，本人及时更新。

十四、负载均衡

负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带 宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 

        14.1    四层负载均衡 vs 七层负载均衡

F5：硬件负载均衡，功能很好，但是成本很高。

lvs：重量级的四层负载软件

nginx：轻量级的四层负载软件，带缓存功能，正则表达式比较灵活。

haproxy：模拟四层转发，较灵活

            14.1.2    七层负载均衡（内容交换）

所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容， 再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。 

七层应用负载的好处，是使得整个网络更智能化。例如访问一个网站的用户流量，可以通过七层 的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可 以转发到特定的文字服务器并可以使用压缩技术。实现七层负载均衡的软件有： 

haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；

nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；

apache：功能较差

MySQL：功能尚可

        14.2    负载均衡算法/策略

            14.2.1    轮循均衡（Round Robin）

每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。此种均衡算法适合 于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。 

            14.2.2    权重轮循均衡（Weighted Round Robin）

根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请 求。例如：服务器A的权值被设计成1，B的权值是 3，C的权值是6，则服务器A、B、C将分 别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用 率，避免低性能的服务器负载过重。 

            14.2.3    随机均衡（Random）

把来自网络的请求随机分配给内部中的多个服务器。 

            14.2.4    权重随机均衡

此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。 

            14.2.5    相应速度均衡（Response Time 探测时间）

负载均衡设备对内部各服务器发出一个探测请求（例如Ping），然后根据内部中各服务器对探测 请求的快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映 服务器的当前运行状态，但这快响应时间仅仅指的是负载均衡设备与服务器间的快响应时 间，而不是客户端与服务器间的快响应时间。 

            14.2.6    最少连接数均衡（Least Connection）

最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在 处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数少的服务器，使均衡 更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。  

            14.2.7    处理能力均衡（CPU、内存）

此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大小 及当前连接数等换算而成）轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行 状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层（应用层）负载均衡的情况 下。 

            14.2.8    DNS相应均衡（Flash DNS）

            14.2.9    哈希算法

一致性哈希一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往 该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。 

            14.2.11    URL散列

通过管理客户端请求URL信息的散列，将发送至相同URL的请求转发至同一服务器的算法。 

        14.3    LVS

            14.3.1    LVS原理

IPVS

ipvs ：工作于内核空间，主要用于使用户定义的策略生效 

ipvsadm : 工作于用户空间，主要用于用户定义和管理集群服务的工具 

ipvs 工作于内核空间的 INPUT 链上，当收到用户请求某集群服务时，经过 PREROUTING 链，经 检查本机路由表，送往 INPUT 链；在进入 netfilter 的 INPUT 链时，ipvs 强行将请求报文通过 ipvsadm定义的集群服务策略的路径改为FORWORD链，将报文转发至后端真实提供服务的主机。 

            14.3.2    LVS NAT 模式

注意：在NAT模式中，Real Server的网关必须指向LVS，否则报文无法送达客户端 

特点：

优点：

集群中的物理服务器可以使用任何支持 TCP/IP 操作系统，只有负载均衡器需要一个合法的 IP 地 址。 

缺点：

扩展性有限。当服务器节点（普通PC服务器）增长过多时,负载均衡器将成为整个系统的瓶颈，因 为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇 在负载均衡器那，速度就会变慢！ 

3. RS 发现请求报文中的目的 MAC 是自己，就会将次报文接收下来，处理完请求报文后，将响应 报文通过lo接口送给eth0网卡直接发送给客户端。 

注意：需要设置lo接口的VIP不能响应本地网络内的arp请求。 

总结：

2. 请求的报文经过调度器，而 RS 响应处理后的报文无需经过调度器 LB，因此并发访问量大时使 用效率很高（和 NAT 模式比） 

5. RS 节点的默认网关不需要配置成 LB，而是直接配置为上级路由的网关，能让 RS 直接出网就 可以。 

7. 直接对外的业务比如 WEB 等，RS 的 IP 好是使用公网 IP。对外的服务，比如数据库等好 使用内网IP。 

优点：

和 TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户 端。与 VS-TUN 相比，VS-DR 这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为 物理服务器。 

DR 模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用 haproxy/nginx取代。日1000-2000W PV或者并发请求1万以下都可以考虑用haproxy/nginx

缺点：

所有 RS 节点和调度器 LB 只能在一个局域网里面 

            14.3.4    LVS TUN 模式（IP封装、跨网段）

注意：需要设置lO接口的VIP不能在公共网络上出现。 

总结：

2. TUNNEL 模式的 vip ------>realserver 的包通信通过 TUNNEL 模式，不管是内网和外网都能通 信，所以不需要 lvs vip 跟 realserver 在同一个网段内。 

3. TUNNEL 模式 realserver 会把 packet 直接发给 client 不会给 lvs 了 

4. TUNNEL 模式走的隧道模式，所以运维起来比较难，所以一般不用。 

优点：

负载均衡器只负责将请求包分发给后端节点服务器，而 RS 将应答包直接发给用户。所以，减少了 负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方 式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。 

缺点：

隧道模式的 RS 节点需要合法 IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。 

            14.3.5    LVS FULLAT 模式

无论是 DR 还是 NAT 模式，不可避免的都有一个问题：LVS 和 RS 必须在同一个 VLAN 下，否则 LVS 无法作为 RS 的网关。这引发的两个问题是： 

同一个 VLAN 的限制导致运维不方便，跨 VLAN 的 RS 无法接入。 

1. LVS 的水平扩展受到制约。当 RS 水平扩容时，总有一天其上的单点 LVS 会成为瓶颈。 

2. Full-NAT 由此而生，解决的是 LVS 和 RS 跨 VLAN 的问题，而跨 VLAN 问题解决后，LVS 和 RS 不再存在 VLAN 上的从属关系，可以做到多个 LVS 对应多个 RS，解决水平扩容的问题。 

3. Full-NAT 相比 NAT 的主要改进是，在 SNAT/DNAT 的基础上，加上另一种转换，转换过程如下： 

Full-NAT 主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨 VLAN 的问题。采用这种方式，LVS 和 RS 的部署在 VLAN 上将不再有任何限制，大大提高了运维部署的 便利性。

总结：

1. FULL NAT 模式不需要 LBIP 和 realserver ip 在同一个网段； 

2. full nat 因为要更新 sorce ip 所以性能正常比 nat 模式下降 10% 

        14.4    Keepalive

keepalive 起初是为 LVS 设计的，专门用来监控 lvs 各个服务节点的状态，后来加入了 vrrp 的功 能，因此除了 lvs，也可以作为其他服务（nginx，haproxy）的高可用软件。VRRP 是 virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。VRRP的出现就是为了解决静态路 由出现的单点故障，它能够保证网络可以不间断的稳定的运行。所以 keepalive 一方面具有 LVS cluster node healthcheck功能，另一方面也具有LVS director failover。 

        14.5    Nginx 反向代理负载均衡

普通的负载均衡软件，如LVS，其实现的功能只是对请求数据包的转发、传递，从负载均衡下的节 点服务器来看，接收到的请求还是来自访问负载均衡器的客户端的真实用户；而反向代理就不一样了，反向代理服务器在接收访问用户请求后，会代理用户 重新发起请求代理下的节点服务器， 后把数据返回给客户端用户。在节点服务器看来，访问的节点服务器的客户端用户就是反向代 理服务器，而非真实的网站访问用户。 

            14.5.1    upstream_module 和健康检测

ngx_http_upstream_module 是负载均衡模块，可以实现网站的负载均衡功能即节点的健康检 查，upstream模块允许Nginx定义一组或多组节点服务器组，使用时可通过 proxy_pass 代理方 式把网站的请求发送到事先定义好的对应 Upstream组 的名字上。 

            14.5.2    proxy_pass 请求转发

proxy_pass 指令属于 ngx_http_proxy_module 模块，此模块可以将请求转发到另一台服务器， 在实际的反向代理工作中，会通过 location 功能匹配指定的 URI，然后把接收到服务匹配 URI 的 请求通过proyx_pass抛给定义好的upstream节点池。 

 location /download/ {
 proxy_pass http://download/vedio/;
}
#这是前端代理节点的设置

本文可能会有所更新，之后还会推出一系列的相关文章，请持续关注大数据健身侠！