几种负载均衡算法
本地流量管理技术主要有以下几种负载均衡算法：
静态负载均衡算法包括：轮询，比率，优先权
动态负载均衡算法包括: 最少连接数,最快响应速度，观察方法，预测法，动态性能分配，动态服务器补充，服务质量，服务类型，规则模式。
静态负载均衡算法
◆轮询（Round Robin）：顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。
◆比率（Ratio）：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。
◆优先权（Priority）：给所有服务器分组,给每个组定义优先权，BIG-IP 用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器出现故障，BIG-IP 才将请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。
动态负载均衡算法
◆最少的连接方式（Least Connection）：传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。
◆最快模式（Fastest）：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直
到其恢复正常。
◆观察模式（Observed）：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
◆预测模式（Predictive）：BIG-IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测)
◆动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。
◆动态服务器补充(Dynamic Server Act.):当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。
◆服务质量(QoS）:按不同的优先级对数据流进行分配。
◆服务类型(ToS): 按不同的服务类型（在Type of Field中标识）负载均衡对数据流进行分配。
◆规则模式：针对不同的数据流设置导向规则，用户可自行。
负载均衡对应本地的应用交换，大家可以通过对上述负载均衡算法的理解，结合实际的需求来采用合适你的负载均衡算法，我们常用到的一般是最少连接数、最快反应、或者轮询，决定选用那种算法，主要还是要结合实际的需求。
服务器负载均衡算法
有很多（持续性的和非持续性的），包括轮循算法、最少连接算法、响应时间算法、散列算法、最少连接失误算法，链路带宽算法等等。此外实际服务器(Real Server)可以被分配不同的加权值来调整被分配的流量。比如性能高的大型服务器可配置较大的加权值，而为性能较低的小型服务器设置较小的加权值。为了避免服务器因过载而崩溃，可为实际服务器指定最大连接阈值来避免该服务器过载。任何服务器可被指定为另一台服务器的备份服务器或溢出服务器，从而进一步保证了应用可用性。
非持续性算法（Non-Persistent）：一个客户端的不同的请求可能被分配到一个实际服务组中的不同的实服务器上进行处理。主要有轮循算法、最少连接算法、响应速度算法等。
轮循算法（Round Robin）：说明：每一次来自网络的请求轮流分配给内部中的每台服务器，从1至N然后重新开始。举例：此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况；
最少连接算法（Least Connection）：说明：客户端的每一次请求服务在服务器停留的时间都可能会有较大的差异，随着工作时间的加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，这样的结果并不会达到真正的负载均衡。最少连接数均衡算法对内部中有负载的每一台服务器都有一个数据记录，记录的内容是当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。
此种负载均衡算法适合长时间处理的请求服务。
响应速度算法（Response Time）：说明：负载均衡设备对内部各服务器发出一个探测请求（例如Ping），然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。举例: 此种均衡算法能较好地反映服务器的当前运行状态，但最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与
服务器间的最快响应时间。
持续性算法（Persistent）：从一个特定的客户端发出的请求都被分配到一个实服务组中的同一个实服务器上进行处理。主要包括：A．基于IP的算法－Persistent IP (pi)：基于用户IP地址来选择服务器。－Hash IP (hi) ：基于用户IP地址的HASH值，来选择服务器－Consistent Hash IP (chi)：B．基于报头/请求的算法－Hash Header (hh)：基于用户请求报中HTTP报头来选择服务器；－Persistent Hostname (ph) ：基于用户请求报中HTTP报头的Hostname的HASH值，来选择服务器；－Persistent URL (pu)：基于对URI Tag 和值的静态对应关系来选择服务器。－SSL Session ID (sslsid)：基于SSL会话ID 来选择服务器。C．基于Cookie的算法－Persistent Cookie (pc) ：选择服务器基于用户请求包用Cookie Name / Value 的静态对应关系；－Hash Cookie (hc) ：选择服务器基于用户请求包用Cookie Name / Value 的Hash 值对应关系；－Insert Cookie (ic) ：选择服务器基于负载均衡器向服务器响应包中插入Cookie；－Re-write Cookie (rc)：选择服务器基于负载均衡器向服务器响应包中重写Cookie值。（必须为重写指定Cookie值的偏移量）
几种负载均衡算法 本地流量管理技术主要有以下几种负载均衡算法： 静态负载均衡算法包括：轮询，比率，优先权 动态负载均衡算法包括: 最少连接数,最快响应速度，观察方法，预测法，动态性能分配，动态服务器补充，服务质量，服务类型，规则模式。 静态负载均衡算法 ◆轮询（Round Robin）：顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。 ◆比率（Ratio）：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。 ◆优先权（Priority）：给所有服务器分组,给每个组定义优先权，BIG-IP 用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器出现故障，BIG-IP 才将请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。 动态负载均衡算法 ◆最少的连接方式（Least Connection）：传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。 ◆最快模式（Fastest）：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。 ◆观察模式（Observed）：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。 ◆预测模式（Predictive）：BIG-IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测) ◆动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。 ◆动态服务器补充(Dynamic Server Act.):当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。 ◆服务质量(QoS）:按不同的优先级对数据流进行分配。 ◆服务类型(ToS): 按不同的服务类型（在Type of Field中标识）负载均衡对数据流进行分配。 ◆规则模式：针对不同的数据流设置导向规则，用户可自行。 负载均衡对应本地的应用交换，大家可以通过对上述负载均衡算法的理解，结合实际的需求来采用合适你的负载均衡算法，我们常用到的一般是最少连接数、最快反应、或者轮询，决定选用那种算法，主要还是要结合实际的需求。
服务器负载均衡的设计与实现 在该架构中OpenFlow控制器可以获取每个服务器的运行状态，并根据运行状态分发用户请求，最大程度地利用每台服务器的计算资源，并且可以在系统运行期间动态地添加或删除服务器，使系统具备很高的灵活性。 1、动态负载均衡架构的整体设计 负载均衡架构是在一个非结构化的网络中使用集中式的控制器实现多台服务器共同对外提供服务。OpenFlow网络中的所有交换机都连接在一个控制器上，每台服务器有两块网卡，一块网卡连接到OpenFlow网络对用户提供网络服务，另一块通过以太网交换机和控制器相连，以便控制器通过SNMP协议获取服务器的运行状态，具体架构如图所示。 在上述负载均衡架构中控制器是网络的核心，其主要功能有四个，分别为： 保证网络正常的通信、获取服务器的运行状态、通过负载均衡算法计算服务器的综合负载、向交换机下发流表项以转发用户请求；控制器的模块设计如图所示。 本文阐述的负载均衡架构可以工作在任意openflow网络中，而不是专门为某个服务器
所设计的负载均衡，控制器的首要任务就是保证网络可以提供正常的数据转发服务，为了保证网络既可以为其他服务提供基础支持又保证负载均衡能够正常工作，在控制器的转发控制中有两个模块，第一个模块负责负载均衡服务，第二个模块负责网络的基本通信。当一个数据包到达Openflow交换机后，如果交换机找不到可以匹配的流表项，就会向控制发送packet-in消息，控制器收到packet-in消息之后首先交给负载均衡模块，由负载均衡模块处理该消息，如果该数据包的目的IP 不是负载均衡所负责的网络服务，如果该数据包的目的IP不是负载均衡所负责的网络服务，负载均衡模块就不会做任何处理而是直接packet-in 消息传递给网络通信模块，以保证其它业务正常通信。如果该数据包的目的IP是负载均衡所负责的网络服务，负载均衡模块就向交换机下发流表项让交换机完成负载均衡服务。 为了有效地利用计算资源，控制器还需要根据服务器的运行状态转发用户请求，因此控制器还要完成这方面的工作。在此架构中每台服务器都有一块通过以太网交换机和控制器相连的网卡，控制器通过以太网交换机和服务器通信，利用SNMP协议获取服务器的运行状态。在此架构中就算没有和服务器相连的网卡，控制器也可以通过Openflow网络和服务器通信，本文之所以没有这么做是因为控制器直接和连接在openflow网络中的服务器通信需要交换机把所有服务器所发送的消息封装成packet-in消息发送给交换机，控制器也必须通过向交换机发送packet-out消息才能把数据发送给服务器，这样做会给交换机和控制器同时带来很大的压力。 因为服务器的运行状态必须由多条信息才能描述清楚，所以就算得到服务器的运行状态之后，也无法根据多条信息判断哪台服务器的负载最低。因此本文在控制器中运行了一个负载均衡算法，控制器会把服务的运行状态作为负载均衡算法的参数代入到服务器综合负载的运算中，计算出服务器的综合负载，并根据综合负载得到负载最小的服务器。 负载均衡的核心内容就是让交换机分发用户的请求，用户请求的第一个数据包到达交换级之后，交换机会通过packet-in消息把数据包发送给控制器，控制器中的负载均衡模块会通过SNMP协议获取所有服务器的运行状态，并根据运行状态计算服务器的综合负载，之后把用户的请求转发给综合负载最小的服务器。 2、动态负载均衡架构的设计与实现 负载均衡常用的算法有随机、轮训和最小连接数，原因是这三种算法很容易用硬件实现，这三种算法中最小连接数算法的效果是最理想的，但是如果集群中的服务器在CPU、内存、网络带宽上的配置不相同，这三个算法都不能充分地发挥服务器集群的计算能力。在openflow网络中，网络的控制层由软件制定，负载均衡算法也可以集成在控制器中，使用软件完成，这样可以更准确地评估服务器的负载情况。本文阐述的负载均衡方案中就设计了一个负载均衡算法，根据服务器的运行状态计算服务器的综合负载，并返回综合负载最小的服务器。该算法可以在服务器性能差距较大的集群中充分发挥每一台服务器的计算能力，算法的具体实现过程如下： 1）动态反馈当前服务器负载量 主要收集每台服务器CPU和内存的使用率，这些信息并不能直接表示一台服务器的负载情况，所以使用公式1把CPU和内存信息转换为服务器的负载量，其中LC为第i台服务器CPU的使用率，LM为第i台内存的使用率，r1和r2为权值，用于强调该服务类型对各个部分的不同影响程度，r1+r2=1,LS为计算得出的第i台服务器负载量 LS=r1LC+r2*LM 2）服务器处理能力计算； 集群中服务器的性能也可能不同，在计算服务器负载的时候还要考虑服务器的处理能力，第i台服务器的处理能力使用C(i)表示，C的计算方法如公式所示，其中P为第i台服务器CPU的个数，M为第i台服务器内存的大小，r1和r2为权值，r1+r2=1。
负载调度算法 负载均衡（Load Balance），又称为负载分担，就是将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。负载均衡建立在现有网络结构之上，它提供了一种廉价又有效的方法来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 在调度器的实现技术中，IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，称之为VS/NAT技术。在分析VS/NAT 的缺点和网络服务的非对称性的基础上，提出通过IP隧道实现虚拟服务器的方法VS/TUN，和通过直接路由实现虚拟服务器的方法VS/DR，它们可以极大地提高系统的伸缩性。 在内核中的连接调度算法上，IPVS实现了以下几种调度算法： 1 轮叫调度 1.1 轮叫调度含义 轮叫调度（Round Robin Scheduling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。 轮叫是基站为终端分配带宽的一种处理流程，这种分配可以是针对单个终端或是一组终端的。为单个终端和一组终端连接分配带宽，实际上是定义带宽请求竞争机制，这种分配不是使用一个单独的消息，而是上行链路映射消息中包含的一系列分配机制。 1.2 轮叫调度算法流程 轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N（内部服务器个数），然后重新开始循环。在系统实现时，我们引入了一个额外条件，即当服务器的权值为零时，表示该服务器不可用而不被调度。这样做的目的是将服务器切出服务（如屏蔽服务器故障和系统维护），同时与其他加权算法保持一致。所以，算法要作相应的改动，它的算法流程如下：假设有一组服务器S = {S0, S1, …, Sn-1}，一个指示变量i表示上一次选择的服务器，W(Si)表示服务器Si的权值。变量i被初始化为n-1，其中n > 0。 j = i; do { j = (j + 1) mod n;
1.Rr – Round Robin 默认情况下，访问请求分配的次序为： 1, 2, 3, 4, 1, 2, 3,4 若Servers之间存在性能差异，可以通过调整分配粒度值（weight），来控制访问请求分配的次序： 1, 1, 1, 2, 2, 2, 3, 3, 3,4,4,4, 2.Lc - Least Connections 新的访问请求将分配至当前连接数最少的一台服务器上。分配粒度方法定义了两个服务器的活动连接数要有多大差别，算法里才会将它们区分为不同等级。3.Sr – Shortest Response Time 基于后台服务器的最短相应时间来分配新的访问请求。 4.Pi – Persistent IP 相同IP地址的请求将会分配到相同的服务器上 5.HI - Hash IP 这是一种基于源IP地址Hash来分发新建连接的算法。客户端发送一个请求到虚拟服务器；负载均衡设备将根据源IP地址计算出的哈希值来选择将该访问请求发送到哪一台服务器；对于哈希值相同的请求连接，都将会发送到相同的服务器上。 注意：如果一台服务器失效了，将导致负载均衡设备上的哈希值重新计算，这样对所有原已维持的会话状态都将产生影响。 在负载均衡集群的方式下，客户端到服务器端的对应关系，在其他负载均衡设备上无法维持的，因此当其中一台负载均衡设备失效以后，客户端的请求将会在其他正常的负载均衡重新进行负载分配。 6.CHI – Consistent Hash IP 这是一种基于源IP地址Hash来分发新建连接的算法。 客户端发送一个请求到虚拟服务器；负载均衡设备将根据源IP地址计算出的哈希值来选择将该访问请求发送到哪一台服务器；对于哈希值相同的请求连接，都将会发送到相同的服务器上。 注意：
负载均衡器部署方式和工作原理 2011/12/16 小柯信息安全 在现阶段企业网中，只要部署WEB应用防火墙，一般能够遇到负载均衡设备，较常见是f5、redware的负载均衡，在负载均衡方面f5、redware的确做得很不错，但是对于我们安全厂家来说，有时候带来了一些小麻烦。昨日的一次割接中，就遇到了国内厂家华夏创新的负载均衡设备，导致昨日割接失败。 在本篇博客中，主要对负载均衡设备做一个介绍，针对其部署方式和工作原理进行总结。 概述 负载均衡（Load Balance） 由于目前现有网络的各个核心部分随着业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。 负载均衡实现方式分类 1：软件负载均衡技术 该技术适用于一些中小型网站系统，可以满足一般的均衡负载需求。软件负载均衡技术是在一个或多个交互的网络系统中的多台服务器上安装一个或多个相应的负载均衡软件来实现的一种均衡负载技术。软件可以很方便的安装在服务器上，并且实现一定的均衡负载功能。软件负载均衡技术配置简单、操作也方便，最重要的是成本很低。 2：硬件负载均衡技术 由于硬件负载均衡技术需要额外的增加负载均衡器，成本比较高，所以适用于流量高的大型网站系统。不过在现在较有规模的企业网、政府网站，一般来说都会部署有硬件负载均衡设备（原因1.硬件设备更稳定，2.也是合规性达标的目的）硬件负载均衡技术是在多台服务器间安装相应的负载均衡设备，也就是负载均衡器来完成均衡负载技术，与软件负载均衡技术相比，能达到更好的负载均衡效果。 3：本地负载均衡技术
大家都知道一台服务器的处理能力，主要受限于服务器自身的可扩展硬件能力。所以，在需要处理大量用户请求的时候，通常都会引入负载均衡器，将多台普通服务器组成一个系统，来完成高并发的请求处理任务。 之前负载均衡只能通过DNS来实现，1996年之后，出现了新的网络负载均衡技术。通过设置虚拟服务地址（IP），将位于同一地域（Region）的多台服务器虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，将来自客户端的网络请求分发到
服务器池中。网络负载均衡会检查服务器池中后端服务器的健康状态，自动隔离异常状态的后端服务器，从而解决了单台后端服务器的单点问题，同时提高了应用的整体服务能力。 网络负载均衡主要有硬件与软件两种实现方式，主流负载均衡解决方案中，硬件厂商以F5为代表目前市场占有率超过50%，软件主要为NGINX与LVS。但是，无论硬件或软件实现，都逃不出基于四层交互技术的“转发”或基于七层协议的“代理”这两种方式。四层的转发模式通常性能会更好，但七层的代理模式可以根据更多的信息做到更智能地分发流量。一般大规模应用中，这两种方式会同时存在。 2007年F5提出了ADC（Application delivery controller）的概念为传统的负载均衡器增加了大量的功能，常用的有：SSL卸载、压缩优化和TCP连接优化。NGINX也支持很多ADC的特性，但F5的中高端型号会通过硬件加速卡来实现SSL卸载、压缩优化这一类CPU密集型的操作，从而可以提供更好的性能。 F5推出ADC以后，各种各样的功能有很多，但其实我们最常用的也就几种。这里我也简单的总结了一下，并和LVS、Nginx对比了一下。
应用交换技术的负载均衡算法 应用交换技术里主要包括四项关键的技术： ●截获和检查流量 ●服务器监控健康检查 ●负载均衡算法 ●会话保持 截获和检查流量保证只有合适的数据包才能通过； 服务器监控和健康检查随时了解服务器群的可用性状态； 负载均衡和应用交换功能通过各种策略导向到合适的服务器； 会话的保持以实现与应用系统完美结合； F5在应用交换技术中的优势： A、截获和检查流量 –BIG-IP 有最强的数据包截获和检查引擎去检查任何数据流量包中的任何部分，可以检测16384bytes包的深度，理论上可以检测 64Kbytes的包长度 –这使得BIG-IP 明显有别于其他的厂商的产品 B、用于定制控制的iRules工具 –可用来定义如何根据报头和/或TCP有效负载信息来引导、保存和过滤流量。 –iRules增强了企业或服务提供商定根据业务需求定制应用流量的能力。 –通用检查引擎和iRules分别是应用智能和业务决策来进行应用流量管理的方法和工具。 C、服务器监控和健康检查
–服务器(Node)-Ping(ICMP) –服务(Port)-Connect –扩展的应用验证(EA V) –扩展的内容验证(ECV) –针对VOD服务器的专用健康检查机制 –针对节点的检查频率和超时频度,e.g.10seconds响应,e.g.5seconds D、负载均衡和应用交换功能 –Global Load Balancer提供17种负载均衡算法 –F5提供最优质的负载均衡和应用交换功能 静态算法 动态算法 智能算法 I –control UIE + Irules –Local Load Balancer提供12种负载均衡算法 E、持续功能 –连续性与负载平衡是相互对立的，但它对于负载平衡又是必不可少的! –简单的连续性—基于源地址 –HTTP Cookie 连续性 –SSL Session ID 连续性 –目的地址的亲合作用--caches –standby BIG-IP实现对连续性记录的镜像 –智能与第七层的内容交换组合 F5做为应用交换领域的领导厂商，一直保持着技术上的领先地位，F5已经有40多项技术申请了专利，其它的竞争合作伙伴都在购买F5的这些专利技术。接下来我们讨论一下负载均衡算法。
PS：Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件，本人都在多个项目中实施过，参考了一些资料，结合自己的一些使用经验，总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以了；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案：Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 一、Nginx Nginx的优点是： 1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会； 3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。 3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。 7、Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比
应用负载均衡设计方案v1设 计方案 1．需要有支持应用的负载均衡产品，具备多种负载均衡算法。 2．能够做到根据各个Web服务器的性能，合理地分配服务器群中的每台机器所要处理的请求。 3．能够及时的发现群中的某台机器当掉，从而不对此机器发送请求。当掉机器恢复正常后，自动进行业务处理。 4．可以应对大量的服务访问；至少2, 000, 000条的TCP同时并发连接，至少每秒建立100, 000条连接。 5．有效直观的监控统计界面，包含当前时刻、过去一段时间的请求数量统计、性能统计、会话时间统计。 6．为个人业务提供SSL加密服务，可以将服务器SSL加/解密前移，并提供高效的https加/解密性能。 7．能够提供有效的机制缓解后台应用中间键服务器压力，提高业务的访问量。
一、方案建议 针对上一节提出的需求分析，F5公司充分考虑XXXX现有的实际状况，结合F5公司在 国际上网络优化案例的经验，总结出以下应用交付优化设计方案。 方案采用F5公司的新一代LTM应用交换机BIGIP3400, 提供后台Web服务器集群的负 载均衡；同时，采用另两台BIGIP 3400设备提供后台中间键服务器负载均衡，并减轻中间键服务器的压力。 在负责实现Web服务器负载均衡的BIG-IP 3400上设置两个Vlan , 分别是External Vlan 负责连接外部的防火墙系统, Internal Vlan负责连接部Web服务器集群。并且在该对BIG-IP 3400上，分别采用SSL加速模块帮助后台Web服务器实现业务的加密处理；还采用了动态智能压缩模块帮助XXXX在有限的带宽下实现访问速度的提高和访问量的增大。 在负责实现部中间键服务器负载均衡的BIG-IP 3400也设置两个Vlan，分别是External Vlan 负责连接外部的Web服务器集群, Internal Vlan负责连接部中间键服务器集群。并 且在该对BIG-IP 3400上，采用One-Connection技术降低后台中间键服务器集群的负载。
实用标准文案 几种负载均衡算法 本地流量管理技术主要有以下几种负载均衡算法： 静态负载均衡算法包括：轮询，比率，优先权 动态负载均衡算法包括: 最少连接数,最快响应速度，观察方法，预测法，动态性能分配，动态服务器补充，服务质量，服务类型，规则模式。 静态负载均衡算法 ◆轮询（Round Robin）：顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。 ◆比率（Ratio）：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。 ◆优先权（Priority）：给所有服务器分组,给每个组定义优先权，BIG-IP 用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器出现故障，BIG-IP 才将请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。 动态负载均衡算法 ◆最少的连接方式（Least Connection）：传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。
◆最快模式（Fastest）：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直精彩文档．实用标准文案 到其恢复正常。 ◆观察模式（Observed）：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。 ◆预测模式（Predictive）：BIG-IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测) ◆动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。 ◆动态服务器补充(Dynamic Server Act.):当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。 ◆服务质量(QoS）:按不同的优先级对数据流进行分配。 ◆服务类型(ToS): 按不同的服务类型（在Type of Field中标识）负载均衡对数据流进行分配。 ◆规则模式：针对不同的数据流设置导向规则，用户可自行。 负载均衡对应本地的应用交换，大家可以通过对上述负载均衡算法的理解，结合实际的需求来采用合适你的负载均衡算法，我们常用到的一般是最少连接数、最快反应、或者轮询，决定选用那种算法，主要还是要结合实际的需求。
该文档是word2003—word2007兼容版 软件、硬件负载均衡部署方案 目录 1、硬件负载均衡之F5部署方案 (2) 1.1网络拓扑结构 (2) 1.2反向代理部署方式 (3) 2软件负载均衡方案 (4) 2.1负载均衡软件实现方式之一- URL重定向方式 (4) 2.2负载均衡软件实现方式之二- 基于DNS (5) 2.3负载均衡软件实现方式之三- LVS (8) 2.4负载均衡软件实现方式之四- 专业负载均衡软件 (16) 总结： (16)
1、硬件负载均衡之F5部署方案 对于所有的对外服务的服务器，均可以在BIG-IP上配置Virtual Server实现负载均衡，同时BIG-IP可持续检查服务器的健康状态，一旦发现故障服务器，则将其从负载均衡组中摘除。 BIG-IP利用虚拟IP地址（VIP由IP地址和TCP/UDP应用的端口组成，它是一个地址）来为用户的一个或多个目标服务器（称为节点：目标服务器的IP地址和TCP/UDP应用的端口组成，它可以是internet的私网地址）提供服务。因此，它能够为大量的基于TCP/IP的网络应用提供服务器负载均衡服务。根据服务类型不同分别定义服务器群组，可以根据不同服务端口将流量导向到相应的服务器。BIG-IP连续地对目标服务器进行L4到L7合理性检查，当用户通过VIP请求目标服务器服务时，BIG-IP根椐目标服务器之间性能和网络健康情况，选择性能最佳的服务器响应用户的请求。如果能够充分利用所有的服务器资源，将所有流量均衡的分配到各个服务器，我们就可以有效地避免“不平衡”现象的发生。 利用UIE+iRules可以将TCP/UDP数据包打开，并搜索其中的特征数据，之后根据搜索到的特征数据作相应的规则处理。因此可以根据用户访问内容的不同将流量导向到相应的服务器，例如：根据用户访问请求的URL将流量导向到相应的服务器。 1.1网络拓扑结构 网络拓扑结构如图所示：
静态负载均衡算法的简单说明 实现的问题： 目前有N个资源Scale1~ScaleN，且这N个资源正在处理个数不等的请求，这时发来M个请求。 如何把M个请求分发到这N个资源中，使得分发完之后这N个资源所处理的请求是均衡的。 名词定义 Scale-资源 Order-请求 compId-每个资源的唯一标识 compId数组-compIdArr 根据每个Scale目前所处理的Order个数多少，从小到大把其对应的compId记录在数组中 负载分配数组-dispatchCountArr 对于dispatchCountArr[i]，它的值表示的是可以分发的Order的个数， 分发的compId的范围是在compIdArr[0]到compIdArr[i]之间。 例，如果有3个Scale，它们的compId和当前的Order个数分别为 Scale1：1，Scale2：5，Scale3：12 那么根据这组数据可以构造一个负载分配数组 dispatchCountArr[0]=(5-1)*1=4 表示可以在Scale1上再分配4个Order dispatchCountArr[1]=(12-5)*2=14 表示可以在Scale1和Scale2上平均分配14个Order dispatchCountArr[2]=整型最大值表示可以在Scale1~Scale3上再平均分配任意个Order 当有多个Order订单，需要为每个都分配一个compId时， 1.先从dispatchCountArr[0]开始，如果dispatchCountArr[0]不为0，说明可以把这个订单指派给Scale1， 并且dispatchCountArr[0]的值减1； 2.如果发现dispatchCountArr[0]已经为0，则继续看dispatchCountArr[1]， 如果大于0，说明可以再从Scale1和Scale2中取一个进行指派，用dispatchCountArr[1] mod 2产生一个0到1 的index，意思是在Scale1和Scale2之间进行平均分配，取compIdArr[index]作为分配的compId， 同时dispatchCountArr[1]减1 3.如果dispatchCountArr[1]也被减为0，那么继续看dispatchCountArr[2]，类似2中的操作， 用dispatchCountArr[2] mod 3产生一个0到2的index，意思是在Scale1到Scale3
（总结）Nginx/LVS/HAProxy负载均衡软件的优缺点详解 PS：Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件，本人都在多个项目中实施过，参考了一些资料，结合自己的一些使用经验，总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以了；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案：Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 Nginx的优点是： 1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会； 3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。 3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器
奈学：传授“带权重的负载均衡实现算法”独家设计思路 分布式系统中，大部分系统调用都会涉及到负载均衡，例如：客户端发往服务端的请求首先到达反向代理，然后反向代理再通过负载均衡算法将请求转发到业务系统；或者后端业务系统各模块间的调用前，也需要通过负载均衡算法选择到一个目标节点。 一般情况下，我们对负载均衡的要求就是均匀，确保调用方的请求流量能够均匀的发送到我们冗余部署的N个服务节点上，所以负载均衡的算法一般使用随机或轮询都可以保证被调用结点流量的均匀。 真实情况下，往往由于部署服务的服务器性能或资源分配等原因需要我们为服务结点设置不同的权重，权重高的结点可以分配多一些的流量，同时降低权重低的结点的流量比例。 这时负载均衡就不能简单的使用随机或者轮询了，需要添加对权重的支持。接下来我们分析几种带权重的负载均衡算法，并分析一下他们的优缺点： 一、使用随机数 设计思路如下：首先经过负载均衡后选择到一个结点，然后我们根据权重值再做一道拦截，按权重按比例放行，实现按降低结点流量的效果。例如我们规定权重的范围从0到10之间，0拒绝，10放行。权重值越高，分配的流量就越多。 最简单的实现方案，可以使用随机值，假设设置目标结点的权重值为7，当结点被负载均衡选中后，我们生成一个0到10之间的随机数，小于7放行，大于7则不向目标结点发送请求，需要从新做负载均衡计算，由此实现了将目标结点的流量降低到原来的70%。 方案实现起来很简单，但问题也很明显，我们都知道生成随机数的计算会造成CPU的开销，计算权重又发生在RPC调用过程中，所以每次RPC请求都会额外的增加一次随机数计算，累积起来对CPU额外的开销就很大了。我们可以进一步优化一下。 二、随机数组 我们可以使用一个随机数组代替上文描述的生成随机数的策略，实现同样效果的同时能够减少CPU 的计算量。接下来描述下随机数组算法，同样权重设计为0~10。 我们为每个被调用的结点都生成一个随机数组，数组长度为10。空间分配好后用0和1填充数组，0的个数与结点的权重值一样，同时要保证0在数组中出现的位置是随机的。 我们生成一个代表权重为“4”的随机数组（4个0），如下图所示： 和随机数方案类似，我们在完成负载均衡计算后，进行权重拦截。这个时候我们可以通过访问随机数组代替生成随机数的计算，方案描述如下：记录上一次访问随机数组的位置，取数组下一位置元素值，取到0则放行，1则拒绝，重新进行负载均衡计算。方案的思路是，轮询访问随机数组，到达随机效果。因为数组的内容是随机的。 这两种方案思路是一致的，都是在负载均衡计算后再加一道权重拦截。但这样的问题是流量控制不精确，无法实现精确个节点按权重比例分配流量。我们可以换个思路，实现精确的流量控制。 三、轮询加权重负载策略 设计思路如下，设计一个权重因子，初始值为所有被调用的结点中最大权重值。负载均衡使用轮询算法，被选中结点权重值大于等于权重因子则可以调用，否则用下一结点的权重值与权重因子比较，一轮
小区负载均衡算法介绍 1、小区负载均衡算法配置（针对本小区与扩容小区之间） 小区负载均衡算法分为两类PRB利用率负载平衡算法和同步态用户负载均衡算法两种。其中：PRB利用率负载平衡算法用于解决在单个小区PRB利用率受限（达到或者接近满载），同时存在与之重叠覆盖的异频邻区相对低载，算法将一部分负载转移至邻区之后，达到整体PRB利用率之和最大化，从而吞吐率最大化；同步态用户数负载平衡算法用于解决在单个小区用户数受限（由于用户数过多导致整体UE 速率受限），同时存在与之重叠覆盖的异频邻区相对低载，算法将一部分负载转移至邻区之后，达到整体用户速率平均化，从而减少差性用户的比例。笼统地说，PRB利用率负载平衡算法主要用于选大包用户，同步态用户数负载平衡算法主要用于选小包用户。 因为现网用户分布符合类正态分布的特性，即小包用户出现概率大，大包用户出现概率小。所以在现网使用同步态用户负载均衡算法。 同步态用户负载均衡算法关键参数及配置方式如下： InterFreqMlbSwitch：负载均衡总开关，在CELLALGOSWITCH设置，是进行PRB利用率负载平衡算法和同步态用户负载均衡的总开关，打开此开关才可进行复杂均衡。MML：MOD CELLALGOSWITCH:LOCALCELLID=X,MLBALGOSWITCH=InterFreqMlbSwitch-1; MlbTriggerMode：异频负载平衡触发模式，当前算法支持两种模式，三种开启方案：单独打开PRB 负载模式（PRB_ONLY）、单独打开用户数模式（UE_NUMBER_ONLY）和支持两个模式同时打开（PRB_OR_UE_NUMBER），现网配置时使用用户数模式即可。MML：MOD CELLMLB:LOCALCELLID=X,MLBTRIGGERMODE=UE_NUMBER_ONLY； InterFreqUeTrsfType：异频负载均衡转移UE类型。决定转移连接态UE还是释放态UE，区分PRB模式下转移UE连接态还是空闲态，用户数模式下转移UE连接态还是空闲态，一共4个勾选项，可以独立或者同时配置。现网设置SynchronizedUE(同步态用户)、IdleUE(空闲态用户)打开，PrbMlbSynchronizedUE(PRB模式负载均衡同步态用户)，异频空闲态小区PRB 利用率负载平衡算法PrbMlbIdleUE(PRB模式负载均衡空闲态用户)关闭即可。MML：MOD CELLMLB:LOCALCELLID=X，INTERFREQUETRSFTYPE=SynchronizedUE-1&IdleUE-1&PrbMlbSynchronizedUE-0&PrbMlbIdleUE-0； InterFreqMlbUeNumThd：异频负载均衡用户数门限；MlbUeNumOffset：负载均衡用户数偏置。算法高载触发门限，当算法未触发时如果小区同步态用户数大于等于InterFreqMlbUeNumThd + MlbUeNumOffset则触发异频连接态小区同步态用户数负载平衡算法，当算法触发时如果小区同步态用户数小于InterFreqMlbUeNumThd则退出算法。MlbUeNumOffset：负载均衡用户数偏置不需要进行配置，现网默认值20即可。InterFreqMlbUeNumThd异频负载均衡用户数门限设置为小区最大用户数的一半即可。MML：MOD CELLMLB:LOCALCELLID=X，INTERFREQMLBUENUMTHD=（最大用户数/2）; InterFreqLoadEvalPrd:异频负载评估周期，控制算法运行时序，在算法触发之后，负载
为了提高服务器的性能和工作负载能力，天互云计算通常会使用DNS服务器、网络地址转换等技术来实现多服务器负载均衡，特别是目前企业对外的互联网Web 网站，许多都是通过几台服务器来完成服务器访问的负载均衡。 目前企业使用的所谓负载均衡服务器，实际上它是应用系统的一种控制服务器，所有用户的请求都首先到此服务器，然后由此服务器根据各个实际处理服务器状态将请求具体分配到某个实际处理服务器中，对外公开的域名与IP地址都是这台服务器。负载均衡控制与管理软件安装在这台服务器上，这台服务器一般只做负载均衡任务分配，但不是实际对网络请求进行处理的服务器。 一、企业实现Web服务器负载均衡 为了将负载均匀的分配给内部的多个服务器上，就需要应用一定的负载均衡策略。通过服务器负载均衡设备实现各服务器群的流量动态负载均衡，并互为冗余备份。并要求新系统应有一定的扩展性，如数据访问量继续增大，可再添加新的服务器加入负载均衡系统。 对于WEB服务应用，同时有几台机器提供服务，每台机器的状态可以设为regular(正常工作)或backup(备份状态)，或者同时设定为regular状态。负载均衡设备根据管理员事先设定的负载算法和当前网络的实际的动态的负载情况决定下一个用户的请求将被重定向到的服务器。而这一切对于用户来说是完全透明的，用户完成了对WEB服务的请求，并不用关心具体是哪台服务器完成的。 二、使用网络地址转换实现多服务器负载均衡 支持负载均衡的地址转换网关中可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。很多硬件厂商将这种技术集成在他们的交换机中，作为他们第四层交换的一种功能来实现，一般采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡策略来分配负载。然而硬件实现的负载控制器灵活性不强，不能支持更优化的负载均衡策略和更复杂的应用协议。 基于网络地址转换的负载均衡器可以有效的解决服务器端的CPU和磁盘I/O负载，然而负载均衡器本身的性能受网络I/O的限制，在一定硬件条件下具有一定的带宽限制，但可以通过改善算法和提高运行负载均衡程序的硬件性能，来提高这个带宽限制。不同的服务类型对不同的服务器资源进行占用，我们使用的负载衡量策略是使用同一个负载进行评估，这对于大多数条件是适合的，然而最好的办法是针对不同的资源，如CPU、磁盘I/O或网络I/O 等，分别监视服务器负载，由中心控制器选择最合适的服务器分发客户请求。 三、使用DNS服务器实现负载均衡
负载均衡软件实现方式之一- URL重定向方式 有一种用软件实现负载均衡的方式,是基于"URL重定向"的. 先看看什么是URL重定向: "简单的说，如果一个网站有正规的URL和别名URL，对别名URL进行重定向到正规URL，访问同一个网址，或者网站改换成了新的域名则把旧的域名重定向到新的域名，都叫URL 重定向" (https://www.doczj.com/doc/f713963861.html,/service/host_faq.php) "很多网络协议都支持“重定向”功能，例如在HTTP协议中支持Location指令，接收到这个指令的浏览器将自动重定向到Location指明的另一个URL上。" (https://www.doczj.com/doc/f713963861.html,/art/200604/25388.htm) 这种方式,对于简单的网站,如果网站是自己开发的,也在一定程度上可行.但是它存在着较多的问题: 1、“例如一台服务器如何能保证它重定向过的服务器是比较空闲的，并且不会再次发送Location指令，Location指令和浏览器都没有这方面的支持能力，这样很容易在浏览器上形成一种死循环。” 2、在哪里放LOCATION，也是一个问题。很有可能用户会访问系统的很多个不同URL，这个时候做起来会非常麻烦。并且，对URL的访问，有的时候是直接过来的，可以被重定向，有的时候是带着SESSION之类的，重定向就可能会出问题。并且，这种做法，将负载均衡这个系统级的问题放到了应用层，结果可能是麻烦多多。 3、这种方式一般只适用于HTTP方式，但是实际上有太多情况不仅仅是HTTP方式了，特别是用户如果在应用里面插一点流媒体之类的。 4、重定向的方式，效率远低于IP隧道。 5、这种方式，有的时候会伴以对服务器状态的检测，但往往也是在应用层面实现，从而实时性大打折扣。 实际上，这种方式是一种“对付”的解决方法，并不能真正用于企业级的负载均衡应用（这里企业级是指稍微复杂一点的应用系统） 可以看一下专业的负载均衡软件是如何来实现的： https://www.doczj.com/doc/f713963861.html,/pcl/pcl_sis_theory.htm 对比一下可以发现，专业的负载均衡软件要更适用于正规应用，而重定向方式则比较适用于