解说基于开源负载均衡的工作原理（负载均衡实现原理）

概要

负载均衡是对多台业务服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性，是构建集群的核心，例如Web集群、数据库集群、分布式缓存服务器集群等，负载均衡通常为四层（TCP/UDP），七层（HTTPS/HTTP）.

一、 负载均衡架构示意图：

1.1、 下面将以Web服务器集群来讨论负载均衡工作原理

在实际生产环境，Web应用集群的上层会部署负载一套负载均衡服务器（通常为高可用模式，常用的高可用组件keepalive，Heartbeat等），负载均衡的任务是作为web服务器流量的入口，负载均衡根据设置的轮询计算模式选择一台后端WebServer，将客户端请求转发到指定的服务器进行处理，实现Client与Server端的透明转发。

1.1.1、 Nginx、Lvs、 Haproxy是目前使用最广泛的开源负载均衡软件。

1、 Nginx：专为性能优化而开发，Nginx在反向代理、Rewrite规则、稳定性、静态文件处理，内存消耗等方面，有很强的优势，使用Nginx取代传统的Apache服务器，会得到多方面的性能提升,官方测试报告表明能支持高达 50,000个并发连接数。（目前1.11以后支持UDP负载均衡）

2、HAProxy 是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。 HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上，完全可以支持数以万计的 并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。

3、LVS工作在四层，可以实现高性能，高可用的服务器集群技术。它易用，配置非常简单，且有多种负载均衡的方法。其性能接近硬件负载均衡F5设备。

一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的 Web 应用，

比如日 PV 小于1000万，用 Nginx 就完全可以了；如果机器不少，可以用 DNS 轮询，LVS 所耗费的机器还是比较多的；大型网站或重要的服

务，且服务器比较多时，可以考虑用 LVS。

1.1.2、目前网站架构一般比较通用流行的架构方案：

1.  Web 前端采用 Nginx/HAProxy+Keepalived 作负载均衡器

2.  后端数据库采用 MySQL数据库一主多从和读写分离，采用 LVS+Keepalived 的架构。（MySQL自带主从设置，如何理解用LVS？）

1.1.3、LVS简述：

LVS 是 Linux Virtual Server 的简称，也就是 Linux 虚拟服务器。现在 LVS 已经是 Linux 标准内核的一部分，从 Linux2.4 内核以后，

已经完全内置了 LVS 的各个功能模块，无需给内核打任何补丁，可以直接使用 LVS 提供的各种功能。

1.1.4、LVS体系架构：

1.1.5、LVS结构：

1. 负载调度器(Load Blancer):是整个LVS集群对外的前端机器，负责敬爱嗯client的请求发送到一组服务器【多台 LB IP】上执行，

而client则认为返回来是同一个IP(通常把这个IP成为虚拟ip或VIP)

2. 服务器池(server pool):一组真正执行clinet请求的服务器，一般是web服务器；除了web，还有FTP、MAIL、DNS等

3. 共享存储(shared stord):它为server pool提供了一个共享的存储区，很容易让服务器池拥有相同的内容，提供相同的服务

1.1.6、LVS负载均衡工作原理

1. LVS DR模式

LVS DR原理：

用户请求LVS到达director，director将请求的报文的目的MAC地址改为后端的realserver的MAC地址，目的IP为VIP(不变)，源IP为client IP地址(不变)，然后director将报文发送到realserver，realserver检测到目的地址为自己本地的VIP，如果在同一网段，将请求直接返回给用户，如果用户跟realserver不在同一个网段，则需要通过网关返回给用户。

LVS DR特性：

前端路由将目标地址为VIP报文统统发给Director Server

RS跟Director Server必须有一个网卡在同一个物理网络中

所有的请求报文经由Director Server，但响应报文必须不能进过Director Server

所有的real server机器上都有VIP地址

2. LVS NAT模式

LVS NAT原理：

用户请求LVS到达director，director将请求的报文的目的IP改为RIP，同时将报文的目标端口也改为realserver的相应端口，最后将报文发送到realserver上，realserver将数据返回给director，director再把数据发送给用户

LVS NAT特性：

NAT模式修改的是目的ip，直接走的是switch不需要修改mac地址，所以VIP和RIP不需要在同一个网段内

NAT的包的进出都需要经过LVS，所以LVS可能会成为一个系统的瓶颈问题

3.  LVS TUN模式：

LVS TUN原理：

用户请求LVS到达director，director通过IP-TUN加密技术将请求报文的包封装到一个新的IP包里面，目的IP为VIP(不变)，然后director将报文发送到realserver，realserver基于IP-TUN解密，然后解析出来包的目的为VIP，检测网卡是否绑定了VIP，绑定了就处理这个包，如果在同一个网段，将请求直接返回给用户，否则通过网关返回给用户；如果没有绑定VIP就直接丢掉这个包

LVS TUN特性：

1. TUNNEL必须在所有的realserver上绑定VIP

2. realserver直接把包发给client

3. 隧道模式运维起来会比较难，所以一般不用

1.1.7、 LVS模式比较（此处我们这边只针对以上三种模式进行比较，不针对FULLNAT模式进行介绍）

1. 是否需要VIP和realserver在同一网段，DR模式因为只修改包的MAC地址，需要通过ARP广播找到realserver，

所以VIP和realserver必须在同一个网段，也就是说DR模式需要先确认这个IP是否只能挂在这个LVS下面；其他

模式因为都会修改目的地址为realserver的IP地址，所以不需要在同一个网段内。

2. 是否需要在realserver上绑定VIP，realserver在收到包之后会判断目的地址是否

是自己的IP，DR模式的目的地址没有修改，还是VIP，所以需要在realserver上绑定VIP

IP TUN模式值是对包重新包装了一层，realserver解析后的包的IP仍然是VIP，所以也需要在realserver上绑定VIP

3. 四种模式的性能比较

DR模式、IP TUN模式都是在包进入的时候经过LVS，在包返回的时候直接返回给client；所以二者的性能比NAT高

但TUN模式更加复杂，所以性能不如DR

注：FULLNAT模式不仅更换目的IP还更换了源IP，所以性能比NAT下降10%（故生产环境也很少使用该模式）在此不做介绍

性能比较：DR>TUN>NAT>FULLNAT

1.1.8、LVS负载均衡算法

1. 轮叫调度 rr

均等地对待每一台服务器，不管服务器上的实际连接数和系统负载

2. 加权轮叫 wrr

调度器可以自动问询真实服务器的负载情况，并动态调整权值

3. 最少链接 lc

动态地将网络请求调度到已建立的连接数最少的服务器上

如果集群真实的服务器具有相近的系统性能，采用该算法可以较好的实现负载均衡

4. 加权最少链接 wlc

调度器可以自动问询真实服务器的负载情况，并动态调整权值

带权重的谁不干活就给谁分配，机器配置好的权重高

5. 基于局部性的最少连接调度算法 lblc

这个算法是请求数据包的目标 IP 地址的一种调度算法，该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器，

如果这台服务器依然可用，并且有能力处理该请求，调度器会尽量选择相同的服务器，否则会继续选择其它可行的服务器

6. 复杂的基于局部性最少的连接算法 lblcr

记录的不是要给目标 IP 与一台服务器之间的连接记录，它会维护一个目标 IP 到一组服务器之间的映射关系，防止单点服务器负载过高。

7. 目标地址散列调度算法 dh

该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系，出现服务器不可用或负载过高的情况下，发往该目标 IP 的请求会固定发给该服务器。

8. 源地址散列调度算法 sh

与目标地址散列调度算法类似，但它是根据源地址散列算法进行静态分配固定的服务器资源。

9. 最少期望延迟 sed

不考虑非活动链接，谁的权重大，优先选择权重大的服务器来接收请求，但权重大的机器会比较忙

10. 永不排队 nq

无需队列，如果有realserver的连接数为0就直接分配过去

1.1.9、 LVS 的优点

1. 抗负载能力强、工作在传输层上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和 cpu 资源消耗

比较低。

2. 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。

3. 工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如 LVS+Keepalived。

4. 无流量，LVS 只分发请求，而流量并不从它本身出去，这点保证了均衡器 IO 的性能不会受到大流量的影响。

5. 应用范围比较广，因为 LVS 工作在传输层，所以它几乎可以对所有应用做负载均衡，包括 http、数据库、在线聊天室等等。

1.1.10、LVS 的缺点

1. 软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是 Nginx、HAProxy+Keepalived

的优势所在。

2. 如果是网站应用比较庞大的话，LVS/DR+Keepalived 实施起来就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了

2.1、Nginx简述：

Nginx 是一个强大的 Web 服务器软件，用于处理高并发的 HTTP 请求和作为反向代理服务器做负载均衡。具有高性能、轻量级、内存消耗少，强大的负载均衡能力等优势。

2.1.1、Nginx架构设计

Nginx服务器启动后，产生一个主进程（master process），主进程执行一系列工作后产生一个或者多个工作进程（worker processes)。主进程主要进行Nginx配置文件解析、数据结构初始化、模块配置和注册、信号处理、网络监听生成、工作进程主要进行进程初始化、模块调用和请求处理等工作，是Nginx服务器提供服务的主体。

在客户端请求动态站点的过程中，Nginx服务器还涉及和后端服务器的通信。Nginx服务器还涉及和后端服务器的通信。Nginx服务器将接收到的Web请求通过代理转发到后端服务器，由后端服务器进行数据处理和页面组织，然后将结果返回。

另外，Nginx服务器为了提高对请求的响应效率，进一步降低网络压力，采用了缓存机制，将历史应答数据缓存到本地。在每次Nginx服务器启动后的一段时间内，会启动专门的进程对本地缓存的内容重建索引，保证对缓存文件的快速访问。

根据上面的分析，我们可以将Nginx服务器的结构大致分为主进程、工作进程、后端服务器和缓存等部分。

Nginx架构设计图

Nginx常用部署架构

2.1.2、Nginx 负载均衡模式

Nginx 负载均衡主要是对四层、七层网络通信模型中的四层（TCP/UDP(1.11以上)）/七层应用层上的 http、https 进行支持。

Nginx 是以反向代理的方式进行负载均衡的。反向代理（Reverse Proxy）方式是指以代理服务器来接受 Internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

Nginx 实现负载均衡的分配策略有很多，Nginx 的 upstream 目前支持以下几种方式：

轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。

weight：指定轮询几率，weight 和访问比率成正比，用于后端服务器性能不均的情况。

ip_hash：每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。

fair（第三方）：按后端服务器的响应时间来分配请求，响应时间短的优先分配。

url_hash（第三方）：按访问 url 的 hash 结果来分配请求，使每个 url 定向到同一个后端服务器，后端服务器为缓存时比较有效。

2.1.3、Nginx 的优点

跨平台：Nginx 可以在大多数 Unix like OS编译运行，而且也有 Windows 的移植版本

配置异常简单：非常容易上手。配置风格跟程序开发一样，神一般的配置

非阻塞、高并发连接：官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数

事件驱动：通信机制采用 epoll 模型，支持更大的并发连接

Master/Worker 结构：一个 master 进程，生成一个或多个 worker 进程

内存消耗小：处理大并发的请求内存消耗非常小。在3万并发连接下，开启的10个 Nginx 进程才消耗150M 内存（15M*10=150M）

内置的健康检查功能：如果 Nginx 代理的后端的某台 Web 服务器宕机了，不会影响前端访问

节省带宽：支持 GZIP 压缩，可以添加浏览器本地缓存的 Header 头

稳定性高：用于反向代理，宕机的概率微乎其微

2.1.4、Nginx 的缺点

对后端服务器的健康检查，只支持通过端口来检测，不支持通过 ur l来检测。

不支持 Session 的直接保持，但能通过 ip_hash 来解决

3.1、 Haproxy简述

HAProxy 是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。 HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上，完全可以支持数以万计的 并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。

HAProxy 实现了一种事件驱动、单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。

HAProxy 支持连接拒绝 : 因为维护一个连接的打开的开销是很低的，有时我们很需要限制攻击蠕虫（attack bots），也就是说限制它们的连接打开从而限制它们的危害。 这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救了很多站点，这个优点也是其它负载均衡器没有的。

HAProxy 支持全透明代理（已具备硬件防火墙的典型特点）: 可以用客户端IP地址或者任何其他地址来连接后端服务器. 这个特性仅在Linux 2.4/2.6内核打了cttproxy补丁后才可以使用. 这个特性也使得为某特殊服务器处理部分流量同时又不修改服务器的地址成为可能。

3.1.1、 性能

HAProxy借助于OS上几种常见的技术来实现性能的最大化。

单进程、事件驱动模型显著降低了上下文切换的开销及内存占用。

O(1)事件检查器(event checker)允许其在高并发连接中对任何连接的任何事件实现即时探测。

在任何可用的情况下，单缓冲(single buffering)机制能以不复制任何数据的方式完成读写操作，这会节约大量的CPU时钟周期及内存带宽；

借助于Linux 2.6 (>= 2.6.27.19)上的splice()系统调用，HAProxy可以实现零复制转发(Zero-copy forwarding)，在Linux 3.5及以上的OS中还可以实现零复制启动(zero-starting)；

内存分配器在固定大小的内存池中可实现即时内存分配，这能够显著减少创建一个会话的时长；

优化的HTTP首部分析：优化的首部分析功能避免了在HTTP首部分析过程中重读任何内存区域；

精心地降低了昂贵的系统调用，大部分工作都在用户空间完成，如时间读取、缓冲聚合及文件描述符的启用和禁用等；

所有的这些细微之处的优化实现了在中等规模负载之上依然有着相当低的CPU负载，甚至于在非常高的负载场景中，5%的用户空间占用率和95%的系统空间占用率也是非常普遍的现象，这意味着HAProxy进程消耗比系统空间消耗低20倍以上。因此，对OS进行性能调优是非常重要的。即使用户空间的占用率提高一倍，其CPU占用率也仅为10%，这也解释了为何7层处理对性能影响有限这一现象。由此，在高端系统上HAProxy的7层性能可轻易超过硬件负载均衡设备。

在生产环境中，在7层处理上使用HAProxy作为昂贵的高端硬件负载均衡设备故障故障时的紧急解决方案也时长可见。硬件负载均衡设备在“报文”级别处理请求，这在支持跨报文请求(request across multiple packets)有着较高的难度，并且它们不缓冲任何数据，因此有着较长的响应时间。对应地，软件负载均衡设备使用TCP缓冲，可建立极长的请求，且有着较大的响应时间。

3.1.2、Haproxy调度算法

roundrobin

基于权重进行轮叫，在服务器的处理时间保持均匀分布时，这是最平衡、最公平的算法。此算法是动态的，这表示其权重可以在运行时进行调整，不过，在设计上，每个后端服务器仅能最多接受4128个连接

static-rr

基于权重进行轮叫，与roundrobin类似，但是为静态方法，在运行时调整其服务器权重不会生效；不过，其在后端服务器连接数上没有限制

leastconn

新的连接请求被派发至具有最少连接数目的后端服务器；在有着较长时间会话的场景中推荐使用此算法，如LDAP、SQL等，其并不太适用于较短会话的应用层协议，如HTTP；此算法是动态的，可以在运行时调整其权重

source

将请求的源地址进行hash运算，并由后端服务器的权重总数相除后派发至某匹配的服务器；这可以使得同一个客户端IP的请求始终被派发至某特定的服务器；不过，当服务器权重总数发生变化时，如某服务器宕机或添加了新的服务器，许多客户端的请求可能会被派发至与此前请求不同的服务器；常用于负载均衡无cookie功能的基于TCP的协议；其默认为静态，不过也可以使用hash-type修改此特性

uri

对URI的左半部分(“问题”标记之前的部分)或整个URI进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器；这可以使得对同一个URI的请求总是被派发至某特定的服务器，除非服务器的权重总数发生了变化；此算法常用于代理缓存或反病毒代理以提高缓存的命中率；需要注意的是，此算法仅应用于HTTP后端服务器场景；其默认为静态算法，不过也可以使用hash-type修改此特性

uri-param

通过为URL指定的参数在每个HTTP GET请求中将会被检索；如果找到了指定的参数且其通过等于号“=”被赋予了一个值，那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器；此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器，除非服务器的总权重发生了变化；如果某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度；此算法默认为静态的，不过其也可以使用hash-type修改此特性

hdr(name)

对于每个HTTP请求，通过指定的HTTP首部将会被检索；如果相应的首部没有出现或其没有有效值，则使用轮叫算法对相应请求进行调度；其有一个可选选项“use_domain_only”，可在指定检索类似Host类的首部时仅计算域名部分(比如通过www.jinjianginns.com来说，仅计算jinjianginns字符串的hash值)以降低hash算法的运算量；此算法默认为静态的，不过其也可以使用hash-type修改此特性

rdp-cookie(name)

表示根据据 cookie(name)来锁定并哈希每一次 TCP 请求。

3.1.3、Haproxy优点

支持8中负载均衡算法，同时也支持session会话保持

可靠性和稳定性可以硬件级的F5相媲美

最高可以同时处理40000~50000个并发连接，单位时间内处理最大的请求出可达20000个

Haproxy是基于第三方应用实现的负载均衡，工作四层和七层的负载均衡软件，可以实现tcp和http应用的负载均衡解决方案

在状态检测方面功能强大，可支持端口，url以及脚本等多种状态检测方式

3.1.4、 Haproxy缺点

haproxy安装简单，但是配置复杂

整体处理能力要低于四层负载均衡的LVS，和lvs相比，lvs拥有接近硬件设备的网络吞吐量和连接负载能力

4

4.1、 Keepalive简述：

Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。

Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件。

Keepalived采用模块化设计，不同模块实现不同的功能

Keepalivd主要有三个模块，分别是core，check，vrrp

core：是Keepalived的核心，负责主进程的启动和维护，全局配置文件的加载解析等

check：负责healthchecker（健康检查）

vrpp：VRRPD子进程，VRRPD子进程就是来实现VRRP协议的

4.1.1、 Keepalive工作原理：

通过vrrp协议广播，每个keepalived vrrp都去争取master

以virtual_router_id为组队标识。  同为一个vip服务的keepalived的virtual_router_id相同

以priority 为权值，同一个virtual_router_id下那个priority大那个就是master,其它为backup

在Keepalived服务正常工作时，主master节点会不断的向备节点发送心跳信息，用来告诉备Backup节点自己还活着，当主master节点发生故障时候，就无法发送心跳信息了，备节点也就因此无法继续检测到来自主 Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的 IP资源及服务。而当主 Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。

4.1.2、 keeplive脑裂与解决思路：

keepalive产生脑裂有以下几种原因：

高可用服务器对之间心跳线链路发生故障，导致无法正常通信。

心跳线坏了（包括断了，老化）。

网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）。

心跳线间连接的设备故障（网卡及交换机）。

仲裁的机器出问题（采用仲裁的方案）。

高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。

高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败。

其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等。

Keepalived配置里VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生。

keepalive解决脑裂思路：

同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个还是好的，依然能传送心跳消息。

当检测到裂脑时强行关闭一个心跳节点（这个功能需特殊设备支持，如Stonith、feyce）。相当于备节点接收不到心跳消患，通过单独的线路发送关机命令关闭主节点的电源。

做好对裂脑的监控报警（如邮件及手机短信等或值班）.在问题发生时人为第一时间介入仲裁，降低损失。

管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器.让服务器根据指令自动处理相应故障这样解决故障的时间更短。

4.1.3 当前keepalive与Nginx的Web架构，Keepalive与Mysql架构示例比较常用如下：

基于keepalive与Nginx的web架构

常用的基于keepalive高可用的Mysql主从架构

负载均衡缓存 Nginx

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。