精华内容
下载资源
问答
  • php负载均衡技术
    2016-07-14 10:38:08

     

    负载均衡介绍(DNS负载均衡技术、IP负载均衡技术)
     
    前言:
    集群、分布式、负载均衡概念的不同

    1、Linux集群 主要分成三大类( 高可用集群, 负载均衡集群,科学计算集群)(下面只介绍负载均衡集群) 
    负载均衡集群(Load Balance Cluster) 
    负载均衡系统:集群中所有的节点都处于活动状态,它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。 

    负载均衡集群一般用于相应网络请求的网页服务器,数据库服务器。这种集群可以在接到请求时,检查接受请求较少,不繁忙的服务器,并把请求转到这些服务器上。从检查其他服务器状态这一点上看,负载均衡和容错集群很接近,不同之处是数量上更多。 


    2、负载均衡系统:  负载均衡又有DNS负载均衡(比较常用)、IP负载均衡、反向代理负载均衡等,也就是在集群中有服务器A、B、C,它们都是互不影响,互不相干的,任何一台的机器宕了,都不会影响其他机器的运行,当用户来一个请求,有负载均衡器的算法决定由哪台机器来处理,假如你的算法是采用round算法,有用户a、b、c,那么分别由服务器A、B、C来处理; 


    3、分布式 是指将不同的业务分布在不同的地方。 
    而集群指的是将几台服务器集中在一起,实现同一业务。 
    分布式中的每一个节点,都可以做集群。 
    而集群并不一定就是分布式的。 
    举例:就比如新浪网,访问的人多了,他可以做一个群集,前面放一个响应服务器,后面几台服务器完成同一业务,如果有业务访问的时候,响应服务器看哪台服务器的负载不是很重,就将给哪一台去完成。 
    而分布式,从窄意上理解,也跟集群差不多, 但是它的组织比较松散,不像集群,有一个组织性,一台服务器垮了,其它的服务器可以顶上来。 
    分布式的每一个节点,都完成不同的业务,一个节点垮了,哪这个业务就不可访问了。
     
     
      负载均衡技术能够平衡服务器集群中所有的服务器和请求应用之间的通信负载,根据实时响应时间进行判断,将任务交由负载最轻的服务器来处理,以实现真正的智能通信管理和最佳的服务器群性能,从而使网站始终保持运行和保证其可访问性。

      为了充分利用现有服务器软件的种种优势,负载均衡最好是在服务器软件之外来完成。而最早使用的负载均衡技术是通过DNS服务中的随机名字解析来实现的。这就是通常所说的DNS负载均衡技术。

      DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的机器上去,使得不同的客户端访问不同的服务器,从而达到负载均衡的目的。

      直到现在,很多网站仍然使用DNS负载均衡来保证网站的运行和可访问性。从其实现和效果来看,主要有以下优缺点:

      主要优点

      这种技术的主要缺点如下:

      第一,技术实现比较灵活、方便,简单易行,成本低,适用于大多数TCP/IP应用。不需要网络专家来对之进行设定,或在出现问题时对之进行维护。

      第二,对于Web应用来说,不需要对代码作任何的修改。事实上,Web应用本身并不会意识到负载均衡配置,即使在它面前。

      第三,Web服务器可以位于互联网的任意位置上。

      主要缺点

      DNS负载均衡技术在具有以上优点的时候,其缺点也非常明显,主要表现在:

      第一,不能够按照Web服务器的处理能力分配负载。DNS负载均衡采用的是简单的轮循负载算法,不能区分服务器之间的差异,不能反映服务器的当前运行状态。所以DNS服务器将Http请求平均地分配到后台的Web服务器上,而不考虑每个Web服务器当前的负载情况。如果后台的Web服务器的配置和处理能力不同,最慢的 Web服务器将成为系统的瓶颈,处理能力强的服务器不能充分发挥作用。不能做到为性能较好的服务器多分配请求,甚至会出现客户请求集中在某一台服务器上的情况。

      第二,不支持高可靠性,DNS负载均衡技术没有考虑容错。如果后台的某台Web服务器出现故障,DNS服务器仍然会把DNS 请求分配到这台故障服务器上,导致不能响应客户端。

      第三,可能会造成额外的网络问题。为了使本DNS服务器和其他DNS服务器及时交互,保证DNS数据及时更新,使地址能随机分配,一般都要将DNS的刷新时间设置的较小,但太小将会使DNS流量大增造成额外的网络问题。

      第四,一旦某个服务器出现故障,即使及时修改了DNS设置,还是要等待足够的时间(刷新时间)才能发挥作用,在此期间,保存了故障服务器地址的客户计算机将不能正常访问服务器。

      总结

      从上面的总结我们可以看出,总体来说,DNS负载均衡技术方案不应该算是真正意义上的负载均衡,不能够稳定、可靠、高效地满足企业对Web服务器的需求,也不能满足网络用户对网站访问的及时响应和可用性,所以现在很多Web站点方案中,已经很少采用这种方案了。
     
     
     
    二、IP负载均衡技术
     
    首先让我们来看看下面这张大家都非常熟悉的TCP/IP协议族的分层图:
                      
    关于每层在网络数据包传输过程中所起到的作用不是本文的重点,本文主要是讲解如何在网络层中使用IP来做服务器集群的负载均衡,为什么可以在这一层来做负载均衡。下面在来看IP协议的报头格式:
                    
    内红色框内的源地址和目的地址是IP负载均衡功能的关键所在,IP负载均衡又可以称之为网络层负载均衡,其核心原理就是通过内核驱动更改IP的目的地址来完成数据负载均衡的,如下图:
                       
        如上图所示,用户请求数据包(源地址为200.110.50.1)到达负载均衡服务器114.100.20.200后,负载均衡服务器在内核进程获取网络数据包,根据一定的负载均衡算法得到一台内部的真实服务器192.168.1.1,然后将数据包的目的IP修改为192.168.1.1,此后数据包将会被发往192.168.1.1的服务器上,服务器处理完后,将向负载均衡服务器返回相应的数据包,负载均衡服务器在把源地址修改为114.100.20.200后将数据包传输给用户浏览器。在这一整个过程中,数据包没有通过用户的应用进程,因此该负载均衡的性能是非常之高的。
        根据以上的图和上文的讲解,大家可能会觉得这很容易实现,其实不然,在这里需要处理关键的地方就是如何将集群内部服务器处理完后的数据返回给负载均衡服务器。因为,用户请求的数据包到达负载均衡服务器前的目的地址是114.100.20.200,源地址是200.110.50.1,通过负载均衡服务器修改后的目的地址是192.168.1.1,源地址还是200.110.50.1,所以处理后返回的数据包目的地址将是200.110.50.1,源地址是192.168.1.1,最终返回的数据包要回到负载均衡服务器就成了问题。解决的办法大概有如下两种:一、负载均衡服务器使用双网卡,一个对内一个对外,在修改请求数据包的目的IP的同时也修改源地址,将源地址设为自身的IP,即源地址转换(SNAT),这样内部集群服务器响应会再回到负载均衡服务器;二、将负载均衡服务器作为真实物理服务器集群的网关服务器,这样所有的响应都将通过负载均衡服务器。
        IP负载均衡在内核进程完成数据分发,处理性能得到了很好的提高。但是由于所有请求和响应都要经过负载均衡服务器,集群的最大响应数据吞吐量将受到负载均衡服务器网卡带宽的限制,对于提供下载服务或者视频服务等需要大量传输数据的站点而言,这是难以满足需求的。要是能让响应数据包绕过负载均衡服务器直接发往用户机器上就好了,有什么办法可以做到呢?当然有,那就是链路层的负载均衡,这将在下一博文中讲解。
    IP负载均衡技术

    上一章节讲述了可伸缩网络服务的几种结构,它们都需要一个前端调度器。在调度器的实现技术中,IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换(Network Address Translation)将一组服务器构成一个高性能的、高可用的虚拟服务器,我们称之为VS/NAT技术(Virtual Server via Network Address Translation),大多数商品化的IP负载均衡调度器产品都是使用此方法,如Cisco的LocalDirector、F5的Big/IP和Alteon的ACEDirector。在分析VS/NAT的缺点和网络服务的非对称性的基础上,我们提出通过IP隧道实现虚拟服务器的方法VS/TUN(Virtual Server via IP Tunneling),和通过直接路由实现虚拟服务器的方法VS/DR(Virtual Server via Direct Routing),它们可以极大地提高系统的伸缩性。

    本章节将描述三种IP负载均衡技术VS/NAT、VS/TUN和VS/DR的工作原理,以及它们的优缺点。在以下描述中,我们称客户的socket和服务器的socket之间的数据通讯为连接,无论它们是使用TCP还是UDP协议。

    一、通过NAT实现虚拟服务器(VS/NAT)

    由于IPv4中IP地址空间的日益紧张和安全方面的原因,很多网络使用保留IP地址(10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0)[64, 65, 66]。这些地址不在Internet上使用,而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时,就需要采用网络地址转换(Network Address Translation, 以下简称NAT),将内部地址转化为Internets上可用的外部地址。NAT的工作原理是报文头(目标地址、源地址和端口等)被正确改写后,客户相信它们连接一个IP地址,而不同IP地址的服务器组也认为它们是与客户直接相连的。由此,可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。

    VS/NAT的体系结构如图3.1所示。在一组服务器前有一个调度器,它们是通过Switch/HUB相连接的。这些服务器提供相同的网络服务、相同的内容,即不管请求被发送到哪一台服务器,执行结果是一样的。服务的内容可以复制到每台服务器的本地硬盘上,可以通过网络文件系统(如NFS)共享,也可以通过一个分布式文件系统来提供。



    图3.1:VS/NAT的体系结构

    客户通过Virtual IP Address(虚拟服务的IP地址)访问网络服务时,请求报文到达调度器,调度器根据连接调度算法从一组真实服务器中选出一台服务器,将报文的目标地址Virtual IP Address改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送给选出的服务器。同时,调度器在连接Hash表中记录这个连接,当这个连接的下一个报文到达时,从连接Hash表中可以得到原选定服务器的地址和端口,进行同样的改写操作,并将报文传给原选定的服务器。当来自真实服务器的响应报文经过调度器时,调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口,再把报文发给用户。我们在连接上引入一个状态机,不同的报文会使得连接处于不同的状态,不同的状态有不同的超时值。在TCP连接中,根据标准的TCP有限状态机进行状态迁移;在UDP中,我们只设置一个UDP状态。不同状态的超时值是可以设置的,在缺省情况下,SYN状态的超时为1分钟,ESTABLISHED状态的超时为15分钟,FIN状态的超时为1分钟;UDP状态的超时为5分钟。当连接终止或超时,调度器将这个连接从连接Hash表中删除。

    这样,客户所看到的只是在Virtual IP Address上提供的服务,而服务器集群的结构对用户是透明的。对改写后的报文,应用增量调整Checksum的算法调整TCP Checksum的值,避免了扫描整个报文来计算Checksum的开销。

    在一些网络服务中,它们将IP地址或者端口号在报文的数据中传送,若我们只对报文头的IP地址和端口号作转换,这样就会出现不一致性,服务会中断。所以,针对这些服务,需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。我们所知道有这个问题的网络服务有FTP、IRC、H.323、CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。

    下面,举个例子来进一步说明VS/NAT,如图3.2所示:



    图3.2:VS/NAT的例子

    VS/NAT的配置如下表所示,所有到IP地址为202.103.106.5和端口为80的流量都被负载均衡地调度的真实服务器172.16.0.2:80和172.16.0.3:8000上。目标地址为202.103.106.5:21的报文被转移到172.16.0.3:21上。而到其他端口的报文将被拒绝。

    Protocol Virtual IP Address Port Real IP Address Port Weight TCP 202.103.106.5 80 172.16.0.2 80 1 172.16.0.3 8000 2 TCP 202.103.106.5 21 172.16.0.3 21 1

    从以下的例子中,我们可以更详细地了解报文改写的流程。

    访问Web服务的报文可能有以下的源地址和目标地址:

    SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80

    调度器从调度列表中选出一台服务器,例如是172.16.0.3:8000。该报文会被改写为如下地址,并将它发送给选出的服务器。

    SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000

    从服务器返回到调度器的响应报文如下:

    SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456

    响应报文的源地址会被改写为虚拟服务的地址,再将报文发送给客户:

    SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456

    这样,客户认为是从202.103.106.5:80服务得到正确的响应,而不会知道该请求是服务器172.16.0.2还是服务器172.16.0.3处理的。

    二、通过IP隧道实现虚拟服务器(VS/TUN)

    在VS/NAT的集群系统中,请求和响应的数据报文都需要通过负载调度器,当真实服务器的数目在10台和20台之间时,负载调度器将成为整个集群系统的新瓶颈。大多数Internet服务都有这样的特点:请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理,即在负载调度器中只负责调度请求而响应直接返回给客户,将极大地提高整个集群系统的吞吐量。

    IP隧道(IP tunneling)是将一个IP报文封装在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态建立的,隧道一端有一个IP地址,另一端也有唯一的IP地址。

    我们利用IP隧道技术将请求报文封装转发给后端服务器,响应报文能从后端服务器直接返回给客户。但在这里,后端服务器有一组而非一个,所以我们不可能静态地建立一一对应的隧道,而是动态地选择一台服务器,将请求报文封装和转发给选出的服务器。这样,我们可以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。VS/TUN的体系结构如图3.3所示,各个服务器将VIP地址配置在自己的IP隧道设备上。



    图3.3:VS/TUN的体系结构

    VS/TUN的工作流程如图3.4所示:它的连接调度和管理与VS/NAT中的一样,只是它的报文转发方法不同。调度器根据各个服务器的负载情况,动态地选择一台服务器,将请求报文封装在另一个IP报文中,再将封装后的IP报文转发给选出的服务器;服务器收到报文后,先将报文解封获得原来目标地址为VIP的报文,服务器发现VIP地址被配置在本地的IP隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。



    图3.4:VS/TUN的工作流程

    在这里,请求报文的目标地址为VIP,响应报文的源地址也为VIP,所以响应报文不需要作任何修改,可以直接返回给客户,客户认为得到正常的服务,而不会知道是哪一台服务器处理的。

    在VS/TUN中,响应报文根据服务器的路由表直接返回给客户,而不经过负载调度器,所以负载调度器只处于从客户到服务器的半连接中,VS/TUN的TCP状态迁移与VS/NAT的不同。我们给出半连接的TCP有限状态机,如图3.5所示,圈表示状态,箭头表示状态间的转换,箭头上的标识表示在当前状态上收到该标识的输入,迁移到下一个状态。VS/TUN的TCP状态迁移是按照半连接的TCP有限状态机进行的。



    图3.5:半连接的TCP有限状态机

    三、通过直接路由实现虚拟服务器(VS/DR)

    跟VS/TUN方法相同,VS/DR利用大多数Internet服务的非对称特点,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量。该方法与IBM的NetDispatcher产品中使用的方法类似,但IBM的NetDispatcher是非常昂贵的商品化产品,我们也不知道它内部所使用的机制,其中有些是IBM的专利。

    VS/DR的体系结构如图3.6所示:调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连,如通过交换机或者高速的HUB相连。VIP地址为调度器和服务器组共享,调度器配置的VIP地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只是用于处理目标地址为VIP的网络请求。



    图3.6:VS/DR的体系结构

    VS/DR的工作流程如图3.7所示:它的连接调度和管理与VS/NAT和VS/TUN中的一样,它的报文转发方法又有不同,将报文直接路由给目标服务器。在VS/DR中,调度器根据各个服务器的负载情况,动态地选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址,再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器,所以服务器肯定可以收到这个数据帧,从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,然后根据路由表将响应报文直接返回给客户。



    图3.7:VS/DR的工作流程

    在VS/DR中,请求报文的目标地址为VIP,响应报文的源地址也为VIP,所以响应报文不需要作任何修改,可以直接返回给客户,客户认为得到正常的服务,而不会知道是哪一台服务器处理的。

    VS/DR负载调度器也只处于从客户到服务器的半连接中,按照半连接的TCP有限状态机进行状态迁移。

    四、三种方法的优缺点比较三种IP负载均衡技术的优缺点归纳在下表中: VS/NAT VS/TUN VS/DR Server any Tunneling Non-arp device server network private LAN/WAN LAN server number low (10~20) High (100) High (100) server gateway load balancer own router Own router

    注:以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡,调度器的硬件配置与后端服务器的硬件配置相同,而且是对一般Web服务。使用更高的硬件配置(如千兆网卡和更快的处理器)作为调度器,调度器所能调度的服务器数量会相应增加。当应用不同时,服务器的数目也会相应地改变。所以,以上数据估计主要是为三种方法的伸缩性进行量化比较。

    4.1、Virtual Server via NAT

    VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统,它只需要一个IP地址配置在调度器上,服务器组可以用私有的IP地址。缺点是它的伸缩能力有限,当服务器结点数目升到20时,调度器本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应报文都需要通过负载调度器。 我们在Pentium 166 处理器的主机上测得重写报文的平均延时为60us,性能更高的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes,则调度器的最大吞吐量为8.93 MBytes/s. 我们再假设每台服务器的吞吐量为800KBytes/s,这样一个调度器可以带动10台服务器。(注:这是很早以前测得的数据)

    基于 VS/NAT的的集群系统可以适合许多服务器的性能要求。如果负载调度器成为系统新的瓶颈,可以有三种方法解决这个问题:混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中,有若干个VS/NAT负载调度器,每个负载调度器带自己的服务器集群,同时这些负载调度器又通过RR-DNS组成简单的域名。但VS/TUN和VS/DR是提高系统吞吐量的更好方法。

    对于那些将IP地址或者端口号在报文数据中传送的网络服务,需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。这会带来实现的工作量,同时应用模块检查报文的开销会降低系统的吞吐率。

    4.2、Virtual Server via IP Tunneling在VS/TUN 的集群系统中,负载调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直接返回给用户。这样,负载调度器就可以处理大量的请求,它甚至可以调度百台以上的服务器(同等规模的服务器),而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡,整个系统的最大吞吐量可超过 1Gbps。所以,VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器,而它本身不会成为系统的瓶颈,可以用来构建高性能的超级服务器。

    VS/TUN技术对服务器有要求,即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。目前,VS/TUN的后端服务器主要运行Linux操作系统,我们没对其他操作系统进行测试。因为“IP Tunneling”正成为各个操作系统的标准协议,所以VS/TUN应该会适用运行其他操作系统的后端服务器。

    4.3、Virtual Server via Direct Routing

    跟VS/TUN方法一样,VS/DR调度器只处理客户到服务器端的连接,响应数据可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。

    跟VS/TUN相比,这种方法没有IP隧道的开销,但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上,服务器网络设备(或者设备别名)不作ARP响应,或者能将报文重定向(Redirect)到本地的Socket端口上。

    五、小结
     
    本章主要讲述了可伸缩网络服务LVS框架中的三种IP负载均衡技术。在分析网络地址转换方法(VS/NAT)的缺点和网络服务的非对称性的基础上,我们给出了通过IP隧道实现虚拟服务器的方法VS/TUN,和通过直接路由实现虚拟服务器的方法VS/DR,极大地提高了系统的伸缩性。
     
    NAT负载均衡技术详解:
     
    首先让我们来看看下面这张大家都非常熟悉的TCP/IP协议族的分层图:
                      
    关于每层在网络数据包传输过程中所起到的作用不是本文的重点,本文主要是讲解如何在网络层中使用IP来做服务器集群的负载均衡,为什么可以在这一层来做负载均衡。下面在来看IP协议的报头格式:
                    
    内红色框内的源地址和目的地址是IP负载均衡功能的关键所在,IP负载均衡又可以称之为网络层负载均衡,其核心原理就是通过内核驱动更改IP的目的地址来完成数据负载均衡的,如下图:
                       
        如上图所示,用户请求数据包(源地址为200.110.50.1)到达负载均衡服务器114.100.20.200后,负载均衡服务器在内核进程获取网络数据包,根据一定的负载均衡算法得到一台内部的真实服务器192.168.1.1,然后将数据包的目的IP修改为192.168.1.1,此后数据包将会被发往192.168.1.1的服务器上,服务器处理完后,将向负载均衡服务器返回相应的数据包,负载均衡服务器在把源地址修改为114.100.20.200后将数据包传输给用户浏览器。在这一整个过程中,数据包没有通过用户的应用进程,因此该负载均衡的性能是非常之高的。
        根据以上的图和上文的讲解,大家可能会觉得这很容易实现,其实不然,在这里需要处理关键的地方就是如何将集群内部服务器处理完后的数据返回给负载均衡服务器。因为,用户请求的数据包到达负载均衡服务器前的目的地址是114.100.20.200,源地址是200.110.50.1,通过负载均衡服务器修改后的目的地址是192.168.1.1,源地址还是200.110.50.1,所以处理后返回的数据包目的地址将是200.110.50.1,源地址是192.168.1.1,最终返回的数据包要回到负载均衡服务器就成了问题。解决的办法大概有如下两种:一、负载均衡服务器使用双网卡,一个对内一个对外,在修改请求数据包的目的IP的同时也修改源地址,将源地址设为自身的IP,即源地址转换(SNAT),这样内部集群服务器响应会再回到负载均衡服务器;二、将负载均衡服务器作为真实物理服务器集群的网关服务器,这样所有的响应都将通过负载均衡服务器。
        IP负载均衡在内核进程完成数据分发,处理性能得到了很好的提高。但是由于所有请求和响应都要经过负载均衡服务器,集群的最大响应数据吞吐量将受到负载均衡服务器网卡带宽的限制,对于提供下载服务或者视频服务等需要大量传输数据的站点而言,这是难以满足需求的。要是能让响应数据包绕过负载均衡服务器直接发往用户机器上就好了,有什么办法可以做到呢?当然有,那就是链路层的负载均衡,这将在下一博文中讲解。
     
     
    三、反向代理负载均衡
     
     
           反向代理,是把一些静态资源存储在服务器上,当用户有请求的时候,就直接返回反向代理服务器上的资源给用户,而如果反向代理服务器上没有的资源,就转发给后面的负载均衡服务器,负载均衡服务器再将请求分发给后端的web服务器。        区别就是:反向代理服务器是需要存储资源的,让用户更快速的接收到资源    负载均衡就是,为了保证后端web服务器的高可用,高并发,是不需要要存储资源,只需要转发用户的请求。
     
    反向代理负载均衡
     

    向代理负载均衡是普通代理方式,是代理内部网络用户访问internet上服务器的连接请求,客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。

    基本信息

    • 中文名称

      反向代理负载均衡

     
    • 外文名称

      reverse-proxyloadbalancing

    目录
     
    1概念
     
    2nginx 实现反向代理负载均衡

    使用代理服务器可以将请求转发给内部的Web服务器,使用这种加速模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术,让代理服务器将请求 均匀转发给多台内部Web服务器之一上,从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同,标准代理方式是客户使用代理访问多个外部Web 服务器,而这种代理方式是多个客户使用它访问内部Web服务器,因此也被称为反向代理模式。

     
    概念

    实现这个反向代理能力并不能算是一个特别复杂的任务,但是在负载均衡中要求特别高的效率,这样实现起来就不是十分简单的了。每针对一次代理,代理服务器就 必须打开两个连接,一个为对外的连接,一个为对内的连接,因此对于连接请求数量非常大的时候,代理服务器的负载也就非常之大了,在最后反向代理服务器会成 为服务的瓶颈。例如,使用Apache的mod_rproxy模块来实现负载均衡功能时,提供的并发连接数量受Apache本身的并发连接数量的限制。一 般来讲,可以使用它来对连接数量不是特别大,但每次连接都需要消耗大量处理资源的站点进行负载均衡,例如搜寻。

    使用反向代理的好处是,可以将负载均衡和代理服务器的高速缓存技术结合在一起,提供有益的性能,具备额外的安全性,外部客户不能直接访问真实的服务器。并 且实现起来可以实现较好的负载均衡策略,将负载可以非常均衡的分给内部服务器,不会出现负载集中到某个 服务器的偶然现象。

     
    ginx实现反向代理负载均衡 1)环境:

    a. 本地使用Windows系统,然后使用VirutalBox安装一个虚拟的Linux系统。

    在本地的Windows系统上分别安装nginx(侦听8080端口)和apache(侦听80端口)。在虚拟的Linux系统上安装apache(侦听80端口)。这样相当于拥有了1台nginx在前端作为反向代理服务器;后面有2台apache作为应用程序服务器(可以看作是小型的server cluster。;-));

    b. nginx用来作为反向代理服务器,放置到两台apache之前,作为用户访问的入口;

    nginx仅仅处理静态页面,动态的页面(php请求)统统都交付给后台的两台apache来处理。也就是说,可以把网站的静态页面或者文件放置到nginx的目录下;动态的页面和数据库访问都保留到后台的apache服务器上。

    c. 如下两种方法实现server cluster的负载均衡。

    假设前端nginx(为127.0.0.1:8080)仅仅包含一个静态页面index.html;后 台的两个apache服务器(分别为localhost:80和158.37.70.143:80),一台根目录放置phpMyAdmin文件夹和 test.php(里面测试代码为print "server1";),另一台根目录仅仅放置一个test.php(里面测试代码为print "server2";)。

    2)针对不同请求的负载均衡:

    a. 在最简单地构建反向代理的时候(nginx仅仅处理静态不处理动态内容,动态内容交给后台的apache server来处理),具体的设置为:在nginx.conf中修改:

    location ~ \.php$ {

    proxy_pass 158.37.70.143:80;

    }

    >;这样当客户端访问localhost:8080/index.html的时候,前端的nginx会自动进行响应;

    >;当用户访问localhost:8080/test.php的时候(这个时候nginx目录下根本就没有该文件),但是通过上面的设置location ~ \.php$(表示正则表达式匹配以.php结尾的文件,详情参看location是如何定义和匹配的),nginx服务器会自动pass给158.37.70.143的apache服务器了。该服务器下的test.php就会被自动解析,然后将html的 结果页面返回给nginx,然后nginx进行显示(如果nginx使用memcached模块或者squid还可以支持缓存),输出结果为打印 server2。

    如上是最为简单的使用nginx做为反向代理服务器的例子;

    b. 我们现在对如上例子进行扩展,使其支持如上的两台服务器。

    设置nginx.conf的server模块部分,将对应部分修改为:

    location ^~ /phpMyAdmin/ {

    proxy_pass 127.0.0.1:80;

    }

    location ~ \.php$ {

    proxy_pass 158.37.70.143:80;

    }

    上面第一个部分location ^~ /phpMyAdmin/,表示不使用正则表达式匹配(^~),而是直接匹配,也就是如果客户端访问的URL是以http://localhost:8080/phpMyAdmin/开头的话(本地的nginx目录下根本没有phpMyAdmin目录),nginx会自动pass到127.0.0.1:80的Apache服务器,该服务器对phpMyAdmin目录下的页面进行解析,然后将结果发送给nginx,后者显示;

    如果客户端访问URL是http://localhost/test.php的话,则会被pass到158.37.70.143:80的apache进行处理。

    因此综上,实现了针对不同请求的负载均衡。

    >;如果用户访问静态页面index.html,最前端的nginx直接进行响应;

    >;如果用户访问test.php页面的话,158.37.70.143:80的Apache进行响应;

    >;如果用户访问目录phpMyAdmin下的页面的话,127.0.0.1:80的Apache进行响应;

    3)访问同一页面的负载均衡:

    用户访问http://localhost:8080/test.php这个同一页面的时候,实现了两台服务器的负载均衡(实际情况中,这两个服务器上的数据要求同步一致,这里我们分别定义了打印server1和server2是为了进行辨认区别)。

    a. 现在的情况是在windows下nginx是localhost侦听8080端口;

    两台apache,一台是127.0.0.1:80(包含test.php页面但是打印server1),另一台是虚拟机的158.37.70.143:80(包含test.php页面但是打印server2)。

    b. 因此重新配置nginx.conf为:

    >;首先在nginx的配置文件nginx.conf的http模块中添加,服务器集群server cluster(我们这里是两台)的定义:

    upstream myCluster {

    server 127.0.0.1:80;

    server 158.37.70.143:80;

    }

    表示这个server cluster包含2台服务器

    >;然后在server模块中定义,负载均衡:

    location ~ \.php$ {

    proxy_passhttp://myCluster; #这里的名字和上面的cluster的名字相同

    proxy_redirect off;

    proxy_set_header Host $host;

    proxy_set_header X-Real-IP $remote_addr;

    proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;

    }

    这样的话,如果访问http://localhost:8080/test.php页面的话,nginx目录下根本没有该文件,但是它会自动将其pass到myCluster定义的服务区机群中,分别由127.0.0.1:80;或者158.37.70.143:80;来做处理。上面在定义upstream的时候每个server之后没有定义权重,表示两者均衡;如果希望某个更多响应的话例如:

    upstream myCluster {

    server 127.0.0.1:80weight=5;

    server 158.37.70.143:80;

    }

     

    综上,通过使用nginx的反向代理服务器reverse proxy server的功能,将其布置到多台apache server的前端。nginx仅仅用来处理静态页面响应和动态请求的代理pass,后台的apache server作为app server来对前台pass过来的动态页面进行处理并返回给nginx。

    通过以上的架构,我们可以实现nginx和多台apache构成的机群cluster的负载均衡。

    两种均衡:

    1)可以在nginx中定义访问不同的内容,代理到不同的后台server;如上例子中的访问phpMyAdmin目录代理到第一台server上;访问test.php代理到第二台server上;

    2)可以在nginx中定义访问同一页面,均衡(当然如果服务器性能不同可以定义权重来均衡)地代理到不同的后台server上。如上的例子访问test.php页面,会均衡地代理到server1或者server2上。

    实际应用中,server1和server2上分别保留相同的app程序和数据,需要考虑两者的数据同步。
     
     
     
     
     
     
     
     
     
     
     
     
     
    反向代理,是把一些静态资源存储在服务器上,当用户有请求的时候,就直接返回 反向代理服务器上的资源给用户,而如果 反向代理服务器上没有的资源,就转发给后面的 负载均衡服务器负载均衡服务器再将请求分发给后端的web服务器。        区别就是:反向代理服务器是需要存储资源的,让用户更快速的接收到资源    负载均衡就是,为了保证后端web服务器的高可用,高并发,是不需要要存储资源,只需要转发用户的请求。
     
    反向代理,是把一些静态资源存储在服务器上,当用户有请求的时候,就直接返回 反向代理服务器上的资源给用户,而如果 反向代理服务器上没有的资源,就转发给后面的 负载均衡服务器负载均衡服务器再将请求分发给后端的web服务器。        区别就是:反向代理服务器是需要存储资源的,让用户更快速的接收到资源    负载均衡就是,为了保证后端web服务器的高可用,高并发,是不需要要存储资源,只需要转发用户的请求。
    更多相关内容
  • PHP超级负载均衡

    2020-12-31 02:27:51
    摘要超级负载均衡旨在为解决服务不断扩展、机器不断增多、机器性能差异等问题,以增强系统的稳定性,自动分配请求压力。算法实现了多个模型和均衡策略,能通过配置实现随机、轮询、一致hash等。同时也能实现跨机房的...

    摘要

    超级负载均衡旨在为解决服务不断扩展、机器不断增多、机器性能差异等问题,以增强系统的稳定性,自动分配请求压力。算法实现了多个模型和均衡策略,能通过配置实现随机、轮询、一致hash等。同时也能实现跨机房的相关分配。现已经在多个系统中使用。

    TAG

    负载均衡

    内容

    现有系统中存在的问题:

    1.慢连接、瞬时访问慢。

    场景一:

    如果后端新增加机器,cache命中率低,因此响应速度慢,但是能连接上且不超时。如果ui持续访问就会把ui夯住。

    场景二:

    如果后端模块某一台机器响应较慢。如果前端持续访问就会被夯住。

    2.死机。

    场景一:

    能断断续续响应请求,不过速度很慢。造成ui夯住。

    3.混合部署。

    场景一:

    多个模块在同一机器上,项目影响。

    4.机器权重。

    场景一:

    老机器,性能差;新机器,性能彪悍。因此他们应该承载不同的压力。

    5.跨机房冗余。

    场景一:

    后端对cache依赖很高的模块,因为采用的是一致hash算法,如果挂掉一台机器,对另外的机器cache命中率冲击很大。因此希望将对这个机器的请求均衡到另外一个机房。

    6. php和c使用同样的策略。

    现在php和c希望能使用的策略实际上是有很大的一致。为了避免重复开发,php和c希望采用同样的负载均衡库。

    要解决的问题:

    设计思路:

    1. 根据均衡策略计算出的均衡值对Server进行逆序排序。

    2. 负载选择。对步骤1排序后的Server按以下顺序进行选择:

    a、按连接失败概率进行选择。

    注:横轴代表失败次数,纵轴代表选择的概率。

    Cconn:一段区间内失败次数

    f(Cconn):连接概率,取值范围在(0,100]

    b、按健康状态选择。

    整个模型基于服务处理时间的收敛性。

    分析:

    1) 如果机器状态良好,则平均处理时间会保持在一个稳定水平;即使是小波动,也会较快平稳在一个状态。

    2) 如果机器开始出现问题,处理时间会开始增长。如果增长持续超过一段时间,则说明有可能会影响服务;如果一段时间后稳定了,说明对请求没有太多影响。

    f(healthy):机器健康状态,取值范围[0,1]

    select(healthy):机器选择概率,取值范围[R,1]

    c、如果所有机器都没选中,则随机选择一台机器进行服务。

    3. 机器流量均分。

    不同的机器处理能力是不一样的。当按照步骤2选择了某台机器,需要将其他处理时间为他的1/T(T>=2)的机器也选取出来,将部分压力分给对应的机器。

    设k台机器的处理时间分别是t1, t2,…,tk, 选中的机器id=i,比该机器处理能力高的机器时间分别为p1,p2,..,pr, (其中pj × T <= ti)。设一段时间总访问量为Y,每台机器理论上的访问量应该为Vg=Y/k。而实际的Vr=Y/(ti * (1/t1+1/t2+…+1/tk))。则应该分出Vg-Vr的流量给pj。pj的流量比例为1/p1:1/p2:…:1/pr

    算法设计:

    A、均衡算法

    1. 一致hash算法。

    将每个server的ip和port加上balance_key三者做字符串拼接后,做md5签名。

    value(server) = md5(server_ip + server_port + balance_key)

    2. 随机算法。

    value(server) = random();

    3. 轮询算法。

    value(server) =((server.id – (rounds % server_count)) + server_count) % server_count

    4. 多个选一算法。

    rank初始化为1, 如果默认的server失败,则rank+1

    value(server) =((server.id – (rank % server_count)) + server_count) % server_count

    B、负载算法

    1. 连接状态算法。

    a、对每一个server开辟一个状态队列。bool queue[K] 用来统计失败次数。每次有坏状态进队,计数加一。如果有坏状态出队,则计数减一。

    b、按照f(Cconn)公式计算出选择概率。

    c、利用rand()%100是否在[0,f(Cconn)]来决定是否选择该机器。

    2. 健康状态算法。

    a、每台机器维持一个一秒钟内的处理时间T和次数C。

    b、当一秒过去以后,将T、C计算为平均处理时间R。

    c、每M秒,统计每台机器最近一段时间的平均处理时间, 按照公式select(healthy)算出选择概率。

    d、利用rand()%100是否在[0, select(healthy)*100]来决定是否选择该机器。

    C、流量均分

    按照策略选出满足要求的机器,按照流量均分公式进行流量分配。

    分配时按照balance_key+server方式和random()来分配机器, 尽量保证请求落在同一台机器。

    展开全文
  • PHP开发负载均衡指南

    2021-01-20 00:19:04
    今天,’大型服务器’模式已经过去,取而代之的是大量的小服务器,使用各种各样的负载均衡技术。这是一种更可行的方法,将使硬件成本降至最低。 ‘更多小服务器’的优势超过过去的’大型服务器’模式体现在两个方面...
  • 一、实验目的:负载均衡PHP应用二、逻辑构建:三、实验需要:4台虚拟机,一台作为客户端,一台作为VS,两台作为RS四、实验环境:VS的DIP要与RS的IP在同一个私网内,RS的默认网关为DIP;VS则要开启路由转发功能echo 1...

    一、实验目的:负载均衡PHP应用

    二、逻辑构建:

    3c8ce6380daa33c267ccb0e2e66a02de.png

    三、实验需要:4台虚拟机,一台作为客户端,一台作为VS,两台作为RS

    四、实验环境:VS的DIP要与RS的IP在同一个私网内,RS的默认网关为DIP;VS则要开启路由转发功能echo 1>/proc/sys/net/ipv4/ip_forword,注意防火墙和selinux都要关闭

    五、实验步骤:

    1、设置相应IP地址

    2、开启VS路由转发

    echo 1>/proc/sys/net/ipv4/ip_forword

    3、在RS上安装httpd、php、php-mysql、mariadb-server,并启动httpd和mariadb,

    a)编辑两个RS的/var/www/html/index.html的首页文件

    编辑RS1

    Vim /var/www/html/index.html

    Hello,I am RS 1,192.168.0.2

    编辑RS2

    Vim /var/www/html/index.html

    Hello,I am RS 1,192.168.0.4

    Systemctl start httpd

    b)设置RS1数据库

    systemctl start mariadb

    mysql –uroot –h127.0.0.1  #授权远程用户的连接

    >create databse wpdb;

    >grant all privileges on wpdb *.* to

    wpuser@’%’ identified by “wppass”;

    >quit

    4、布置VS规则

    ipvsadm -A -t 172.18.24.1:80 -s rr

    ipvsadm -a -t 172.18.24.1:80 -r

    192.168.0.2:80 -m

    ipvsadm -a -t 172.18.24.1:80 -r 192.168.0.4:80

    –m

    5、在客户端上检验:

    For i in {1..10};do curl

    http://172.18.24.1;done

    查看显示信息,判断是否按照制定规则进行轮询。如没有按照轮询显示效果,则重返上述步骤,检查修改,若显示效果正常则继续。

    6、在RS1上安装nfs-utils,并启动服务

    Yum install nfs-utils

    Systemctl start nfs

    7、在RS1创建共享文件download

    Mkdir /var/www/html/download

    Chown –R mysql.mysql /var/www/html/download

    Vim /etc/exports

    /var/www/html/download 192.168.0.4/24(rw,all_squash,anonuid=27,anongid=27)  #定义所有人压缩,27为mysql的uid,注意客户端必须也有个mysql其UID也是27

    Exports –ra

    把wordpress放置在共享文档里,并且给予其写权限

    Chmod –R o+w /var/www/html/download/wordpress

    8、RS2挂载共享文档

    Mkdir /var/www/html/download

    mount –t nfs 172.18.24.1: /var/www/html/download

    /var/www/html/download

    9、测试:前端访问WordPress,并检测WordPress是否有上传、读写等功能。

    六、实验总结:通过实验,客户端访问服务器的动态页面时候,需要会话保持,否则其会根据VS上设置的轮询规则,进行刷新,导致页面不能正常加载使用,并且RS服务器需要实现共享存储,才能确保信息的完整性。

    原创文章,作者:chenxu@magedu.com,如若转载,请注明出处:http://www.178linux.com/75120

    展开全文
  • 通过高性能缓存技术,将已经部署好的多套应用实例地址读入缓存,按照设定的权重进行转发。例如设计5个实例可设计将流量平均分配到5个实例上。应用实例可以在单台或多台服务器上。 运行环境: 1..net 运行环境2.0及...
  • 应用Docker容器技术部署Nginx负载均衡

    千次阅读 2022-03-28 18:31:17
    利用Docker容器技术实现如下负载均衡 # 搜索nginx镜像 docker search nginx # 拉取nginx镜像 docker pull nginx # 检查镜像是否拉取成功 docker images # 运行一个测试的nginx docker run -d --name nginxtest ...

    利用Docker容器技术实现如下负载均衡

    在这里插入图片描述

    # 搜索nginx镜像
    docker search nginx
    # 拉取nginx镜像
    docker pull nginx
    # 检查镜像是否拉取成功
    docker images
    # 运行一个测试的nginx
    docker run -d --name nginxtest nginx
    # 把容器里的nginx目录复制出来,配置是放在/etc/nginx
    docker cp nginxtest:/etc/nginx ./
    # 把容器里的log目录复制出来,日志是放在/var/log
    docker cp nginxtest:/var/log ./
    # 删除测试的nginx-test
    docker rm -f nginxtest
    # 查看nginx配置结构
    [root@localhost ~]# tree nginx
    nginx
    ├── conf.d
    │   └── default.conf
    ├── fastcgi_params
    ├── mime.types
    ├── modules -> /usr/lib/nginx/modules
    ├── nginx.conf
    ├── scgi_params
    └── uwsgi_params
    # 查看log日志结构
    [root@localhost ~]# tree log
    log
    ├── apt
    │   ├── eipp.log.xz
    │   ├── history.log
    │   └── term.log
    ├── btmp
    ├── dpkg.log
    ├── faillog
    ├── lastlog
    ├── nginx
    │   ├── access.log -> /dev/stdout
    │   └── error.log -> /dev/stderr
    └── wtmp
    

    新建/data目录

    # Nginx负载均衡容器
    docker run -d --name nginx1 -p 80:80 \
    -v /data/nginx1/nginx:/etc/nginx \
    -v /data/nginx1/log:/var/log nginx;
    
    # WEB服务器1
    docker run -d --name nginx2 -p 8080:80 \
    -v /data/nginx2/nginx:/etc/nginx \
    -v /data/nginx2/log:/var/log \
    -v /data/nginx2/html:/usr/share/nginx/html nginx;
    
    # WEB服务器2
    docker run -d --name nginx3 -p 8081:80 \
    -v /data/nginx3/nginx:/etc/nginx \
    -v /data/nginx3/log:/var/log \
    -v /data/nginx3/html:/usr/share/nginx/html nginx;
    
    # Nginx负载均衡容器default.conf配置改成如下
    upstream services {
    	server 192.168.123.199:8080;
        server 192.168.123.199:8081;
    }
    
    server {
    	listen 80;
    	server_name localhost;
    	location / {
    		proxy_pass  http://services;
    	}
    }
    
    # WEB服务器1、WEB服务器2的default.conf配置改成如下
    server {
    	listen 80;
        server_name localhost;
        location / {
        	root    /usr/share/nginx/html;
          	index   index index.html index.php;
        }
    }
    
    # 重启nginx1、nginx2、nginx3容器
    docker restart nginx1 nginx2 nginx3
    

    也可以开始就把default.conf配置改成最终版的配置

    展开全文
  • 基于Nginx的负载均衡实验

    千次阅读 2022-02-23 20:55:15
    基于Nginx的负载均衡实验 Nginx介绍及安装: Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器,同时也提供了IMAP/POP3/SMTP服务。 Mac下安装Nginx: 安装Homebrew 如何检测Homebrew安装? 终端输入...
  • Nginx负载均衡架构

    多人点赞 2021-06-26 14:57:02
    Nginx负载均衡架构 1.准备好三台服务器 2. Nginx、MariaDB、php的安装(server1,server2) 安装nginx 启动nginx 修改配置文件 安装MariaDB 安装php 新建index.php 关闭防火墙和selinux 3.代理服务器的配置(server3...
  • nginx负载均衡session共享

    千次阅读 2021-08-18 16:04:15
    nginx+php 10.0.0.7 172.16.1.7 redis01 redis 172.16.1.41 db01 mysql (mariadb) 172.16.1.51 1.下载可道云开源代码,部署在web01服务器上。 可道云官网下载 下载源码,解压到指定目录,授权。 [root@web01...
  • php nginx 负载均衡简单配置过程

    千次阅读 2019-05-24 10:14:47
    负载均衡 一台计算机的计算资源是有效的,当超大流量请求时,就可能导致请求等待或者服务器死机的情况,为了解决大流量访问的问题,可以搭建分布式,将请求分发到不同计算机,就可以解决大流量请求的问题。 长见的...
  • 20张图 详解 负载均衡

    2020-10-19 00:26:38
    1.PHP执行的时候有如下执行过程:Scanning(Lexing) - Compilation - Execution - Parsing,其含义分别为: A、将PHP代码转换为语言片段(Tokens)、将Tokens转换成简单而有意义的表达式、顺次执行Opcodes、将表达式...
  • 系统设计基础 负载均衡

    千次阅读 2021-01-25 15:06:05
    二、负载均衡分类软件负载均衡硬件负载均衡DNS负载均衡三、负载均衡算法1. 健康检测(health checks)2. 负载均衡如何处理状态3. 负载均衡器如何选择后端服务器?随机轮询加权轮询IP哈希最小连接数一致性 Hash粘性...
  • 当时最早申请的一批容器配置比较低,缩容的时候留下了几台,当流量达到高峰时,这几台容器由于负载太高,就扛不住压力了。 解决方案:在治理平台上调低这几台机器的权重,这样的话,访问的流量自然就减少了。 但...
  • PHP负载均衡

    2019-07-26 11:50:07
    今天,“大型服务器”模式已经过去,取而代之的是大量的小服务器,使用各种各样的负载均衡技术。  “更多小服务器”的优势超过过去的“大型服务器”模式体现在两个方面:  1. 如果服务器宕机,那么负载均衡系统将...
  • haproxy七层负载均衡

    千次阅读 2021-12-31 15:42:08
    用户访问负载均衡器,负载均衡器将用户的请求转发给后端服务器的Web后端组。无论选择哪个后端服务器,都将直接响应用户的请求。通常,Web后端中的所有服务器应该提供相同的内容 - 否则用户可能会收到不一致的内容。 ...
  • 负载均衡 Nginx 不仅可以作为一个 Web 服务器或反向代理服务器,还可以按照权重、轮询、 ip hash、 URL hash 等多种方式实现对后端服务器的负载均衡。本节将对负载均衡实现的原理以及具体配置进行详细讲解。 什么是...
  • 如何设置mysql的负载均衡

    千次阅读 2021-01-20 00:51:06
    MySQL作为中小型办公室都会选择的数据库系统,在安装前工作人员需要知道mysql安装前所必需的环境,今天跟大家分享下mysql的负载均衡问题。本文将介绍MySQL的负载均衡问题,包括环境介绍,操作系统和软件安装和配置...
  • 负载均衡,你自己会不会配置?

    千次阅读 2022-01-20 14:33:06
    什么是负载均衡 所谓负载均衡,就是说如果一组计算机节点(或者一组进程)提供相同的(同质的)服务,那么对服务的请求就应该均匀的分摊到这些节点上。这里的服务是广义的,可以是简单的计算,也可能是数据的读取...
  • PHP负载均衡

    千次阅读 2012-01-17 19:30:27
    今天,“大型服务器”模式已经过去,取而代之的是大量的小服务器,使用各种各样的负载均衡技术。 “更多小服务器”的优势超过过去的“大型服务器”模式体现在两个方面: 1. 如果服务器宕机,那么负载均衡系统将...
  • 用nginx实现负载均衡

    千次阅读 2021-06-25 16:05:09
    负载均衡 反向代理 操作步骤 首先检查自己电脑上是否克隆好了3个centos虚拟机,若未克隆,先克隆 最后的: 在虚拟机server2、server3中进行如下操作 首先打开终端进入root su root 安装nginx 配置两个源站 ...
  • lamp架构-nginx的负载均衡与高可用1

    千次阅读 2022-02-21 16:15:00
    前2列是前面做的负载均衡后面是lnmp架构(电商的平台) lamp=linux/unix/windows(操作系统) +apache/nginx/…(web服务器)+mysql/pgsql/…(数据库)+php/jsp/python…(动态语言) 通过路由器的等价路由,配合OSPF等价...
  • 如果某段时间内服务器进入了很多固定IP代理的请求 [翻墙,代理] ,如果代理IP的负载过高就会导致ip_hash对应的服务器负载压力过大,这样ip_hash就失去了负载均衡的作用了。 4.对session文件进行同步 使用同步...
  • 负载均衡的几种实现技术

    千次阅读 2016-05-10 09:39:55
    当web服务器的垂直扩展变得话费很高或困难的时候,我们需要考虑服务器的水平扩展,即负载均衡技术。负载均衡有很多技术,这里我们来一一介绍。 1.HTTP重定向 我们可以在代码层面实现,通过设定访问特定页面如...
  • 架构文摘:LSV负载均衡技术笔记

    千次阅读 2018-06-01 15:56:34
    一、LVS介绍 在本部分,我们将介绍Linux服务器集群...当今计算机技术已进入以网络为中心的计算时期。由于客户/服务器模型的简单性、易管理性和易维护性,客户/服务器计算模式在网上被大量采用。同时,Internet的飞...
  • PHP服务器有多台,用nginx做负载均衡,这样同一个IP访问同一个页面会被分配到不同的服务器上,如果session不同步的话,就会出现很多问题,比如说最常见的登录状态,下面提供了几种方式来解决session共享的问题: ...
  • 目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。 什么是Nginx? Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器,同时也提供...
  • 论数据中心网络的负载均衡技术

    千次阅读 2017-07-03 14:10:00
    相信很多人对负载均衡技术并不陌生。即使是没有接触数据中心网络技术的人,从字面上理解也能猜个大概。负载均衡是一种用来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性的技术,...
  • web技术负载均衡与缓存技术

    千次阅读 2015-09-30 16:56:35
    本文档用于指导对日上亿基本web访问,web框架技术如何来设计的
  • 接收客户端请求,根据负载均衡策略转发给后端多个上游服务器处理;然后再等待后端服务器返回请求响应,接收到后再返回给请求的客户端。 2、nginx基本架构 1、一个master进程生成多个worker子进程(每个进程只有一个...
  • 在操作之前需要确认的是,是否已经关闭了“VerifyCsrfToken”的提交验证,可根据自行需要修改下文件App\Http\Middleware\VerifyCsrfToken.php,建议根据路径需求允许部分不需要验证的,不要关闭全部。 第一步确认下...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 34,380
精华内容 13,752
热门标签
关键字:

php负载均衡技术