广域网负载均衡原理简单介绍
广域网负载均衡
多链路广域网负载均衡
（1）Inbound多链路负载均衡算法策略：RTT+Topology+RoundRobin
具体描述：
当外部用户访问九州梦网网站时，首先由F5的3DNS对客户端的LDNS进行RTT（Round Trip Time）探测，对比从两条链路返回的探测结果（可以从统计列表中看到），选择一条返回值小的链路IP地址返回给客户端，从而客户端再发起访问请求；当F5的3DNS探测不到客户端的LDNS（由于LDNS安全防护等原因）时，F5的3DNS自动启用Topology算法，来静态匹配客户端的LDNS地理位置，从而根据客户端的来源，返回正确的A记录；当探测不到的LDNS又不在地址列表中时，F5 3DNS自动启用Global Availability 算法作为默认算法，将所有无法计算结果并且不在Topology范围之内的LocalDNS请求，定义到系统的默认线路上。
F5 的3DNS具备二十多种Inbound算法，可以根据需要进行组合。
①RTT算法运行机制：
通过3DNS的RTT就近性算法会自动运算生成一个ldns就近分布表，通过这个动态的表，每个客户上来都会提供一个最快速的链路进行访问，由于站点有ISP1和ISP2的两条广域网线路。在3DNS上会针对站点服务器(以https://www.wendangku.net/doc/0a6598080.html, 为例)解析ISP1和ISP2的两个不同的公网地址。
对应于https://www.wendangku.net/doc/0a6598080.html,域名，在3DNS上配置wideip：https://www.wendangku.net/doc/0a6598080.html,，对应两个Virtual Server：VS1：202.106.83.177，VS2：219.17.66.100。分别属于ISP1和ISP2两条线路分配的IP地址段。在3DNS内部，同时定义两个DataCenter分别与ISP1和ISP2相对应。
用户的访问流程如下：
访问的用户在发起DNS请求时
（1）首先向其所在运营商的Local DNS发起https://www.wendangku.net/doc/0a6598080.html,域名的DNS请求。步骤2
（2）运营商的Local DNS服务器通过递归算法查找到工行的主、辅DNS服务器。步骤3和4。
（3）接受到请求的3DNS首先查询在本地是否有该LocalDNS的就近性表项，如果存在，则直接给LocalDNS返回速度最快的服务器
地址。如果不存在，则通知另外一台3DNS发起对该LocalDNS
的查询。步骤5。
（4）两台3DNS分别对LocalDNS进行Probe。例如ISP1侧3DNS查询该LocalDNS的RTT时间为150ms，而ISP2侧3DNS查询同一
LocalDNS的RTT时间为300ms，则此时在两台3DNS内都形成
了该LocalDNS的对应就近性表记录。
（5）接受到LocalDNS请求得3DNS根据系统的就近性表返回相应的DataCenter内的WEB服务器地址。步骤6。
（6）在用户LocalDNS获得地址后，将该地址返回给用户。步骤7
（7）用户向https://www.wendangku.net/doc/0a6598080.html,网站发起访问。步骤8。
通过以上流程可以看出，通过动态计算方式，可以最为准确的估算出用户LocalDNS与两条线路之间的速度。通过3DNS之间的信息交互，在两台3DNS上形成就近性表，并根据该表返回用户的最佳访问地址。
3DNS可以选择多种测试方法判断对local DNS的RTT时间, 包括:
●DNS_Dot: 向local DNS发起一个包含”.”的测试, 也就是向目标
LocalDNS请求root清单，该解析一般默认配置的DNS服务器均提供支
持。
●DNS_REV: 向local DNS发起LocalDNS本机IP的PTR请求
●UDP:发起一个UDP的包, 看是否回应
●TCP:发起一个TCP的包看是否回应
●ICMP:发起一个ICMP 的ping 包, 看是否回应
在以上各检测方式中，无论目标系统返回那种类型的数据包，3DNS均可认为是有效数据包而记录数据包往返时间，最终形成就近性表。
针对一个local DNS 的RTT结果:
ldns {
address 61.136.178.229
cur_target_state 419446729
ttl 2419199
probe_protocol tcp
path {
datacenter "CNC"
cur_rtt 189850
cur_hops 0
cur_completion_rate 10000
cur_last_hops 0
}
path {
datacenter "TEL"
cur_rtt 57209
cur_hops 0
cur_completion_rate 10000
cur_last_hops 0
}
}
通常情况下，我们选择RTT动态算法作为优选算法，只要是3DNS能检测到的地址，一律按照动态算法分配，保证系统最大的灵活性。
在实际的运行环境中，可能存在某些LocalDNS无法检测的情况，所以我们可以采用地理分布算法作为动态RTT算法的有效补充。
②地理分布算法
在3DNS上，可以根据用户的LocalDNS地址来决定给用户返回那个地址。在3DNS上可配置多个自定义区域，并将这些区域与链路相对应。当用户的LocalDNS发起请求连接3DNS的时候，3DNS将根据LocalDNS所位于的区域返回给LocalDNS适当的链路侧服务器地址，引导用户从正确的线路进行访问。
在该算法下，需要收集各运营商的IP地址网段表。将网段进行整理后输入到3DNS内形成自定义区域表。
一个典型的topology表结构如下：
topology { // 4 Items
// server ldns score
dc."CNC" 202.106.0.0/16 100
dc."TEL" 219.172.0.0/16 100
dc."CNC" 200.100.0.0/16 100
}
这样，就将所有从表中ldns网段内的LocalDNS请求有限定一到相应的表中对应的链路上。
通常，我们采用地理分布算法作为第二算法。当动态检测机制无法检到LocalDNS就进性的时候，将启动静态算法，将在地址范围列表之内的用户定义到正确的线路上去。
如果用户的LocalDNS即不可被动态RTT计算所检测，又不在本机对应的地理分布表中。此时就需要采用全球可用性算法引导用户到默认的线路上。
③全球可用性算法
全球可用性算法主要用于灾难备份系统。通过3DNS的健康检查算法，可判断各站点或线路的健康状态。并在配置的时候，将同一域名所对应的IP地址进行排序，在系统正常的时候，仅会有排名第一的服务器对外提供服务。只有在排名第一的服务器无法对外提供服务的时候，由排名第二的服务器接管服务。如果有多线路或者多站点则依次类推。
通常，我们采用全球可用性算法作为第三选择算法。在动态计算和地理分布均没有命中的时候，将所有的用户定义到默认的线路上。
（2）链路健康检查机制
两台3DNS分别检查本地端的服务器地址和对端线路的服务器地址。这些服务器地址实际上为BIGIP上配置的内部服务器的对外服务地址（如下示意图）。
当一条线路出现故障的时候，两台3DNS服务器均无法检测到对端线路的地址。所以在每台3DNS服务器上均只解析本侧线路对应的服务器地址（如下示意图）。
但在此时故障线路的3DNS服务器无法接受请求，根据DNS的冗余机制，所有的用户请求均会发送到正常线路侧的3DNS，所以此时所有的用户均将通过正常的线路进行访问。
（3）系统切换时间
在采用DNS实现链路切换时，系统的切换时间主要取决于每个域名的TTL 时间设置。在3DNS系统里，每个域名如https://www.wendangku.net/doc/0a6598080.html,均可设置对应的TTL 生存时间。在用户的LocalDNS得到域名解析纪录后，将在本地在TTL设定时间内将该域名解析对应纪录进行Cache，在Cache期间所有到该LocalDNS上进行域名解析的用户均将获得该纪录。在TTL时间timeout之后，如果有用户到LocalDNS上请求解析，则此LocalDNS将重新发起一次请求到3DNS上获得相应纪录。
因此，当单条线路出现故障时，3DNS将在系统定义的检查间隔（该时间可自行定义）内检查到线路的故障，并只解析正常的线路侧地址。但此时在LocalDNS上可能还有未过时的Cache纪录。在TTL时间timeout之后，该LocalDNS重新发起请求的时候就将从3DNS上获得正确的解析，从而引导用户通过正常的线路进行访问。系统检测间隔加上TTL时间之和则为系统切换的最长时间。通常，系统检测间隔设置为60秒，而TTL时间设置为600秒，所以系统切换的整体时间为11分钟。
（4）根据带宽负载情况，限制流量
当每条链路上Inbound的流量超过预先设定的阀值时，会分配流量给其它链路。
广域网负载均衡原理简单介绍
广域网负载均衡 多链路广域网负载均衡 （1）Inbound多链路负载均衡算法策略：RTT+Topology+RoundRobin 具体描述： 当外部用户访问九州梦网网站时，首先由F5的3DNS对客户端的LDNS进行RTT（Round Trip Time）探测，对比从两条链路返回的探测结果（可以从统计列表中看到），选择一条返回值小的链路IP地址返回给客户端，从而客户端再发起访问请求；当F5的3DNS探测不到客户端的LDNS（由于LDNS安全防护等原因）时，F5的3DNS自动启用Topology算法，来静态匹配客户端的LDNS地理位置，从而根据客户端的来源，返回正确的A记录；当探测不到的LDNS又不在地址列表中时，F5 3DNS自动启用Global Availability 算法作为默认算法，将所有无法计算结果并且不在Topology范围之内的LocalDNS请求，定义到系统的默认线路上。 F5 的3DNS具备二十多种Inbound算法，可以根据需要进行组合。 ①RTT算法运行机制： 通过3DNS的RTT就近性算法会自动运算生成一个ldns就近分布表，通过这个动态的表，每个客户上来都会提供一个最快速的链路进行访问，由于站点有ISP1和ISP2的两条广域网线路。在3DNS上会针对站点服务器(以https://www.wendangku.net/doc/0a6598080.html, 为例)解析ISP1和ISP2的两个不同的公网地址。 对应于https://www.wendangku.net/doc/0a6598080.html,域名，在3DNS上配置wideip：https://www.wendangku.net/doc/0a6598080.html,，对应两个Virtual Server：VS1：202.106.83.177，VS2：219.17.66.100。分别属于ISP1和ISP2两条线路分配的IP地址段。在3DNS内部，同时定义两个DataCenter分别与ISP1和ISP2相对应。 用户的访问流程如下：
F5负载均衡基本原理
F5 Application Management Products 服务器负载均衡原理 F5 Networks Inc
1．服务器负载平衡市场需求 (3) 2．负载平衡典型流程 (4) 2..1 通过VIP来截获合适的需要负载平衡的流量 (4) 2.2 服务器的健康监控和检查 (5) 2.3 负载均衡和应用交换功能,通过各种策略导向到合适的服务器 (6)
1．服务器负载平衡市场需求 随着Internet的普及以及电子商务、电子政务的发展，越来越多的应用系统需要面对更高的访问量和数据量。同时，企业对在线系统的依赖也越来越高，大量的关键应用需要系统有足够的在线率及高效率。这些要求使得单一的网络服务设备已经不能满足这些需要，由此需要引入服务器的负载平衡，实现客户端同时访问多台同时工作的服务器，一则避免服务器的单点故障，再则提高在线系统的服务处理能力。从业界环境来说，如下的应用需求更是负载均衡发展的推动力： ?业务系统从Client-Server转向采用Browser-Server 系统结构，关键系统需要高可用性 ?电子商务系统的高可用性和高可靠性需要 ?IT应用系统大集中的需要（税务大集中,证券大集中,银行大集中） ?数据中心降低成本,提高效率 负载均衡技术在现有网络结构之上提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。它有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。 BIG/IP利用定义在其上面的虚拟IP地址来为用户的一个或多个应用服务器提供服务。因此，它能够为大量的基于TCP/IP的网络应用提供服务器负载均衡服务。BIG/IP 连续地对目标服务器进行L4到L7合理性检查，当用户通过VIP请求目标服务器服务时，BIG/IP根椐目标服务器之间性能和网络健康情况，选择性能最佳的服务器响应用户的请求。 下图描述了一个负载平衡发生的流程：
负载均衡设备主要参数配置说明
（初稿）Radware负载均衡设备 主要参数配置说明 2007年10月 radware北京代表处
目录 一、基本配置 (3) 1.1 Tuning配置 (3) 1.2 802.1q配置 (4) 1.2 IP配置 (6) 1.3 路由配置 (7) 二、四层配置 (8) 2.1 farm 配置 (8) 2.2 servers配置 (10) 2.3 Client NAT配置 (11) 2.4 Layer 4 Policy配置 (16) 三、对服务器健康检查 (18) 3.1 基于连接的健康检查 (19) 3.2 高级健康检查 (21) 四、常用系统命令 (25)
一、基本配置 Radware负载均衡设备的配置主要包括基本配置、四层配置和对服务器健康检查配置。注：本文档内容，用红色标注的字体请关注。 1.1 Tuning配置 Rradware设备tuning table的值是设备工作的环境变量，在做完简单初始化后建议调整tuning值的大小。调整完tuning table后，强烈建议，一定要做memory check，系统提示没有内存溢出，才能重新启动设备，如果系统提示内存溢出，说明某些表的空间调大了，需要把相应的表调小，然后，在做memory check，直到没有内存溢出提示后，重启设备，使配置生效。 点击service->tuning->device 配置相应的环境参数，
在做一般的配置时主要调整的参数如下：Bridge Forwarding Table、IP Forwarding Table、ARP Forwarding Table、Client Table等。 Client NAT Addresses 如果需要很多网段做Client NAT，则把Client NAT Addresses 表的值调大。一般情况下调整到5。 Request table 如果需要做基于7层的负载均衡，则把Request table 的值调大，建议调整到10000。 1.2 80 2.1q配置 主要用于打VLAN Tag Device->Vlan Tagging
F5负载均衡原理
F5负载均衡原理 一负载均衡基本概念 1、什么是负载均衡? 负载均衡技术在现有网络结构之上提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。它有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。 BIG/IP利用定义在其上面的虚拟IP地址来为用户的一个或多个应用服务器提供服务。因此，它能够为大量的基于TCP/IP的网络应用提供服务器负载均衡服务。BIG/IP 连续地对目标服务器进行L4到L7合理性检查，当用户通过VIP请求目标服务器服务时，BIG/IP根椐目标服务器之间性能和网络健康情况，选择性能最佳的服务器响应用户的请求。 下图描述了一个负载平衡发生的流程： 1. 客户发出服务请求到VIP 2. BIGIP接收到请求，将数据包中目的IP地址改为选中的后台服务器IP地址，然后将数据包发出到后台选定的服务器 3. 后台服务器收到后，将应答包按照其路由发回到BIGIP 4. BIGIP收到应答包后将其中的源地址改回成VIP的地址，发回客户端，由此就完成了一个标准的服务器负载平衡的流程。
2．负载平衡典型流程 ●通过VIP来截获合适的需要负载平衡的流量 ●服务器监控和健康检查,随时了解服务器群的可用性状态 ●负载均衡和应用交换功能,通过各种策略导向到合适的服务器 2．1 通过VIP来截获合适的需要负载平衡的流量 在BIGIP上通过设置VIP来截获需要进行负载平衡的流量，这个VIP地址可以是一个独立的主机地址和端口的组合（例如：202.101.112.115:80）也可以是一个网络地址和端口的组合（例如：202.101.112.0:80），当流量经过BIGIP的时候，凡是命中VIP 的流量都将被截获并按照规则进行负载平衡。 2．2 服务器的健康监控和检查 服务器 (Node) - Ping (ICMP) BIGIP可以定期的通过ICMP包对后台服务器的IP地址进行检测，如果在设定的时间内能收到该地址的ICMP的回应，则认为该服务器能提供服务 服务 (Port) – Connect BIGIP可以定期的通过TCP包对后台服务器的服务端口进行检测，如果在设定的时间内能收到该服务器端口的回应，则认为该服务器能提供服务 扩展内容查证(ECV: Extended Content Verification)—ECV ECV是一种非常复杂的服务检查，主要用于确认应用程序能否对请求返回对应的数据。如果一个应用对该服务检查作出响应并返回对应的数据，则BIG/IP控制器将该服务器标识为工作良好。如果服务器不能返回相应的数据，则将该服务器标识为宕机。宕机一旦修复，BIG/IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。该功能使BIG/IP可以将保护延伸到后端应用如Web内容及数据库。BIG/ip的ECV 功能允许您向Web服务器、防火墙、缓存服务器、代理服务器和其它透明设备发送查询，然后检查返回的响应。这将有助于确认您为客户提供的内容正是其所需要的。 扩展应用查证(EAV: Extended Application Verification) EAV是另一种服务检查，用于确认运行在某个服务器上的应用能否对客户请求作出响应。为完成这种检查，BIG/IP控制器使用一个被称作外部服务检查者的客户程序，该程序为BIG/IP提供完全客户化的服务检查功能，但它位于BIG/IP控制器的外部。例如，该外部服务检查者可以查证一个Internet或Intranet上的从后台数据库中取出数据并在HTML网页上显示的应用能否正常工作。EAV是BIG/IP提供的非常独特的功能，它提供管理者将BIG/IP客户化后访问各种各样应用的能力，该功能使BIG/IP在提供标准的可用性查证之外能获得服务器、应用及内容可用性等最重要的反馈。
负载均衡设备的理解
现在越来越多的用户购买了负载均衡设备，但是在交流中发现很多人对负载均衡的一 些指标和作用理解的并不是那么确切，这里阐述一下个人的一些理解。 1. 吞吐量 各厂家对负载均衡设备的每个型号都有标称的吞吐量，客户购买了设备后，肯定是希 望设备在实际环境中能够达到标称的吞吐量。但这基本上是不可能的，原因很简单，设备的任何指标都是在最优的条件下测出的该设备所能发挥出的最大性能，就吞吐量来说，各厂家都是通过相同大小的大包来测的(传输一个大包自然比传输多个小包需要设备处理的次数少)，而实际环境中，各种大小的包都有，所以实际的吞吐量肯定要打个折扣。 那么是否会有厂家宣称的吞吐量就是实际混合环境的吞吐量呢? 这基本不可能，第一，性能测试工具很难模拟出真实环境的流量，测出的值仍然跟实际不符，第二，与商业利益不符，没有任何一个厂家会有指标的最大值不说，而却宣称一个较小的值。 那么是否真有人在实际环境中测出设备的真实性能跟宣称性能差不多呢? 这是可能的，个人分析原因也是两方面：第一，配置的应用比较单一，例如负载均衡设备配置的是简单的四层处理，而且服务器内容就是一些静态网页。第二，跟产品设计的架构有关，例如本人以前看过某厂商的一款产品，主板跟交换板之间是通过一根1G的网线相连，虽然CPU处理的能力可能是大于1Gbps的，但是根据木板理论，该款设备的性能肯定不可能大于1Gbps， 由于CPU可能还有空闲处理能力，即使对于实际环境的混合流量，CPU的处理结果还是能 够达到1G，瓶颈在于那根网线到底能否达到1G的传输能力，所以实际环境中我们才看到 设备达到了宣称的性能。虽然是这样，但是从产品设计角度来说，性能瓶颈应该是来自于核心处理器的处理能力而不应该是来自于交换带宽的限制，这样的设备其实是有设计缺陷的，所以只能当作1G吞吐量的设备来卖。 2. bypass 这里说的bypass是指硬件bypass，而不是有些人说的某些流量bypass到某条路由，那种只能成为策略转发，不能用bypass字眼。首先明确范围，硬件bypass只能用于网络中处于二层不参与三层路由的设备，例如我们看到的很多的流程设备，在网络中仅仅配一个管理地址，而设备却是二层串接在网络中，对流经的流量做带宽管理，由于不参与三层路由交换，所以流控设备可以做到在设备坏掉或断电的情况下把自己当作网线一样透传流量。 负载均衡设备不存在bypass一说，因为负载均衡设备涉及到路由交换以及地址的访问，举个例子，服务器在负载均衡设备上映射的地址是1.1.1.1，所有用户访问的都是1.1.1.1，当负载均衡设备断电或坏掉,1.1.1.1这个地址在路由上就不存在了，即使bypass，用户也访问不到目的地址。同样对于所有参与路由交换的设备来说，设备断电或坏掉，那一段的路由
负载均衡器部署方式和工作原理
负载均衡器部署方式和工作原理 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对比了一下。
负载均衡方案及详细配置
Apache+Tomcat+mod_jk实现负载均衡方案 一、概述： 原理图： 提高系统可用性，对系统性能影响较小。对于一台服务器Down机后，可自动切换到另 最少需要两台机器，Tomcat1 和Tomcat2可在同一台服务器上。若条件允许最好是各用一台服务器。 二、详细配置步骤： 1、Apache http Server安装 32位的按照提示操作即可。 64位系统的不是安装包。 64位安装配置： 以管理员身份运行cmd 执行：httpd -k install 若无法运行并提示配置错误，请先安装vcredist_x64.exe后再执行。 安装后在Testing httpd.conf...时会报错，不影响。 httpd -k start 启动Apache、httpd -k shutdown 停止Apache 、httpd -k restart重启测试Apache：
在IE中输入：127.0.0.1 打开网页显示It work就OK 2、将Mod_jk的压缩包解压，找到mod_jk.so 复制到Apache目录下modules目录下 64位的下载mod_jk1.2.30_x64.zip 32位的下载tomcat-connectors-1.2.35-windows-i386-httpd-2.0.x.zip 3、修改Apache conf目录下的httpd.conf文件 在最后增加:Include conf/extra/mod_jk.conf 4、在conf/extra 下创建mod_jk.conf文件 增加如下： #load module mod_jk.so LoadModule jk_module modules/mod_jk.so #mod_jk config #load workers JkWorkersFile conf/workers.properties #set log file JkLogFile logs/mod_jk.log #set log level JkLogLevel info #map to the status server #mount the status server JkMount /private/admin/mystatus mystatus JkMount /* balance 5.在conf目录下创建workers.properties文件 增加：worker.tomcat1 中的tomcat1和tomcat2必须和Tomcat中的配置相同。Tomcat配置下面介召 worker.list=balance,mystatus #first worker config worker.tomcat1.type=ajp13 worker.tomcat1.host=192.168.8.204 worker.tomcat1.port=8009 #Tomcat的监听端口 worker.tomcat1.lbfactor=1 worker.tomcat1.socket_timeout=30 worker.tomcat1.socket_keepalive=1 #second worker config worker.tomcat2.type=ajp13 worker.tomcat2.host=192.168.8.204 worker.tomcat2.port=8010 #Tomcat的监听端口实验是在同一机器上做的，所以两个不同
实现服务器负载均衡常见的四种方法
为了提高服务器的性能和工作负载能力，天互云计算通常会使用DNS服务器、网络地址转换等技术来实现多服务器负载均衡，特别是目前企业对外的互联网Web 网站，许多都是通过几台服务器来完成服务器访问的负载均衡。 目前企业使用的所谓负载均衡服务器，实际上它是应用系统的一种控制服务器，所有用户的请求都首先到此服务器，然后由此服务器根据各个实际处理服务器状态将请求具体分配到某个实际处理服务器中，对外公开的域名与IP地址都是这台服务器。负载均衡控制与管理软件安装在这台服务器上，这台服务器一般只做负载均衡任务分配，但不是实际对网络请求进行处理的服务器。 一、企业实现Web服务器负载均衡 为了将负载均匀的分配给内部的多个服务器上，就需要应用一定的负载均衡策略。通过服务器负载均衡设备实现各服务器群的流量动态负载均衡，并互为冗余备份。并要求新系统应有一定的扩展性，如数据访问量继续增大，可再添加新的服务器加入负载均衡系统。 对于WEB服务应用，同时有几台机器提供服务，每台机器的状态可以设为regular(正常工作)或backup(备份状态)，或者同时设定为regular状态。负载均衡设备根据管理员事先设定的负载算法和当前网络的实际的动态的负载情况决定下一个用户的请求将被重定向到的服务器。而这一切对于用户来说是完全透明的，用户完成了对WEB服务的请求，并不用关心具体是哪台服务器完成的。 二、使用网络地址转换实现多服务器负载均衡 支持负载均衡的地址转换网关中可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。很多硬件厂商将这种技术集成在他们的交换机中，作为他们第四层交换的一种功能来实现，一般采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡策略来分配负载。然而硬件实现的负载控制器灵活性不强，不能支持更优化的负载均衡策略和更复杂的应用协议。 基于网络地址转换的负载均衡器可以有效的解决服务器端的CPU和磁盘I/O负载，然而负载均衡器本身的性能受网络I/O的限制，在一定硬件条件下具有一定的带宽限制，但可以通过改善算法和提高运行负载均衡程序的硬件性能，来提高这个带宽限制。不同的服务类型对不同的服务器资源进行占用，我们使用的负载衡量策略是使用同一个负载进行评估，这对于大多数条件是适合的，然而最好的办法是针对不同的资源，如CPU、磁盘I/O或网络I/O 等，分别监视服务器负载，由中心控制器选择最合适的服务器分发客户请求。 三、使用DNS服务器实现负载均衡
软件负载均衡优缺点总结
（总结）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服务器
F5服务器负载均衡方案
目录 部署方式 方式一、单臂旁路接入 方式二、双臂串接 部署说明 F5支持单臂旁路接入和双臂串行等接入方式。因为F5端口个数有限，建议采用单臂旁路模式，即F5旁挂在交换机上，通过交换机完成与服务器和客户端之间的通讯。 原理流程图 ?BIGIP LTM对外提供一个虚拟的应用服务器，接收所有的客户端请求 ?BIGIP LTM通过负载均衡算法处理，将客户端请求转发到后台的多个应用实例 ?BIGIP LTM内置可编程控制接口，可以对流量进行编程控制处理 ?BIGIP LTM通过应用健康检查，准确的判断应用程序的工作和服务状态，一旦发现应用不能提供服务，则将其从负载均衡组中摘除
负载均衡必要性 随着互联网的发展，web服务的数据量越来越大，同时对应用的高可用性提出了更高的要求，服务器主备冗余模式已经不能满足当前需求，作为应用交付行业内最为成熟的方案提供商，F5的负载均衡技术可以实现以下目标： ?实现应用系统%的不间断访问 ?优化应用结构 ?节省服务器资源 ?加速访问，提高用户体验 ?实现应用系统良好的扩展性 相关技术 服务器负载均衡算法 BIG-IP是一台对流量和内容进行管理分配的设备。它提供10种灵活的算法将数据流有效地转发到它所连接的服务器群。而面对用户，只是一台虚拟服务器。用户此时只须记住一台服务器，即虚拟服务器。但他们的数据流却被BIG-IP灵活地均衡到所有的服务器。 这10种算法包括： 轮询（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收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。
负载均衡系统构架
负载均衡系统构架 负载均衡系统构架 【摘要】随着计算机网络和Internet应用的飞速发展，信息共享日益广泛化，并深入到人们工作和生活的各个领域。人们对信息共享的依赖正逐渐增强。而作为提供信息载体的服务器的压力也越来越大，对于电子商务、信息共享平台急需合理分配访问流量来减少服务器的压力。 本文对目前的负载均衡技术进行简单的阐述，并对现有均衡算法进行简单的比较，分析其不足之处。并采用LVS（Linux虚拟服务器）实现负载均衡的架构。采用Keepalived技术实现负载均衡的高可用性。并对LVS不同策略上实现的均衡结果进行详细的比较。最终完成对负载均衡系统的构建同时提供了详细的系统搭建步骤，为研究该方向的人员提供可靠的参考资料。 【关键词】负载均衡、LVS、Keepalived、高并发 中图分类号：TN711 文献标识码：A 文章编号： 简介 1.1背景 目前随着网络技术的迅速崛起，网络信息共享数据越来越大，访问量和数据流量的快速增长，所需的处理能力和运算强度也越来越大，使得单一的服务器设备根本无法承担｡在此情况下，如果花大量的资金进行硬件方面的升级，会造成大量的资源浪费。并且对于下一次升级来说，将会投入更大的成本，如何才能利用现有资源，在少量的投入下解决该问题？ 针对此情况而衍生出来的一种廉价有效透明的方法来扩展现有网络设备和服务器的带宽､增加吞吐量､加强网络数 据处理能力､提高网络的灵活性和可用性的技术就是负载均 衡(Load Balance)。 1.2负载均衡技术概述 负载均衡（又称为负载分担），英文名称为Load Balance，其
F5服务器负载均衡解决方案要点
F5服务器负载均衡解决方案 目录 一．大量数据处理所面临的问题 (2) 1．目前存在隐患 (3) 2．应用系统问题综述 (3) 1)“峰值”问题 (4) 2)多米诺”现象 (4) 3)“N+1”方式 (4) 4)“扩展”不便 (5) 5)“免疫力”差 (5) 6)“容灾”.................................................................................. 错误！未定义书签。 7)应用与网络脱节 (6) 二．F5解决方案 (6) 2.1 网络结构 (6) 2.2 方案优势 (7) 2.2.1避免“不平衡”现象 (7) 2.2.2解决因“峰值堵塞”带来的性能调整“不平衡” (9) 2.2.3避免“多米诺”现象 (9) 2.2.4更好的提供系统容错，提高系统可靠性 (10) 2.2.5“扩展”灵活 (11) 2.2.6“免疫力”强 (12) 2.2.7“容灾” (13) 2.2.8网络感知应用，应用控制网络 (14) 三．相关技术资料 (17) BIG-IP提供支持99.999%的正常运行 (17) 四．成功案例 (19) F5为中国某税务机关提供高可用性解决方案 (19)
一．大量数据处理所面临的问题 在现今的企业中，不论是否提供关键性任务的服务，都需要一个持续运行不断的高可用性网络计算环境以维持不间断的高品质服务。所谓高可用性的环境，也是信息管理人员所必须考虑的四件事： 1.使数据有一个安全的存储和运作方式，即使在设备故障时仍能保持数据的完整 一致。 2.使服务器系统持续运行，即使发生故障仍然让服务持续下去。 3.使整个计算环境能更好的管理，如何容错、容灾、集群共享。 4.如何使投资有最好的效益，使系统有最佳的扩充能力，有最低的整体拥有成本， 也就是在任何情况之下均能确保数据的完整一致，系统持续运行，使服务不间 断，同时有最好的投资回报率。 高可用性被定义为计算系统的连续运行。根据故障停机的业务影响，应用系统需要不同的可用性水平。要想实现一个应用系统的高可用性，所有组件(包括应用和数据库服务器、存储设备以及端到端网络)都需要提供连续的服务。 企业和机构对网络化应用及Internet 的日益依赖，加上语音和数据的集成，创造了对高可用性应用的增加需求。任何类型的系统故障停机都可能意味着收入、信誉和客户满意的巨大损失。 高度网络可用性的利用，企业实施高可用性网络来： ?防止财务损失 ?防止生产力损失 ?改进用户满意度 ?改进客户满意/信任 ?降低反应性IT支持成本，提高IT生产力 ?部署关键任务应用支持新业务实践的好处 ?典型的业务要求 为了实现高度的网络可用性，需要部署下列组件：
网站负载均衡解决方案
网站负载均衡解决方案 Web负载均衡（Load Balancing），简单地说就是给我们的服务器集群分配“工作任务”，而采用恰当的分配方式，对于保护处于后端的Web服务器来说，非常重要。 反向代理负载均衡 反向代理服务的核心工作主要是转发HTTP请求，扮演了浏览器端和后台Web 服务器中转的角色。因为它工作在HTTP层（应用层），也就是网络七层结构中的第七层，因此也被称为“七层负载均衡”。可以做反向代理的软件很多，比较常见的一种是Nginx。 Nginx 是一种非常灵活的反向代理软件，可以自由定制化转发策略，分配服务器流量的权重等。反向代理中，常见的一个问题，就是Web服务器存储的session
数据，因为一般负载均衡的策略都是随机分配请求的。同一个登录用户的请求，无法保证一定分配到相同的Web机器上，会导致无法找到session的问题。 解决方案主要有两种： 配置反向代理的转发规则，让同一个用户的请求一定落到同一台机器上（通过分析cookie），复杂的转发规则将会消耗更多的CPU，也增加了代理服务器的负担。 将session这类的信息，专门用某个独立服务来存储，例如redis/memchache，这个方案是比较推荐的。 反向代理服务，也是可以开启缓存的，如果开启了，会增加反向代理的负担，需要谨慎使用。这种负载均衡策略实现和部署非常简单，而且性能表现也比较好。但是，它有“单点故障”的问题，如果挂了，会带来很多的麻烦。而且，到了后期Web服务器继续增加，它本身可能成为系统的瓶颈。 配置文件样本： #user nobody; worker_processes 1; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; upstream https://www.wendangku.net/doc/0a6598080.html, { server 192.168.1.188:80 weight=5; server 192.168.1.158:80; } server { listen 80; server_name https://www.wendangku.net/doc/0a6598080.html,; location / { proxy_pass https://www.wendangku.net/doc/0a6598080.html,; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
负载均衡原理与技术实现
负载均衡原理与技术实现负载均衡 原理与技术实现 负载均衡(Load Bala nee，简称LB)是一种服务器或网络设备的集群技术。负载均衡将特定的业务(网络服务、网络流量等)分担给多个服务器或网络设备，从而提高了业务处理能力，保证了业务的高可用性。负载均衡基本概念有：实服务、实服务组、虚服务、调度算法、持续性等，其常用应用场景主要是服务器负载均衡，链路负载均衡。 一服务器负载均衡 服务器负载均衡根据LB设备处理到的报文层次，分为四层服务器负载均衡和七层负载均衡，四层处理到IP包的IP头，不解析报文四层以上载荷(L4 SLB);七层处理到报文载荷部分，比如HTTP RTSP SIP报文头，有时也包括报文内容部分(L7 SLB)。
1.四层服务器负载均衡技术 客户端将请求发送给服务器群前端的负载均衡设备，负载均衡设备上的虚服务接收客户端请求，通过调度算法，选择真实服务器，再通过网络地址转换，用真实服务器地址重写请求报文的目标地址后，将请求发送给选定的真实服务器; 真实服务器的响应报文通过负载均衡设备时，报文的源地址被还原为虚服务的VSIP,再返回给客户，完成整个负载调度过程。报文交互流程如下： NAT方式的服务器负载均衡报文交互流程图报文交互流程说明： (1)Host发送服务请求报文，源IP为Host IP、目的IP为VSIP (2)LB Device 接收到请求报文后，借助调度算法
计算出应该将请求分发给哪台Server (3)LB Device使用DNAT技术分发报文，源IP 为Host IP、目的IP 为Server IP (4)Server接收并处理请求报文，返回响应报文，源IP 为Server IP、目的IP 为Host IP (5)LB Device接收响应报文，转换源IP后转发，源IP为VSIP、目的IP为Host IP 2.七层服务器负载均衡技术 七层负载均衡和四层负载均衡相比，只是进行负载均衡的依据不同，而选择确定的实服务器后，所做的处理基本相同，下面以HTTP应用的负载均衡为例来说明。 由于在TCP握手阶段，无法获得HTTP真正的请求内容，因此也就无法将客户的TCP握手报文直接转发给服务器，必须由负载均衡设备先和客 户完成TCP握手，等收到足够的七层内容后，再选择服务器，由负载均衡设备和所选服务器建立TCP连接。 七层负载均衡组网和四层负载均衡组网有一个显著的区别：四层负载均衡每个虚服务对应一个实服务组，实服务组内的所有实服务器提供相同的服务;七层负载均衡每个虚服务对应多个实服务组，每组实服务器
Web负载均衡的几种实现方式
摘要： 负载均衡(Load Balance)是集群技术（Cluster）的一种应用。负载均衡可以将工作任务分摊到多个处理单元，从而提高并发处理能力。目前最常见的负载均衡应用是Web负载均衡。根据实现的原理不同，常见的web负载均衡技术包括：DNS轮询、IP负载均衡和CDN。其中IP负载均衡可以使用硬件设备或软件方式来实现。 什么是web负载均衡 服务器集群(Cluster)使得多个服务器节点能够协同工作，根据目的的不同，服务器集群可以分为：?高性能集群：将单个重负载的请求分散到多个节点进行处理，最后再将处理结果进行汇总 ?高可用集群：提高冗余单元，避免单点故障 ?负载均衡集群：将大量的并发请求分担到多个处理节点。由于单个处理节点的故障不影响整个服务，负载均衡集群同时也实现了高可用性。 一般提到的负载均衡(Load Balance)，是指实现负载均衡集群。负载均衡实现了横向扩展（Scale Out），避免纵向的升级（Scale Up）换代。 本文中的web负载均衡，特指能够分担web请求（http，https等）的负载均衡技术。 基本原理 任何的负载均衡技术都要想办法建立某种一对多的映射机制：一个请求的入口映射到多个处理请求的节点，从而实现分而治之（Divide and Conquer）。 这种映射机制使得多个物理存在对外体现为一个虚拟的整体，对服务的请求者屏蔽了内部的结构。 采用不同的机制建立映射关系，可以形成不同的负载均衡技术，常见的包括： ?DNS轮询 ?CDN ?IP负载均衡 DNS DNS轮询是最简单的负载均衡方式。以域名作为访问入口，通过配置多条DNS A记录使得请求可以分配到不同的服务器。 DNS轮询没有快速的健康检查机制，而且只支持WRR的调度策略导致负载很难“均衡”，通常用于要求不高的场景。并且DNS轮询方式直接将服务器的真实地址暴露给用户，不利于服务器安全。 CDN CDN（Content Delivery Network，内容分发网络）。通过发布机制将内容同步到大量的缓存节点，并在DNS 服务器上进行扩展，找到里用户最近的缓存节点作为服务提供节点。 因为很难自建大量的缓存节点，所以通常使用CDN运营商的服务。目前国内的服务商很少，而且按流量计费，价格也比较昂贵。 IP负载均衡
负载均衡解决方案讲解
负载均衡实现方案 负载均衡是OA 系统多应用和集群部署必不可少的组件。作为多应用和集群部署的前端，负载均衡负责将用户的请求分发到后端各个OA应用上，并将OA 应用的响应返回给用户。 后端的OA 应用可以是独立的多应用部署，也可以是集群部署。两者间的区别在于集群部署可以实现会话复制，即用户的会话可以在集群中的应用间进行复制，其好处在于当用户当前访问的应用宕机时，由于用户会话会被复制到另一正常应用上，因此用户访问将不会受到影响，不需要重新登录OA 系统，而独立的多应用部署没有会话复制功能。 负载均衡为OA 系统提供了高性能、高可靠性和可扩展能力。 高性能，负载均衡可以将用户的访问请求均衡分配到各个OA 应用上，从而避免单一应用负载过高，影响此应用的访问体验； 高可靠性，负载均衡可以探测各个OA 应用的运行状况，自动将出现问题的OA 应用退出负载，避免用户继续访问此应用； 可扩展性，通过扩展负载均衡后的OA 应用数量，从而让OA 系统负担更多的用户并发访问。 实现负载均衡有多种方法，对于OA 系统常见的方法有以下三种： 一、基于JSP 页面的跳转 将一个OA 应用做为主应用，用户统一访问此应用，由此应用上的特定的JSP 页面按轮询的方式将用户平均分配到其他各个应用上。 此方法的优点在于实现简单，且没有成本——不需要额外的设备和软件。 此方法的缺点在于不能提供高可靠性，当其中一个应用出现问题时，主应用仍然会将用户分配到此应用上，只有用户重新访问主应用，主应用才会将用户分配到另外一个应用上。
二、基于反向代理软件 此方法通过反向代理软件实现后端各个 OA 应用间的负载均衡。 1、实现方式 用户通过反向代理软件提供的IP 地址和端口访问OA 系统。过程如下：1）用户将访问请求发送到反向代理软件； 2）反向代理软件根据请求中的特定标识（客户端ip 地址或cookie 标记）将用户请求转发给特定的后端OA 应用——由于 OA 系统是基于用户的，在用户访问过程中始终保持用户会话，因此需要反向代理软件具有会话保持能力——始终将特定用户的请求路由到后端的同一个 OA 应用； 3）后端应用将响应返回给反向代理软件； 4）反向代理软件将响应转发给用户。