网站高性能与可伸缩架构设计——负载均衡

07-19 1056阅读

从公众号转载，关注微信公众号掌握更多技术动态

---------------------------------------------------------------

一、高性能负载均衡

单服务器无论如何优化，无论采用多好的硬件，总会有一个性能天花板，当单服务器的性能无法满足业务需求时，就需要设计高性能集群来提升系统整体的处理性能。

高性能集群的本质是通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点：同样的输入数据和逻辑，无论在哪台服务器上执行，都应该得到相同的输出。因此高性能集群设计的复杂度主要体现在：任务分配(又叫负载均衡，不只是为了计算单元的负载达到均衡状态)

多台计算机处理任务，首先可以采用单个任务分配器进行分配,此时任务分配器和真正的服务器之间的交互需要选择合适的连接方式，并且对连接进行管理(连接建立，连接检测，连接中断如何处理)，同时要选择合适的任务分配器和分配算法。

当单个任务分配器性能达到上限时，就采用多台任务分配器。此时需要将不同用户分配到不同的分配器，分配器和业务服务器变成了多对多的网状关系，并且因为服务器的增多，连接管理的复杂性也变得更高。

1.负载均衡分类

(1)DNS 负载均衡(能够增加入口Nginx实例个数)

DNS 是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。例如，北方的用户访问北京的机房，南方的用户访问深圳的机房。DNS 负载均衡的本质是 DNS 解析同一个域名可以返回不同的 IP 地址。例如，同样是 www.baidu.com，北方用户解析后获取的地址是 61.135.165.224（这是北京机房的 IP），南方用户解析后获取的地址是 14.215.177.38（这是深圳机房的 IP）。

①DNS 负载均衡其优点

简单、成本低：负载均衡工作交给 DNS 服务器处理，无须自己开发或者维护负载均衡设备。

就近访问，提升访问速度：DNS 解析时可以根据请求来源 IP，解析成距离用户最近的服务器地址，可以加快访问速度，改善性能。

②DNS 负载均衡其缺点

更新不及时：DNS 缓存的时间比较长，修改 DNS 配置后，由于缓存的原因，还是有很多用户会继续访问修改前的 IP，这样的访问会失败，达不到负载均衡的目的，并且也影响用户正常使用业务。
扩展性差：DNS 负载均衡的控制权在域名商那里，无法根据业务特点针对其做更多的定制化功能和扩展特性。
分配策略比较简单：DNS 负载均衡支持的算法少；不能区分服务器的差异（不能根据系统与服务的状态来判断负载）；也无法感知后端服务器的状态。
域名解析均衡，并不代表真正的流量均衡。

针对 DNS 负载均衡的一些缺点，对于时延和故障敏感的业务，有一些公司自己实现了 HTTP-DNS 的功能，即使用 HTTP 协议实现一个私有的 DNS 系统。这样的方案和通用的 DNS 优缺点正好相反。

(2)硬件负载均衡

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。目前业界典型的硬件负载均衡设备有两款：F5 和 A10。这类设备性能强劲、功能强大，但价格都不便宜，一般只有“土豪”公司才会考虑使用此类设备。普通业务量级的公司一是负担不起，二是业务量没那么大，用这些设备也是浪费。

①硬件负载均衡的优点
- 功能强大：全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡。
- 性能强大：对比一下，软件负载均衡支持到 10 万级并发已经很厉害了，硬件负载均衡可以支持 100 万以上的并发。
- 稳定性高：商用硬件负载均衡，经过了良好的严格测试，经过大规模使用，稳定性高。
- 支持安全防护：硬件均衡设备除具备负载均衡功能外，还具备防火墙、防 DDoS 攻击等安全功能。
  
  ②硬件负载均衡的缺点
  
  价格昂贵：最普通的一台 F5 就是一台“马 6”，好一点的就是“Q7”了。
  
  扩展能力差：硬件设备，可以根据业务进行配置，但无法进行扩展和定制。
  
  (3)软件负载均衡
  
  软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS，其中 Nginx 是软件的 7 层负载均衡(IP)，LVS 是 Linux 内核的 4 层负载均衡(数据链路)。4 层和 7 层的区别就在于协议和灵活性，Nginx 支持 HTTP、E-mail 协议；而 LVS 是 4 层负载均衡，和协议无关，几乎所有应用都可以做，例如，聊天、数据库等。
  
  ①软件负载均衡的优点
  - 简单：无论是部署还是维护都比较简单。
  - 便宜：只要买个 Linux 服务器，装上软件即可。
  - 灵活：4 层和 7 层负载均衡可以根据业务进行选择；也可以根据业务进行比较方便的扩展，例如，可以通过 Nginx 的插件来实现业务的定制化功能。
    
    ②软件负载均衡的缺点
    - 性能一般：Ngxin 的性能是万级，一般的 Linux 服务器上装一个 Nginx 大概能到 5 万 / 秒；LVS 的性能是十万级，据说可达到 80 万 / 秒；而 F5 性能是百万级，从 200 万 / 秒到 800 万 / 秒都有。
    - 功能没有硬件负载均衡那么强大。
    - 一般不具备防火墙和防 DDoS 攻击等安全功能。
      
      ③L4 vs L7
      
      L4四层负载均衡工作于处于OSI模型的传输层，主要工作是转发。它在接收到客户端报文后，需要了解传输层的协议内容，根据预设的转发模式和调度算法将报文转发到应用服务器。以TCP为例，当一个TCP连接的初始SYN报文到达时，调度器就选择一台服务器，将报文转发给它。此后通过查发报文的IP和TCP报文头地址，保证此连接的后继报文被转发到该服务器。
      
      L7七层负载均衡工作在OSI模型的应用层，主要工作就是代理。七层负载均衡会与客户端建立一条完整的连接并将应用层的请求解析出来，再按照调度算法选择一个应用服务器，并与应用服务器建立另外一条连接将请求发送过去。
      
      四层对应的是TCP/UDP协议，也就常说的IP+端口。七层已经是非常具体的应用层协议了。因此，所谓四层就是基于IP+端口的负载均衡；七层就是基于URL等应用层信息的负载均衡；
      
      同理，还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。二层负载均衡通过一个虚拟MAC地址接收请求，然后再分配到真实的MAC地址；三层负载均衡通过一个虚拟IP地址接收请求，然后再分配到真实的IP地址。
      - 四层代理。四层代理主要工作于OSI模型中的传输层，传输层主要处理消息的传递，而不管消息的内容。TCP就是常见的四层协议。四层负载均衡只针对由上游服务发送和接收的网络包，而并不检查包内的具体内容是什么。**四层负载均衡可以通过检查TCP流中的前几个包，从而决定是否限制路由。因此，四层负载均衡的核心就是IP+端口层面的负载均衡，不涉及具体的报文内容。四层代理是由后端服务器进行处理，包括报文的封装都是后端服务器进行封装；四层代理相当于是一个路由器。
      - 七层代理。七层代理主要工作于OSI模型的应用层，应用层主要用来处理消息内容的。比如，HTTP便是常见的七层协议。七层负载均衡服务器起到了反向代理的作用，Client端要先与七层负载均衡设备三次握手建立TCP连接，把要访问的报文信息发送给七层负载均衡。七层负载均衡器基于消息中内容( 比如URL或者cookie中的信息 )来做出负载均衡的决定。之后，七层负载均衡器建立一个新的TCP连接来选择上游服务并向这个服务发出请求。使用七层负载均衡的设备经常被用于反向代理。后端服务器把资源返回给负载均衡器，负载均衡器对资源再次进行封装，然后返还给客户端；在此过程中，需要建立两次TCP连接，一次是客户端，一次是后端的服务器。
        
        上图中最直观的区别是四层代理只进行了一次TCP请求，而七层代理进行了两次TCP请求。七层负载均衡的CPU密集程度比基于包的四层负载均衡更高。七层负载均衡能够让均衡器做更小粒度的负载均衡决定，并且会根据消息的内容( 比如压缩和加密 )利用最优化方式做出改变。它运用缓存的方式来卸载上游服务较慢的连接，并显著地提高了性能。
        
        ④负载均衡器
        
            负载均衡器通常称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP层，实现四层流量负载均衡。七层交换机除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息。
        
            负载均衡分为L4 switch（四层交换），即在OSI第4层工作，也就是TCP层。四层负载均衡器（如：LVS，F5）不关心应用协议（如HTTP/FTP/MySQL等）。
        
            L7 switch（七层交换），OSI的最高层，应用层。七层负载均衡器（如：HAProxy，MySQL Proxy）能理解应用协议。Nginx、LVS、HAProxy是目前使用最广泛的三种负载均衡软件。
        
        ⑤应用场景
        
        七层负载均衡器可以是使整个网络更智能化，比如可以通过七层代理将图片类、静态文件类（JS、CSS）请求转发到特定的服务器，利用缓存技术达到更好的性能。
        
        从技术原理上，可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性。例如Nginx或者Apache上部署的功能可以前移到负载均衡设备上，例如客户请求中的Header重写，服务器响应中的关键字过滤或者内容插入等功能。
        
        针对SYN Flood攻击，四层模型下攻击请求会被转发到后端服务器上，而七层模式下则可在负载均衡器上进行拦截，不影响后台服务器正常运营。针对SQL注入等情况，也可以通过在七层代理设置策略进行特定报文的过滤，从应用层面进一步提高系统整体安全。
        
        总之，七层负载均衡，主要着重于应用HTTP协议，所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。四层负载均衡则对应其他TCP应用，例如基于C/S开发的ERP等系统。
        
        虽然四层代理性能比七层高很多，但目前像Nginx这类负载均衡器已经可以满足大多数场景的需求，应用最多的也是像Nginx这类七层负载均衡器。
        
        2.负载均衡典型架构
        
            DNS 负载均衡、硬件负载均衡、软件负载均衡三种方式每种方式都有一些优缺点，但并不意味着在实际应用中只能基于它们的优缺点进行非此即彼的选择，反而是基于它们的优缺点进行组合使用。具体来说，组合的基本原则为：DNS 负载均衡用于实现地理级别的负载均衡；硬件负载均衡用于实现集群级别的负载均衡；软件负载均衡用于实现机器级别的负载均衡。
        
        地理级别负载均衡：www.xxx.com 部署在北京、广州、上海三个机房，当用户访问时，DNS 会根据用户的地理位置来决定返回哪个机房的 IP，图中返回了广州机房的 IP 地址，这样用户就访问到广州机房了。
        
        集群级别负载均衡：广州机房的负载均衡用的是 F5 设备，F5 收到用户请求后，进行集群级别的负载均衡，将用户请求发给 3 个本地集群中的一个，我们假设 F5 将用户请求发给了“广州集群 2”。
        
        机器级别的负载均衡：广州集群 2 的负载均衡用的是 Nginx，Nginx 收到用户请求后，将用户请求发送给集群里面的某台服务器，服务器处理用户的业务请求并返回业务响应。一般NGINX上面还有一层LVC,LVS它是一种集群(Cluster)技术，采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。
        
        注：一般在大型业务场景下才会这样用，如果业务量没这么大，则没有必要严格照搬这套架构。例如，一个大学的论坛，完全可以不需要 DNS 负载均衡，也不需要 F5 设备，只需要用 Nginx 作为一个简单的负载均衡就足够了。
        
        3.高性能负载均衡算法
        
        
        
        (1)轮询
        
        
        
        负载均衡系统收到请求后，按照顺序轮流平均分配到服务器上。轮询是最简单的一个策略，无须关注服务器本身的状态，例如：某个服务器当前因为触发了程序 bug 进入了死循环导致 CPU 负载很高，负载均衡系统是不感知的，还是会继续将请求源源不断地发送给它。集群中有新的机器是 32 核的，老的机器是 16 核的，负载均衡系统也是不关注的，新老机器分配的任务数是一样的。
        
        需要注意的是负载均衡系统无须关注“服务器本身状态”，这里的关键词是“本身”。也就是说，只要服务器在运行，运行状态是不关注的。但如果服务器直接宕机了，或者服务器和负载均衡系统断连了，这时负载均衡系统是能够感知的，也需要做出相应的处理。例如，将服务器从可分配服务器列表中删除，否则就会出现服务器都宕机了，任务还不断地分配给它，这明显是不合理的。
        
        (2)加权轮询
        
        
        
        负载均衡系统根据服务器权重进行任务分配，这里的权重一般是根据硬件配置进行静态配置的，采用动态的方式计算会更加契合业务，但复杂度也会更高。
        
        加权轮询是轮询的一种特殊形式，其主要目的就是为了解决不同服务器处理能力有差异的问题。例如，集群中有新的机器是 32 核的，老的机器是 16 核的，那么理论上我们可以假设新机器的处理能力是老机器的 2 倍，负载均衡系统就可以按照 2:1 的比例分配更多的任务给新机器，从而充分利用新机器的性能。
        
        加权轮询解决了轮询算法中无法根据服务器的配置差异进行任务分配的问题，但同样存在无法根据服务器的状态差异进行任务分配的问题。
        
        (3)负载最少连接优先(解决轮询缺点，但十分复杂，不推荐使用)
        
        负载均衡系统将任务分配给当前负载最低的服务器，这里的负载根据不同的任务类型和业务场景，可以用不同的指标来衡量。例如：LVS 这种 4 层网络负载均衡设备，可以以“连接数”来判断服务器的状态，服务器连接数越大，表明服务器压力越大。Nginx 这种 7 层网络负载系统，可以以“HTTP 请求数”来判断服务器状态（Nginx 内置的负载均衡算法不支持这种方式，需要进行扩展）。
        
        如果我们自己开发负载均衡系统，可以根据业务特点来选择指标衡量系统压力。如果是 CPU 密集型，可以以“CPU 负载”来衡量系统压力；如果是 I/O 密集型，可以以“I/O 负载”来衡量系统压力。
        
        负载最低优先的算法解决了轮询算法中无法感知服务器状态的问题，由此带来的代价是复杂度要增加很多。例如：
        
        最少连接数优先的算法要求负载均衡系统统计每个服务器当前建立的连接，其应用场景仅限于负载均衡接收的任何连接请求都会转发给服务器进行处理，否则如果负载均衡系统和服务器之间是固定的连接池方式，就不适合采取这种算法。
        
        CPU 负载最低优先的算法要求负载均衡系统以某种方式收集每个服务器的 CPU 负载，而且要确定是以 1 分钟的负载为标准，还是以 15 分钟的负载为标准，不存在 1 分钟肯定比 15 分钟要好或者差。不同业务最优的时间间隔是不一样的，时间间隔太短容易造成频繁波动，时间间隔太长又可能造成峰值来临时响应缓慢。
        
        (4)性能最优类/最快响应
        
        
        
        负载最低优先类算法是站在服务器的角度来进行分配的，而性能最优优先类算法则是站在客户端的角度来进行分配的，优先将任务分配给处理速度最快的服务器，通过这种方式达到最快响应客户端的目的。
        
        和负载最低优先类算法类似，性能最优优先类算法本质上也是感知了服务器的状态，只是通过响应时间这个外部标准来衡量服务器状态而已。因此性能最优优先类算法存在的问题和负载最低优先类算法类似，复杂度都很高，主要体现在：
        
        负载均衡系统需要收集和分析每个服务器每个任务的响应时间，在大量任务处理的场景下，这种收集和统计本身也会消耗较多的性能。为了减少这种统计上的消耗，可以采取采样的方式来统计，即不统计所有任务的响应时间，而是抽样统计部分任务的响应时间来估算整体任务的响应时间。采样统计虽然能够减少性能消耗，但使得复杂度进一步上升，因为要确定合适的采样率，采样率太低会导致结果不准确，采样率太高会导致性能消耗较大，找到合适的采样率也是一件复杂的事情。
        
        无论是全部统计还是采样统计，都需要选择合适的周期：是 10 秒内性能最优，还是 1 分钟内性能最优，还是 5 分钟内性能最优……没有放之四海而皆准的周期，需要根据实际业务进行判断和选择，这也是一件比较复杂的事情，甚至出现系统上线后需要不断地调优才能达到最优设计。
        
        (5)Hash 类
        
        负载均衡系统根据任务中的某些关键信息进行 Hash 运算，将相同 Hash 值的请求分配到同一台服务器上。
        
        ①源地址 Hash
        
        将来源于同一个源 IP 地址的任务分配给同一个服务器进行处理，适合于存在事务、会话的业务。例如，当我们通过浏览器登录网上银行时，会生成一个会话信息，这个会话是临时的，关闭浏览器后就失效。网上银行后台无须持久化会话信息，只需要在某台服务器上临时保存这个会话就可以了，但需要保证用户在会话存在期间，每次都能访问到同一个服务器，这种业务场景就可以用源地址 Hash 来实现。
        
        ②ID Hash
        
        将某个 ID 标识的业务分配到同一个服务器中进行处理，这里的 ID 一般是临时性数据的 ID（如 session id）。例如，上述的网上银行登录的例子，用 session id hash 同样可以实现同一个会话期间，用户每次都是访问到同一台服务器的目的。
        
        ③一致性hash——减少扩容、缩容时迁移的数据量
        
        普通hash运算速度也快，但它最大的问题是在系统扩容或者缩容时，必须迁移改变了映射关系的数据。然而，取模哈希函数中基数的变化，往往会导致绝大部分映射关系改变，比如上例中的 5 个关键字，在下图中集群节点数（即基数）从 5 降为 4 时，原映射关系全部失效，这 5 条数据都得迁移到其他节点：
        
        1997 年发布的《Consistent Hashing and Random Trees》论文提出了一致性哈希算法，可以大幅度减少数据迁移量。一致性哈希算法是通过以下 2 个步骤来建立数据与主机节点间映射关系的：
        
        首先，将关键字经由通用的哈希函数映射为 32 位整型哈希值。这些哈希值会形成 1 个环，最大的数字 232 相当于 0。
        
        其次，设集群节点数为 N，将哈希环由小至大分成 N 段，每个主机节点处理哈希值落在该段内的数据。比如下图中，当节点数 N 等于 3 且均匀地分段时，节点 0 处理哈希值在 [0, 31∗232] 范围内的关键字，节点 1 处理 [31∗232, 32∗232] 范围内的关键字，而节点 2 则处理的范围是 [32∗232, 232]：
        
        当然，在生产环境中主机节点很可能是异构的，所以我们要给高规格的服务器节点赋予更高的权重。一致性哈希算法改变节点的权重非常简单，只需要给每个节点分配更大的弧长即可。例如，如果上图中的节点 0 拥有更高的硬件配置，那么可以将原本均匀分布的 3 个节点调整为 2:1:1 的权重，这样节点 0 处理的哈希值范围调整为 [0, 231]，节点 1 的处理范围调整为 [231, 3∗230]，节点 2 的处理范围调整为 [3∗230, 232]，如下图所示：
        
        而扩容、缩容时，虽然节点数发生了变化，但只要小幅度调整环上各节点的位置，就不会导致大量数据的迁移。比如下图中我们将 3 个节点的集群扩容为 4 个节点，只需要将节点 0 上一半的数据迁移至节点 3 即可，其他节点不受影响：
        
        因此，一致性哈希算法的缺点是将映射函数的时间复杂度从 O(1) 提高到了 O(logN)，它的优点是将数据迁移规模从 O(M) 降低至 O(M/N)。由于数据条数 M 远大于主机节点数 N，而且数据迁移的成本很大，所以一致性哈希算法更划算，它的适用场景也更广！
        
        如何通过虚拟节点提高均衡度
        
        一致性哈希算法虽然降低了数据的迁移量，但却遗留了两个问题没有解决。
        
        首先，如果映射后哈希环中的数字分布不均匀，就会导致各节点处理的数据不均衡，从而降低了系统的运行效率与性能。在无法找出分布规律时，我们也无法通过调整环中节点的权重，平衡各节点处理的数据量。
        
        其次，容灾与扩容时，哈希环上的相邻节点容易受到过大影响。比如下图中，当节点 0 宕机后，根据一致性哈希算法的规则，其上数据应该全部迁移到相邻的节点 1 上，这样，节点 1 的数据量、访问量都会迅速增加 1 倍，一旦新增的压力超过了节点 1 的处理能力上限，就会导致节点 1 崩溃，进而形成雪崩式的连锁反应：
        
        系统扩容时也面临着同样的问题，除非同时调整环中各节点的位置，否则扩容节点也只会减轻相邻节点的负载。当数据存在多份冗余时，这两类问题会被进一步放大。那如何提高均衡性呢？在真实的数据节点与哈希环之间引入一个虚拟节点层，就可以解决上述问题。例如下图中的集群含有 4 个节点，但我们并不直接将哈希环分为 4 份，而是将它均匀地分为 32 份并赋予 32 个虚拟节点，因此每个虚拟节点会处理 227 个哈希值，再将 32 个虚拟节点通过某个哈希函数（比如 CRC32）映射到 4 个真实节点上（比如图中 8 个绿色虚拟节点皆由同色的主机节点 0 处理）：
        
        这样，如果图中绿色的节点 0 宕机，按照哈希环上数据的迁移规则，8 个绿色虚拟节点上的数据就会沿着顺时针方向，分别迁移至相邻的虚拟节点上，最终会迁移到真实节点 1（橙色）、节点 2（蓝色）、节点 3（水红色）上。所以，宕机节点上的数据会迁移到其他所有节点上。
        
        扩容时也是一样的，通过虚拟节点环，新增节点可以分担现有全部节点的压力。至于虚拟节点为什么可以让数据的分布更均衡，这是因为在虚拟节点与真实节点间，又增加了一层哈希映射，哈希函数会将原本不均匀的数字进一步打散。上图为了方便你理解，每个真实节点仅包含 8 个虚拟节点，这样能起到的均衡效果其实很有限。而在实际的工程中，虚拟节点的数量会大很多，比如 Nginx 的一致性哈希算法，每个权重为 1 的真实节点就含有160 个虚拟节点。
        
        当然，有了虚拟节点后，为异构的服务器节点设置权重也更方便。只需要为权重高的真实节点，赋予更多的虚拟节点即可。注意，虚拟节点增多虽然会提升均衡性，但也会消耗更多的内存与计算力。
        
        二、软件负载均衡区别
        
        1.HAProxy
        
        (1)HA是什么
        
        HAProxy 是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy适用于负载特大并发连接的web站点，这些站点通常又需要会话保持或七层处理。它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护web服务器不被暴露到网络上。
        
        HAProxy 实现了一种事件驱动、单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以使每个CPU时间片(Cycle)做更多的工作。
        
        HAProxy 支持连接拒绝 : 因为维护一个连接的打开的开销是很低的，有时很需要限制攻击蠕虫（attack bots），也就是说限制它们的连接打开从而限制它们的危害。这个已经为一个陷于小型DDoS攻击的网站开发了而且已经拯救了很多站点，这个优点也是其它负载均衡器没有的。
        
        HAProxy 支持全透明代理（已具备硬件防火墙的典型特点）: 可以用客户端IP地址或者任何其他地址来连接后端服务器. 这个特性仅在Linux 2.4/2.6内核打了cttproxy补丁后才可以使用. 这个特性也使得为某特殊服务器处理部分流量同时又不修改服务器的地址成为可能。
        
        (2)性能
        
        单进程、事件驱动模型显著降低了上下文切换的开销及内存占用。
        
        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)；
        
        内存分配器在固定大小的内存池中可实现即时内存分配，这能够显著减少创建一个会话的时长；
        
        树型存储：侧重于使用作者多年前开发的弹性二叉树，实现了以O(log(N))的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列；
        
        优化的HTTP首部分析：优化的首部分析功能避免了在HTTP首部分析过程中重读任何内存区域；
        
        精心地降低了昂贵的系统调用，大部分工作都在用户空间完成，如时间读取、缓冲聚合及文件描述符的启用和禁用等；
        
        所有的这些细微之处的优化实现了在中等规模负载之上依然有着相当低的CPU负载，甚至于在非常高的负载场景中，5%的用户空间占用率和95%的系统空间占用率也是非常普遍的现象，这意味着HAProxy进程消耗比系统空间消耗低20倍以上。因此，对OS进行性能调优是非常重要的。即使用户空间的占用率提高一倍，其CPU占用率也仅为10%，这也解释了为何7层处理对性能影响有限这一现象。由此，在高端系统上HAProxy的7层性能可轻易超过硬件负载均衡设备。
        
        在生产环境中，在7层处理上使用HAProxy作为昂贵的高端硬件负载均衡设备故障故障时的紧急解决方案也时长可见。硬件负载均衡设备在“报文”级别处理请求，这在支持跨报文请求(request across multiple packets)有着较高的难度，并且它们不缓冲任何数据，因此有着较长的响应时间。对应地，软件负载均衡设备使用TCP缓冲，可建立极长的请求，且有着较大的响应时间。
        
        2.LVS：Linux Virtual Server
        
        (1)简介
        
        LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器,。现在LVS已经是 Linux标准内核的一部分。LVS主要用于服务器集群的负载均衡。它工作在网络层，可以实现高性能，高可用的服务器集群技术。它廉价，可把许多低性能的服务器组合在一起形成一个超级服务器。它易用，配置非常简单，且有多种负载均衡的方法。它稳定可靠，即使在集群的服务器中某台服务器无法正常工作，也不影响整体效果。另外可扩展性也非常好。
        
        　　LVS自从1998年开始，发展到现在已经是一个比较成熟的技术项目了。可以利用LVS技术实现高可伸缩的、高可用的网络服务，例如WWW服务、Cache服务、DNS服务、FTP服务、MAIL服务、视频/音频点播服务等等。
        
        (2)LVS的体系结构
        
        　　使用LVS架设的服务器集群系统有三个部分组成：
        
        最前端的负载均衡层，用Load Balancer表示；
        
        中间的服务器集群层，用Server Array表示；
        
        最底端的数据共享存储层，用Shared Storage表示；
        
        　　在用户看来，所有的内部应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。
        
        (3)LVS负载均衡机制
        
        LVS是四层负载均衡，建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。因为LVS是四层负载均衡，因此它相对于其它高层负载均衡的解决办法，比如DNS域名轮流解析、应用层负载的调度、客户端的调度等，它的效率是非常高的。
        
        LVS的转发主要通过修改IP地址（NAT模式，分为源地址修改SNAT和目标地址修改DNAT）、修改目标MAC（DR模式）来实现。
        
        ①NAT模式：网络地址转换
        
        
        
        　NAT（Network Address Translation）是一种外网和内网地址映射的技术。NAT模式下，网络数据报的进出都要经过LVS的处理。LVS需要作为RS（真实服务器）的网关。当包到达LVS时，LVS做目标地址转换（DNAT），将目标IP改为RS的IP。RS接收到包以后，仿佛是客户端直接发给它的一样。RS处理完，返回响应时，源IP是RS IP，目标IP是客户端的IP。这时RS的包通过网关（LVS）中转，LVS会做源地址转换（SNAT），将包的源地址改为VIP，这样，这个包对客户端看起来就仿佛是LVS直接返回给它的。客户端无法感知到后端RS的存在。
        
        ②DR模式：直接路由
        
        
        
        DR模式下需要LVS和RS集群绑定同一个VIP（RS通过将VIP绑定在loopback实现），但与NAT的不同点在于：请求由LVS接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时候不经过LVS。详细来看，一个请求过来时，LVS只需要将网络帧的MAC地址修改为某一台RS的MAC，该包就会被转发到相应的RS处理，注意此时的源IP和目标IP都没变，LVS只是做了一下移花接木。RS收到LVS转发来的包时，链路层发现MAC是自己的，到上面的网络层，发现IP也是自己的，于是这个包被合法地接受，RS感知不到前面有LVS的存在。而当RS返回响应时，只要直接向源IP（即用户的IP）返回即可，不再经过LVS。
        
        DR负载均衡模式数据分发过程中不修改IP地址，只修改mac地址，由于实际处理请求的真实物理IP地址和数据请求目的IP地址一致，所以不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。因此，DR模式具有较好的性能，也是目前大型网站使用最广泛的一种负载均衡手段。
        
        3.nginx、lvs、ha区别
        
        LVS是一个四层的负载均衡器,虽然是四层,但并没有TCP握手以及分手,只是偷窥了IP等信息,而Nginx是一个七层的负载均衡器,所以效率势必比四层的LVS低很多,但是可操作性比LVS高。四层是TCP层，使用IP+端口四元组的方式。只是修改下IP地址，然后转发给后端服务器，TCP三次握手是直接和后端连接的。只不过在后端机器上看到的都是与代理机的IP的established而已,LVS中没有握手。
        
        目前关于网站架构一般比较合理流行的架构方案：Web前端采用Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。
        
        网站建设初期（每日 PV 小于 100 万），可以选用 Nigix 作为反向代理负载均衡，因为其配置简单，性能也能满足一般的业务场景。如果考虑到负载均衡器是有单点问题，可以采用 Nginx + Keepalived 避免负载均衡器自身的单点问题
        
        网站并发达到一定程度之后，为了提高稳定性和转发效率，可以使用 LVS、毕竟 LVS 比 Nginx 要更稳定，转发效率也更高。不过维护 LVS 对维护人员的要求也会更高，投入成本也更大
        
        重要的ip地址，最好交由lvs/ha托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而来。所以将这些重要ip交给lvs托管式最为稳妥的，这样做的唯一缺点是需要VIP数量会比较多。
        
        (1)LVS
        
        LVS的优点：
        
        抗负载能力强，因为lvs工作方式的逻辑是非常简单的，而且工作再网络层第4层，仅作请求分发用，没有流量，所以在效率上基本不需要太过考虑。lvs一般很少出现故障，即使出现故障一般也是其他地方（如内存、CPU等）出现问题导致lvs出现问题。
        
        配置性低，这通常是一大劣势同时也是一大优势，因为没有太多的可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。
        
        工作稳定，因为其本省抗负载能力很强，所以稳定性高也是顺理成章的事，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体式非常稳定的。
        
        无流量，lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
        
        lvs基本上能支持所有应用，因为lvs工作在第4层(传输层)，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等。
        
        LVS的缺点是：
        
        软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
        
        如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。
        
        LVS就比较依赖于网络环境，目前来看服务器在同一网段内并且LVS使用direct方式分流，效果较能得到保证。另外注意，LVS需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。
        
        (2)nginx应用层负载均衡
        
        nginx的优点：
        
        nginx有充足的第三方功能模块的支持，主要通过upstream模块进行负载均衡；
        
        nginx对网络的依赖较小，理论上只要Ping得通，网页访问正常，nginx就能连得通；
        
        工作在网络的7层之上，可以针对http应用做一些分流的策略(域名、目录结构)，它的正则规则比haproxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，nginx单凭这点可利用的场合就远多于lvs了。
        
        Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。
        
        Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比Nginx的就只有lighttpd了，不过lighttpd目前还没有做到Nginx完全的功能，配置也不那么清晰易读，社区资料也远远没Nginx活跃。
        
        Nginx也可作为静态网页和图片服务器，这方面的性能也无对手。还有Nginx社区非常活跃，第三方模块也很多。
        
        nginx的缺点：
        
        将Nginx当做反向代理时，负载均衡功能不是很好，对后端服务器的健康检查功能较弱；
        
        nginx仅能支持http、https和email协议，这样就在适用范围上面小些，这个是它的缺点；
        
        nginx只支持通过端口来检测，不支持通过url来检测。
        
        (3)ha
        
        haproxy的优点：
        
        HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态；
        
        haproxy也是专门的负载均衡软件，Haproxy可以负载http，还可以负载均衡mysql；
        
        HAProxy是支持虚拟主机的。
        
        HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。
        
        4.LVS+Nginx同时使用
        
        nginx 用来做 http 的反向代理，能够 upsteam 实现 http 请求的多种方式的均衡转发。由于采用的是异步转发可以做到如果一个服务器请求失败，立即切换到其他服务器，直到请求成功或者最后一台服务器失败为止。这可以最大程度的提高系统的请求成功率
        
        lvs 采用的是同步请求转发的策略。这里说一下同步转发和异步转发的区别。同步转发是在 lvs 服务器接收到请求之后，立即 redirect 到一个后端服务器，由客户端直接和后端服务器建立连接。异步转发是 nginx 在保持客户端连接的同时，发起一个相同内容的新请求到后端，等后端返回结果后，由 nginx 返回给客户端
        
        进一步来说：当做为负载均衡服务器的 nginx 和 lvs 处理相同的请求时，所有的请求和响应流量都会经过 nginx；但是使用 lvs 时，仅请求流量经过 lvs 的网络，响应流量由后端服务器的网络返回
        
        也就是，当作为后端的服务器规模庞大时，nginx 的网络带宽就成了一个巨大的瓶颈
        
        但是仅仅使用 lvs 作为负载均衡的话，一旦后端接受到请求的服务器出了问题，那么这次请求就失败了。但是如果在 lvs 的后端在添加一层 nginx（多个），每个 nginx 后端再有几台应用服务器，那么结合两者的优势，既能避免单 nginx 的流量集中瓶颈，又能避免单 lvs 时一锤子买卖的问题
        
        lvs + nginx 的使用中，nginx 还可以作为一个中间环节来减小后端 tomcat 的服务压力，以及做一些业务切换、分流、前置缓存的功能
        
        5.Haproxy+Keepalived+MySQL实现读均衡负载
        
            应用服务器对只读的应用程序连接虚拟IP地址，连接到haproxy，然后通过haproxy将TCP协议转移到下面的3个数据库服务器中。Haproxy在此做4层的TCP交换服务。keepalived为了防止haproxy单点故障。
        
            为什么不用LVS？环境服务器少，haproxy和lvs相比性能差不多，且haproxy自带有mysql check，不需要额外的写mysql侦测脚本。