WEB集群与各种负载均衡简介 （资源）

2019独角兽企业重金招聘Python工程师标准>>>

                               负载均衡构架图

  

  集群(Cluster)：是一组独立的计算机系统构成一个松耦合的多处理器系统，它们之间通过网络实现进程间的通信。应用程序可以通过网络共享内存进行消息传送，实现分布式计算机。

集群分类及不同分类的特点

计算机集群架构按照功能和结构一般分成以下几类：

1）负载均衡集群（Loadbalancing clusters）简称LBC

2）高可用性集群（High-availability clusters）简称HAC

3）高性能计算集群（High-perfomance clusters）简称HPC

集群

          系统扩展的方法 ：

             scale up  : 向上扩展

             scale out : 向外扩展

常用集群软硬件

常用开源集群软件有：lvs，keepalived，haproxy，nginx，apache，heartbeat

常用商业集群硬件有：F5,Netscaler，Radware，A10等

 Web集群是由多个同时运行同一个web应用的服务器组成，在外界看来就像一个服务器一样，这多台服务器共同来为客户提供更高性能的服务。集群更标准的定义是：一组相互独立的服务器在网络中表现为单一的系统，并以单一系统的模式加以管理，此单一系统为客户工作站提供高可靠性的服务。

Web负载均衡(LoadBalance)  ： 是集群技术(Cluster)的一种应用。负载均衡可以将工作任务分摊到多个处理单元,从而提高并发处理能力。目前最常见的负载均衡应用是Web负载均衡。根据实现的原理不同,常见的web负载均衡技术包括:DNS轮询、IP负载均衡和CDN。其中IP负载均衡可以使用硬件设备或软件方式来实现。

负载均衡集群的作用

1）分担访问流量（负载均衡）

2）保持业务的连续性（高可用）

基本原理    :   一个请求的入口映射到多个处理请求的节点,从而实现分而治之(Divide and Conquer)。

    ELB 弹性负载均衡（Elastic Load Balancing ）通过将访问流量自动分发到多台弹性云主机，扩展应用系统对外的服务能力，实现更高水平的应用程序容错性能

ELB 弹性负载均衡工作原理图

负载均衡器的作用

提高扩展性              在服务器群（即虚拟服务器）处理能力不足，负载均衡器能够随时添加1台物理服务器。由于客户端访问的是虚拟IP地址，因此虚拟服务器性能的提高是显而易见

提高可靠性            即使服务器群中某台服务器发生故障，虚拟服务器也会继续提供服务，以确保其他服务器能够继续不间断地处理业务。同理，当服务器群某台服务器需要停机保养时，也可以通过不间断虚拟服务器来完成。

负载均衡器的算法

轮询、最少连接、加权轮询、加权最少连接、IP地址散列、URL散列

 

常见的web负载均衡

DNS轮询   :  

DNS轮询是最简单的负载均衡方式。以域名作为访问入口,通过配置多条DNS A记录使得请求可以分配到不同的服务器。

DNS轮询没有快速的健康检查机制,而且只支持WRR的调度策略导致负载很难“均衡”,通常用于要求不高的场景。并且DNS轮询方式直接将服务器的真实地址暴露给用户,不利于服务器安全。

 

CDN

CDN(Content Delivery Network,内容分发网络)。通过发布机制将内容同步到大量的缓存节点,并在DNS服务器上进行扩展,找到里用户最近的缓存节点作为服务提供节点。

因为很难自建大量的缓存节点,所以通常使用CDN运营商的服务。目前国内的服务商很少,而且按流量计费,价格也比较昂贵

 

六种常用的web负载均衡技术 ：

1、http重定向

性能缺点 ： 吞吐率限制；重定向访问深度不同

2、DNS负载均衡

3、反向代理负载均衡

4、IP负载均衡(LVS-NAT)

5、直接路由(LVS-DR)

6、IP隧道(LVS-TUN)

更多介绍 ： https://blog.csdn.net/wt725/article/details/58580315

 

IP负载均衡

IP负载均衡是基于特定的TCP/IP技术实现的负载均衡。比如NAT、DR、Turning等。是最经常使用的方式。

 

注意   ：  IP负载均衡可以使用硬件设备,也可以使用软件实现。硬件设备的主要产品是F5-BIG-IP-GTM(简称F5),软件产品主要有LVS、HAProxy、NginX。其中LVS、HAProxy可以工作在4-7层,NginX工作在7层。

 

常用的web服务器软件 :

1、Apache是世界使用排名第一的Web服务器软件。

2、IIS是微软公司主推的服务器。

3、GFEGoogle的web服务器。

4、Nginx的HTTP服务器。

5、Lighttpd服务器。

6、Zeus是一个运行于Unix下的非常优秀的Web Server，据说性能超过Apache，是效率最高的Web Server之一。

7、（8）Resin提供了最快的jsp/servlets运行平台。

8、Jetty是一个开源的servlet容器，它为基于Java的web内容，例如JSP和servlet提供运行环境。

9、BEA WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。

10、Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，由Apache、Sun 和其他一些公司及个人共同开发而成。

Web服务器的主要功能是存储，处理和传递网页给客户。客户端和服务器之间的通信使用超文本传输协议（HTTP）进行。交付的页面最常见的是HTML文档，除了文本内容之外，还可能包含图像，样式表和脚本。

主流Web服务器 ：Apache、IIS 、Nginx、Tomcat，Jetty，WebSphere，WebLogic，Kerstrel等等。

 

什么是web负载均衡

服务器集群(Cluster)使得多个服务器节点能够协同工作,根据目的的不同,服务器集群可以分为:

高性能集群:将单个重负载的请求分散到多个节点进行处理,最后再将处理结果进行汇总高可用集群:提高冗余单元,避免单点故障负载均衡集群:将大量的并发请求分担到多个处理节点。由于单个处理节点的故障不影响整个服务,负载均衡集群同时也实现了高可用性。

 

常见的负载均衡器 ：

1.keepalived

 使用vrrp实现高可用，可以理解成是IP层的高可用，虚拟出一个vip来实现高可用的功能。

实际应用时主要是两两组合，提供两个vip，在一台挂掉后可以自动转移至另一台服务。

比较常见的问题是脑裂问题和ip转移后的arp问题，第一种问题可以通过tcpdump快速定位rc(要抓vrrp协议),第二种情况可以使用arping的脚本解决(keepalived 的notify_master设置)。

 基本上没有性能上的问题。

 

2.lvs

 线上用的比较多的一种负载均衡器，内核态转发型的高可用工具，可以看做是tcp层的负载均衡器,主要原理就是对tcp的报文做些更改，然后进行转发,支持的状态检测方法也比较完善，有端口检测，url检测和自定义脚本检测。

 实际应用中一般是用lvs的dr模式，配合keepalived使用，keepalived提供主机的高可用，lvs提供应用的高可用，lvs采用url的检测方式（避免端口ok但是应用挂起的情况，比如java应用的gc）。

 比较常见的问题是realserver被踢出的问题，可以通过在lvs部署监控并根据检测方法部署相关的检测脚本(网络检测，端口检测，url检测)来找到问题的rc。

 很少能遇到性能的问题，在包量很大的情况下（几十万/s），可能会遇到网卡ring buffer和网卡中断的问题，可以通过丢包率和mpstat来定位，ring buffer问题可以尝试增加网卡的ring buffer设置解决，中断问题可以采用centos5.8以上的内核配合多队列(必须)来解决。

 

3.nginx

 现在主流的反向代理软件，可以通过代理的功能实现负载均衡的功能，本身功能比较完善，既可以做静态站点，缓存又可以做负载均衡器，配置上可以优化的地方很多，有端口检测和url的检测，但是检测的方式是被动式的，会对用户的访问造成一定的影响。

 以java类应用来说，常见的使用方式是lvs+nginx+tomcat/resin，比较完善的日志，可以通过分析nginx日志的状态码，响应时间(response time)和后端响应时间(upstream time)来跟踪qos，定位问题。

 性能上问题不大，比较常见的问题是buffer导致的io问题和日志本地切割导致的nginx慢速响应的问题

第一个问题可以尝试内存换io或者干脆关掉buffer试试，第二个问题可以把日志通过网络写入远端处理（不过貌似目前nginx不支持）。

 

4.tengine

 nginx的变种，在url check上做了改进，支持主动的检查，减少了对用户的影响，同时可以支持多种方式的日志处理(通过网络写入远端处理等)，还支持各种自定义的插件，灵活性比较高。在webcdn的结构设计中我就是用了lvs+tengine+squid/trafficserver的结构。

 

 

5.squid/trafficserver/varnish

反向代理软件，个人觉得还是做缓存会比较有优势。没有用来做过负载均衡器，这里就不妄加评论了。。

 

6.haproxy

个人感觉和nginx差不多，比nginx要轻量级。

一般都是lvs + haproxy来做高可用，比如淘宝的cdn结构就是lvs+haproxy+trafficserver

这个个人用的也比较少。。

 

7.f5设备类

F5的主要特性包括:

多链路的负载均衡和冗余

可以接入多条ISP链路,在链路之间实现负载均衡和高可用。

防火墙负载均衡

F5具有异构防火墙的负载均衡与故障自动排除能力。

服务器负载均衡

高大上的设备，没接触过，不过有界面一切都好说。

F5提供HTTPS、SSH、Telnet、SNMP等多种管理方式,

 

负载均衡部署方式

负载均衡有三种部署方式：路由模式、桥接模式、服务直接返回模式。

 

路由模式部署灵活，约60%的用户采用这种方式部署；桥接模式不改变现有的网络架构；服务直接返回（DSR）比较适合吞吐量大特别是内容分发的网络应用。约30%的用户采用这种模式。

路由模式（推荐）

路由模式的部署方式如上图。服务器的网关必须设置成负载均衡机的LAN口地址，且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小，能均衡任何下行流量。

 

桥接模式

桥接模式配置简单，不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP（WAN口与LAN口是桥连接），所有的服务器与负载均衡均在同一逻辑网络中。

服务直接返回模式

如上图，这种安装方式负载均衡的LAN口不使用，WAN口与服务器在同一个网络中，互联网的客户端访问负载均衡的虚IP（VIP），虚IP对应负载均衡机的WAN口，负

服务直接返回模式

载均衡根据策略将流量分发到服务器上，服务器直接响应客户端的请求。因此对于客户端而言，响应他的IP不是负载均衡机的虚IP（VIP），而是服务器自身的IP地址。也就是说返回的流量是不经过负载均衡的。因此这种方式适用大流量高带宽要求的服务

主要应用 :

          1、 DNS负载均衡

          2、代理服务器

          3、地址转换网关

          4、协议内部支持负载均衡

          5、NAT负载均衡

          6、反向代理负载均衡

          7、混合型负载均衡

 

负载均衡的几种实现方式

1)HTTP重定向负载均衡。
        这种负载均衡方案的优点是比较简单,缺点是浏览器需要每次请求两次服务器才能拿完成一次访问,性能较差。

(2)DNS域名解析负载均衡。

       DNS域名解析负载均衡的优点是将负载均衡工作交给DNS,省略掉了网络管理的麻烦,缺点就是DNS可能缓存A记录,不受网站控制。

(3)反向代理负载均衡。
        优点是部署简单,缺点是反向代理服务器是所有请求和响应的中转站,其性能可能会成为瓶颈。

(4)IP负载均衡。
        优点:IP负载均衡在内核进程完成数据分发,较反向代理均衡有更好的处理性能。缺点:负载均衡的网卡带宽成为系统的瓶颈。

(5)数据链路层负载均衡。
        避免负载均衡服务器网卡带宽成为瓶颈,是目前大型网站所使用的最广的一种负载均衡手段。

 

      服务器集群：

        服务器集群就是指将很多服务器集中起来一起进行同一种服务,在客户端看来就像是只有一个服务器.集群可以利用多个计算机进行并行计算从而获得很高的计算速度,也可以用多个计算机做备份,从而使得任何一个机器坏了整个系统还是能正常运行.

       负载均衡（Load balance cluster,LBC）： 它是利用一个集群中的多台单机，完成许多并行的小的工作。一般情况下，如果一个应用使用的人多了，那么用户请求的相应时间就会增大，机器的性能也会受到影响，如果使用负载均衡集群，那么集群中任意一台机器都能相应用户的请求，这样集群就会在用户发出服务请求之后，选择当时负载最小，能够提供最好的服务的这台机器来接受请求并相应，这样就可用用集群来增加系统的可用性和稳定性。

            就是负责多个服务器之间（集群内）实现合理的任务分配，使这些服务器（集群）不会出现因某一台超负荷、而其他的服务器却没有充分发挥处理能力的情况。负载均衡有两个方面的含义：首先，把大量的并发访问或数据流量分担到多台节点上分别处理，减少用户等待响应的时间；其次，单个高负载的运算分担到多台节点上做并行处理，每个节点设备处理结束后，将结果汇总，再返回给用户，使得信息系统处理能力可以得到大幅度提高

            第四层交换负载均衡的原理，就是按照IP地址和TCP端口进行虚拟连接的交换，直接将数据包发送到目的计算机的相应端口中。具备第四层交换能力的交换机，能作为一个硬件负载均衡器，完成服务器的负载均衡。由于第四层交换基于硬件芯片，因此性能非常优秀，尤其是对于网络传输的速度，交换的速度远远超过普通的数据包转发。采用第四层交换机设备，所有的集群主机通过第四层交换机与外部Internet相连，外部客户防问服务器时通过第四层交换机动态分配服务器，实现动态负载均衡，当其中一台服务器出现故障时，由交换机动态将所有流量分配到集群中的其他主机上,这类只适合在大型流量大的服务器。

         第四层交换是在ASIC专用高速芯片中实现的，从而使过滤控制可以线速进行。

端口负载平衡

通道端口间的负载平衡有两种方式，基于源MAC的转发和基于目的MAC的转发。

scr-mac：源MAC地址相同的数据帧使用同一个端口转发。

dst-mac：目的MAC地址相同的数据帧使用同一个端口转发。
 

负载均衡架构

数据库的数据一致性：

1：开启所有数据的二进制日志文件
2：配置监听(从数据库--主)或者触发器(主---日志文件)
3：监听主数据库的二进制文件，如果二进制文件有变化，则将主服务器的二进制文件拷贝到本地日志文件中
4：主服务器配置触发器，如果二进制文件被修改或者触发，则自动将二进制文件复制到从服务器

       分布式系统（distributed system）:是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。

在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件（middleware）负责实现这个模型。一个著名的分布式系统的例子是万维网（World Wide Web），在万维网中，所有的一切看起来就好像是一个文档（Web页面）一样。

分布式与集群的区别:

分布式:一个复杂业务分拆多个子业务,部署在不同的服务器上.
集群:同一个业务,部署在多个服务器上.
集群是个物理形态,分布式是个工作方式
集群一般是物理集中、统一管理的,而分布式系统则不强调这一点.

负载策略算法

1、轮询(Round Robin)
2、加权轮询(Weighted Round Robin)
3、动态轮询
4、随机
5、最快算法(最快算法基于所有服务器中的最快响应时间分配连接)
6、最少连接(系统把新连接分配给当前连接数目最少的服务器)

负载均衡有硬件和软件两种

硬件层的比较牛逼,将4-7层负载均衡功能做到一个硬件里面,如F5,梭子鱼.

目前主流的软件负载均衡分为四层和七层

LVS属于四层负载均衡,工作在tcp/ip协议栈上,通过修改网络包的ip地址和端口来转发, 由于效率比七层高,一般放在架构的前端.

七层的负载均衡有nginx, haproxy, apache等, 工作在应用层,因此可以将HTTP请求等应用数据发送到具体的应用服务器,
如将图片请求转发到特定的服务器上,总之可以做到更智能的负载均衡，这些功能在四层负载均衡上不好实现,一般放在架构的后面位置,布置在应用服务器前面.

 

服务器集群的方向：

1、向内扩展  

两个Tomcat的实例运行在一台物理器上，充分利用原有内存，CPU未得到扩展。

缺点:在一定的范围之内它的性能是上升的趋势,但是超出范围之后就是下降的趋势。因为随着它的cpu的个数增加我们需要给我们的cpu仲裁，而且随着cpu个数的增加资源竞争性越大。

2、向外扩展  

一台服务器应付不过来,我们就再增加一台服务器。两台Tomcat，分别运行在2台物理机上，好处是最大的即CPU扩展，内存也扩展了，处理能力也扩展了。   

优点:增减服务器很方便，而且没有向上扩展随着增加性能下降。   

    
    集群技术可以分为三大类：

    1、高性能性集群(HPC Cluster)
    2、高可用性集群(HA Cluster)
    3、高可扩展性集群

 1、高性能性集群(HPC Cluster)

     指以提高科学计算能力为目标的集群技术。该集群技术主要用于科学计算，这里不打算介绍，如果感兴趣可以参考相关的资料。

 2、高可用性集群(HA Cluster)

     指为了使群集的整体服务尽可能可用，减少服务宕机时间为目的的集群技术。如果高可用性集群中的某节点发生了故障，那么这段时间内将由其他节点代替它的工作。当然对于其他节点来讲，负载相应的就增加了。
    为了提高整个系统的可用性，除了提高计算机各个部件的可靠性以外，一般情况下都会采用该集群的方案。
    对于该集群方案，一般会有两种工作方式：
     ①主-主(Active-Active)工作方式
       这是最常用的集群模型，它提供了高可用性，并且在只有一个节点时也能提供可以接受的性能，该模型允许最大程度的利用硬件资源。每个节点都通过网络对客户机提供资源，每个节点的容量被定义好，使得性能达到最优，并且每个节点都可以在故障转移时临时接管另一个节点的工作。所有的服务在故障转移后仍保持可用，但是性能通常都会下降。

这是目前运用最为广泛的双节点双应用的Active/Active模式。

        支撑用户业务的应用程序在正常状态下分别在两台节点上运行，各自有自己的资源，比如IP地址、磁盘阵列上的卷或者文件系统。当某一方的系统或者资源出现故障时，就会将应用和相关资源切换到对方的节点上。

这种模式的最大优点是不会有服务器的“闲置”，两台服务器在正常情况下都在工作。但如果有故障发生导致切换，应用将放在同一台服务器上运行，由于服务器的处理能力有可能不能同时满足数据库和应用程序的峰值要求，这将会出现处理能力不够的情况，降低业务响应水平。

     
     ②主-从(Active-Standby)工作方式
      为了提供最大的可用性，以及对性能最小的影响，主-从工作方式需要一个在正常工作时处于备用状态的节点，主节点处理客户机的请求，而备用节点处于空闲状态，当主节点出现故障时，备用节点会接管主节点的工作，继续为客户机提供服务，并且不会有任何性能上影响。

 3、高可扩展性集群

     这里指带有负载均衡策略（算法）的服务器群集技术。带负载均衡集群为企业需求提供了更实用的方案，它使负载可以在计算机集群中尽可能平均地分摊处理。而需要均衡的可能是应用程序处理负载或是网络流量负载。该方案非常适合于运行同一组应用程序的节点。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载， 以实现平衡。对于网络流量也是如此。通常，单个节点对于太大的网络流量无法迅速处理，这就需要将流量发送给在其它节点。还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。

  负载均衡集群在多节点之间按照一定的策略（算法）分发网络或计算处理负载。负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法来扩展服务器带宽，增加吞吐量，提高数据处理能力，同时又可以避免单点故障。

 

企业实现服务器负载均衡常见的四种方法

一、企业实现Web服务器负载均衡

二、使用网络地址转换实现多服务器负载均衡

三、使用DNS服务器实现负载均衡

四、企业实现SQL Server数据库服务器负载均衡

具体信息：https://www.cnblogs.com/xiangzhong/p/5014493.html

 

服务器的类型

1、LB:LoadBalancing:负载均衡集群

负载均衡集群中有一个分发器或者叫调度器，我们将其称之为Director，它处在多台服务器的上面，分发器根据内部锁定义的规则或调度方式从下面的服务器群中选择一个以此来响应客户端发送的请求。

2、HA:HighAvailability 高可用集群  

高可用集群是服务的可用性比较高，当我们某台服务器死机后不会造成我们的服务不可用。其工作模式则是将一个具有故障的服务转交给一个正常工作的服务器，从而达到服务不会中断。一般来说我们集群中工作在前端（分发器）的服务器都会对我们的后端服务器做一个健康检查，如果发现我们服务器当机就不会对其在做转发。

衡量标准：可用性=在线时间/(在线时间+故障处理时间) 99%、99.9%、99.99%、99.999%

3、HP:HightPerformance 高性能  

高性能的集群是当某一个任务量非常大的时候，我们做一个集群共同来完成这一个任务。这种处理方式我们称为并行处理集群，并行处理集群是将大任务划分为小任务，分别进行处理的机制。一般这样的集群用来科学研究与大数据运算等方面的工作。现在比较火的Hadoop就是使用的并行处理集群。

负载均衡方案：

1:HTTP 重定向负载均衡

 

 

负载均衡简介

       负载均衡功能是在应用服务器、应用、链路高负载的情况下，由多台节点提供相同应用、多条链路提供可伸缩的、高负载、动态调度的集群节点组以保证对外提供良好的服务响应。DHLOAD可分为:链路负载均衡、应用服务均衡、服务器的负载均衡。

 

负载均衡有硬件和软件两种

硬件层的比较牛逼,将4-7层负载均衡功能做到一个硬件里面,如F5,梭子鱼.

目前主流的软件负载均衡分为四层和七层

LVS属于四层负载均衡,工作在tcp/ip协议栈上,通过修改网络包的ip地址和端口来转发, 由于效率比七层高,一般放在架构的前端.

七层的负载均衡有nginx, haproxy, apache等, 工作在应用层,因此可以将HTTP请求等应用数据发送到具体的应用服务器,
如将图片请求转发到特定的服务器上,总之可以做到更智能的负载均衡，这些功能在四层负载均衡上不好实现,一般放在架构的后面位置,布置在应用服务器前面.

负载均衡服务器

      负载均衡服务器（load-balancing server）是进行负载分配的服务器。通过负载均衡服务器，将服务请求均衡分配到实际执行的服务中，从而保证整个系统的响应速度。

负载均衡器一般根据两个因素来决定要将请求转发到哪个服务器。

1：确保所选择的后端服务器是正常工作的，能给对用户的请求做出响应；

2：根据预先设置的负载均衡算法从健康服务器池中进行选择。

 

 

1.链路负载均衡

        外网链路均衡

 

        内网链路均衡

2、应用负载均衡

        WEB应用均衡

 

        中间件均衡

 

        ftp应用均衡

 

        等50多种应用均衡。

3、      特   点：  

 

        适用于各类网络体系和两层以上结构的应用软件，完全的软件实现方式；

 

        链路智能均衡调度

 

        节点智能均衡调度

 

        链路负载均衡支持基于流量和服务器本身I/O和负载能力的均衡

 

        均衡策略灵活可定制

 

4、  网络环境：

 

        操作系统 Windows NT,Windows 2000,Linux,Soraris,Unix 等。

 

        数据库系统 Oracle,Sybase,SQL Server 等。

 

        网络协议 TCP/IP,SPX/IPX。

 

负载均衡分类

​
1. 硬件负载均衡
常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用。
​
2. 软件负载均衡
目前使用最广泛的三种负载均衡软件Nginx/LVS/HAProxy，他们都是基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。
​
3. 成熟的架构
成熟的架构有LVS+Keepalived、Nginx+Keepalived、HAProxy+keepalived。

LVS+keepalived能很好的实现以上的要求，LVS提供负载均衡，keepalived提供健康检查，故障转移，提高系统的可用性！采用这样的架构以后很容易对现有系统进行扩展，只要在后端添加或者减少realserver，只要更改lvs的配置文件，并能实现无缝配置变更！

负载均衡的基本（常用）算法

1 、轮转法

2、散列法

3、最少连接法

4 、最低缺失法

5、最快响应法

6、加权法

实现负载均衡的算法

1、轮询调度

 2、最小连接调度(Least-Connection Scheduling)

3、 基于局部性的最少链接(LBLC)

4、带复制的基于局部性最少链接(LBLCR)

5、目标地址散列调度(Destination Hashing Scheduling)
6、 源地址散列调度(Source Hashing Scheduling)

参考链接：http://blog.csdn.net/u014649204/article/details/25115039

常见的负载均衡软件

常见的有LVS、Nginx和HAProxy

        LVS：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)，感谢章文嵩博士为我们提供如此强大实用的开源软件。
　　LVS的特点是：
　　1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的；

　　2、工作在网络4层，通过VRRP协议(仅作代理之用)，具体的流量是由linux内核来处理，因此没有流量的产生。
　　3、工作稳定，自身有完整的双机热备方案；
　　4、无流量，保证了均衡器IO的性能不会收到大流量的影响；

　　5、应用范围比较广，可以对所有应用做负载均衡；配置相对复杂，对网络依赖比较大，稳定性很高。

       6、LVS：使用Linux内核集群实现一个高性能、高可用的负载均衡服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。

      7、支持多种负载均衡算法：rr(轮询)，wrr(带权轮询)、lc(最小连接)、wlc(带权最小连接)

 ①轮循算法，就是将来自网络的请求依次分配给集群中的节点进行处理。
  ②最小连接数算法，就是为集群中的每台服务器设置一个记数器，记录每个服务器当前的连接数，负载均衡系统总是选择当前连接数最少的服务器分配任务。 这要比"轮循算法"好很多，因为在有些场合中，简单的轮循不能判断哪个节点的负载更低，也许新的工作又被分配给了一个已经很忙的服务器了。
  ③快速响应优先算法，是根据群集中的节点的状态（CPU、内存等主要处理部分）来分配任务。 这一点很难做到，事实上到目前为止，采用这个算法的负载均衡系统还很少。尤其对于硬件负载均衡设备来说，只能在TCP/IP协议方面做工作，几乎不可能深入到服务器的处理系统中进行监测。但是它是未来发展的方向。
 

      8、 LVS工作模式有4种：

                    (1) nat 地址转换

                    (2) dr 直接路由

                    (3) tun 隧道

                    (4) full-nat
​

LVS的缺点是：

　　1、软件本身不支持正则处理，不能做动静分离。

       2、如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。
​

　　Nginx的特点是：
　　1、工作在网络的7层之上，可以针对http应用做一些分流的策略；比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。
​
　　2、Nginx对网络的依赖非常小，理论上能ping通就能进行负载功能；
　　3、Nginx安装和配置比较简单，测试起来比较方便；它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。
　　4、可以承担高的负载压力且稳定，一般能支撑超过几万次的并发量；
　　5、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等；会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了。
　　6、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件。

       7、Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比Nginx的就只有lighttpd了，不过lighttpd目前还没有做到Nginx完全的功能，配置也不那么清晰易读，社区资料也远远没Nginx活跃。

      8、Nginx也可作为静态网页和图片服务器，这方面的性能也无对手。还有Nginx社区非常活跃，第三方模块也很多。

       9、Nginx对请求的异步处理可以帮助节点服务器减轻负载压力

       10、Nginx还能做Web服务器即Cache功能。

 Nginx的缺点是：

                       1、Nginx仅能支持http和Email；

                       2、对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。不支持Session的直接保持，但能通过ip_hash来解决。

                       3、不支持Session的直接保持，但能通过ip_hash来解决。对Big request header的支持不是很好。

              

 Nginx常用四种算法：
​
         6.1.roundrobin：轮询，轮流分配到后端服务器；
        6.2.static-rr：根据后端服务器性能分配；
        6.3.leastconn：最小连接者优先处理；
       6.4.source：根据请求源IP，与Nginx的IP_Hash类似。

　

　　HAProxy的特点是：

　　1、支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；
　　2、HAProxy的优点能够补充Nginx的一些缺点，比如Session的保持，Cookie的引导等工作；同时支持通过获取指定的url来检测后端服务器的状态。
　　3、支持url检测后端的服务器出问题的检测会有很好的帮助；
　　4、支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）
　　5、HAProxy可以对Mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，不过在后端的MySQL slaves数量超过10台时性能不如LVS；
　　6、HAProxy的算法多；

       7、HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。

       8、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。

       9、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种：
​
               ① roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；
               ② static-rr，表示根据权重，建议关注；
               ③ leastconn，表示最少连接者先处理，建议关注；
              ④ source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；
             ⑤ ri，表示根据请求的URI；
            ⑥ rl_param，表示根据请求的URl参数’balance url_param’ requires an URL parameter name；
           ⑦ hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；
          ⑧ rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。

             HAProxy缺点：

                           1、不能做Web服务器即Cache。

 

Nginx和LVS对比的总结：

​
1、Nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下LVS并不具备这样的功能，所以Nginx单凭这点可利用的场合就远多于LVS了；但Nginx有用的这些功能使其可调整度要高于LVS，所以经常要去触碰触碰，触碰多了，人为出问题的几率也就会大。
​
2、Nginx对网络稳定性的依赖较小，理论上只要ping得通，网页访问正常，Nginx就能连得通，这是Nginx的一大优势！Nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；LVS就比较依赖于网络环境，目前来看服务器在同一网段内并且LVS使用direct方式分流，效果较能得到保证。另外注意，LVS需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。
​
3、Nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了；LVS对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。
​
4、Nginx也同样能承受很高负载且稳定，但负载度和稳定度差LVS还有几个等级：Nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的。
​
5、Nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控，但LVS的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而恼火。
​
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大量内存而不能释放，使用多一个Nginx做apache代理的话，这些窄带链接会被Nginx挡住，apache上就不会堆积过多的请求，这样就减少了相当多的资源占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。
​
7、Nginx能支持http、https和email（email的功能比较少用），LVS所支持的应用在这点上会比Nginx更多。在使用上，一般最前端所采取的策略应是LVS，也就是DNS的指向应为LVS均衡器，LVS的优点令它非常适合做这个任务。重要的ip地址，最好交由LVS托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所逊色于Nginx。Nginx也可作为中层代理使用，这一层面Nginx基本上无对手，唯一可以撼动Nginx的就只有lighttpd了，不过lighttpd目前还没有能做到 Nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得具体分析，如果是比较小的网站（日PV小于1000万），用Nginx就完全可以了，如果机器也不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用LVS。
​

负载均衡器适用业务场景

   1. 网站建设初期，可以选用Nginx、HAProxy作为反向代理负载均衡(流量不大时，可以不选用负载均衡)，因为其配置简单，性能也能满足一般业务场景。如果考虑到负载均衡器是有单点问题，可以采用Nginx+Keepalived/HAproxy+Keepalived避免负载均衡器自身的单点问题。
    2. 网站并发到达一定程度后，为了提高稳定性和转发效率，可以使用lvs，毕竟lvs比Nginx/HAProxy要更稳定，转发效率也更高。
    注：nginx与HAProxy比较：nginx只支持七层，用户量最大，稳定性比较可靠。Haproxy支持四层和七层，支持更多的负载均衡算法，支持session等。

 

负载均衡方案：

1、【协议层】http重定向协议实现负载均衡

原理：根据用户的http请求计算出一个真实的web服务器地址，并将该web服务器地址写入http重定向响应中返回给浏览器，由浏览器重新进行访问。

优点：HTTP重定向方案比较简单

缺点：

1、浏览器需要零次请求服务器才能完成一次访问，性能较差。

http重定向服务器自身的处理能力可能成为瓶颈。

使用http302响应重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。

2、性能比较差，需要2次请求才能返回实际结果,还有就是仅适合HTTP服务器使用。

 

 

2、【协议层】dns域名解析负载均衡

原理：在DNS服务器上配置多个域名对应IP的记录。例如一个域名www.baidu.com对应一组web服务器IP地址，域名解析时经过DNS服务器的算法将一个域名请求分配到合适的真实服务器上。

使用dig命令来看下"baidu"的DNS设置

如图：

优点：1、将负载均衡的工作交给了DNS，省却了网站管理维护负载均衡服务器的麻烦，同事许多DNS还支持基于地理位置的域名解析，将域名解析成距离用户地理最近的一个服务器地址，加快访问速度吗，改善性能。

2、是由DNS来完成负载均衡工作，服务本身不用维护负载均衡服务器的工作。

2、可以根据用户IP来进行智能解析。DNS服务器可以在所有可用的A记录中寻找离用记最近的一台服务器。

3、动态DNS：在每次IP地址变更时，及时更新DNS服务器。当然，因为缓存，一定的延迟不可避免。

缺点：

1、由于负载均衡服务器不是自己维护，没法做精细控制，而且DNS在客户端往往带有缓存，服务器的变更很难及时反映到客户端上。

2、目前的DNS解析是多级解析，每一级DNS都可能化缓存记录A，当摸一服务器下线后，该服务器对应的DNS记录A可能仍然存在，导致分配到该服务器的用户访问失败。

       DNS负载均衡的控制权在域名服务商手里，网站可能无法做出过多的改善和管理。

      不能够按服务器的处理能力来分配负载。DNS负载均衡采用的是简单的轮询算法，不能区分服务器之间的差异，不能反映服务器当前运行状态，所以其的负载均衡效果并不是太好。

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

    没有用户能直接看到DNS解析到了哪一台实际服务器，给服务器运维人员的调试带来了不便。

 

3、【协议层】反向代理负载均衡

原理：反向代理处于web服务器这边，反向代理服务器提供负载均衡的功能，同时管理一组web服务器，它根据负载均衡算法将请求的浏览器访问转发到不同的web服务器处理，处理结果经过反向服务器返回给浏览器。

        反向代理服务器位于实际的服务器之前，他能够缓存服务器响应，加速访问，同时也启到了负载均衡服务器的效果。反向代理服务器解析客户端请求，根据负载均衡算法转发到不同的后台服务器上。用户和后台服务器之间不再有直接的链接。请求，响应都由反向代理服务器进行转发。

反向代理服务器工作在HTTP层

如图：

例如：浏览器访问请求的地址是反向代理服务器的地址114.100.80.10，反向代理服务器收到请求，经过负载均衡算法后得到一个真实物理地址10.0.03，并将请求结果发给真实无服务，真实服务器处理完后通过反向代理服务器返回给请求用户。

 

优点：1、负载均衡服务集成在一起，部署简单，处于http协议层面。

2、任何对于实际服务器的HTTP请求都必须经过调度器

3、调度器必须等待实际服务器的HTTP响应，并将它反馈给用户（前两种方式不需要经过调度反馈，是实际服务器直接发送给用户）

4、调度策略丰富。例如可以为不同的实际服务器设置不同的权重，以达到能者多劳的效果。

5、反向代理服务器可以监控后端服务器，比如系统负载、响应时间、是否可用、TCP连接数、流量等，从而根据这些数据调整负载均衡的策略。

缺点：1、使用了反向代理服务器后，web 服务器地址不能直接暴露在外，因此web服务器不需要使用外部IP地址，而反向代理服务作为沟通桥梁就需要配置双网卡、外部内部两套IP地址。

2、对反向代理服务器的并发处理能力要求高，因为它工作在HTTP层面。

3、所有的请求回应都需要经过反向代理服务器。其本身可能会成为性能的瓶颈。

上面的三种都是工作在OSI网络模型中的应用层，我们可以统称为应用层负载均衡(七层负载均衡)。

4、【网络层】IP负载均衡(LVS-NAT)

        NAT服务器:它工作在传输层，它可以修改发送来的IP数据包，将数据包的目标地址修改为实际服务器地址。

从 Linux2.4内核开始，其内置的Neftilter模块在内核中维护着一些数据包过滤表，这些表包含了用于控制数据包过滤的规则。可喜的是，Linux提供了iptables来对过滤表进行插入、修改和删除等操作。更加令人振奋的是，Linux2.6.x内核中内置了IPVS模块，它的工作性质类型于Netfilter模块，不过它更专注于实现IP负载均衡。

想知道你的服务器内核是否已经安装了IPVS模块，可以

有输出意味着IPVS已经安装了。IPVS的管理工具是ipvsadm，它为提供了基于命令行的配置界面，可以通过它快速实现负载均衡系统。这就是大名鼎鼎的LVS(Linux Virtual Server，Linux虚拟服务器)

原理：在网络层通过修改目标地址进行负载均衡。

如图：

      用户请求包到达负载均衡服务器114.100.20.200后，负载均衡服务器在操作系统内核层获取网络数据包，根据负载均衡算法获取真实后台服务器地址192.168.1.1, 然后将数据包的目标地址改为192.168.1.1, 转发给内部服务器。整个过程都在内核层进行处理。收到192.168.1.1的响应包之后，会更改响应包的SRC IP, 转发给客户端用户。采用IP层负载均衡算法，全部处理过程都在内核层(Ring 0)进行。和七层负载均衡相比，具有更好的性能。

1、打开调度器的数据包转发选项

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

2、检查实际服务器是否已经将NAT服务器作为自己的默认网关，如果不是，如添加

route add default gw xx.xx.xx.xx

3、使用ipvsadm配置

ipvsadm -A -t 111.11.11.11:80 -s rr  

添加一台虚拟服务器，-t 后面是服务器的外网ip和端口，-s rr是指采用简单轮询的RR调度策略（这属于静态调度策略，除此之外，LVS还提供了系列的动态调度策略，比如最小连接（LC）、带权重的最小连接（WLC），最短期望时间延迟（SED）等）

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m  

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m  

添加两台实际服务器（不需要有外网ip），-r后面是实际服务器的内网ip和端口，-m表示采用NAT方式来转发数据包

运行ipvsadm -L -n可以查看实际服务器的状态。这样就大功告成了。

实验证明使用基于NAT的负载均衡系统。作为调度器的NAT服务器可以将吞吐率提升到一个新的高度，几乎是反向代理服务器的两倍以上，这大多归功于在内核中进行请求转发的较低开销。但是一旦请求的内容过大时，不论是基于反向代理还是NAT，负载均衡的整体吞吐量都差距不大，这说明对于一睦开销较大的内容，使用简单的反向代理来搭建负载均衡系统是值靠虑的。

 

 

优点：在响应请求时速度较反向服务器负载均衡要快。

缺点：当请求数据较大（大型视频或文件）时，速度较慢，很容易成为系统的瓶颈。

 

5、【链路层】数据链路层负载均衡

原理：在数据链路层修改Mac地址进行负载均衡。

 

如图：

负载均衡服务器的IP和它所管理的web 服务群的虚拟IP一致；

负载均衡数据分发过程中不修改访问地址的IP地址，而是修改Mac地址；

通过这两点达到不修改数据包的原地址和目标地址就可以进行正常的访问。

 

优点：不需要负载均衡服务器进行地址的转换。

数据响应时不需要经过负载均衡服务器。

缺点：负载均衡服务器的网卡带宽要求较高。

 

目前连路程负载均衡是特别常见的一种手段，典型的产品有LVS（Linux Virtual Server）。

 

WEB负载均衡策略

硬件负载均衡框架结构

       后台的多个Web节点上面有相同的Web应用，用户的访问请求首先进入负载均衡分配节点(可能是软件或者硬件)，由它根据负载均衡策略（算法）合理地分配给某个Web应用节点。每个Web节点相同的内容做起来不难，所以选择负载均衡策略（算法）是个关键问题。

 web负载均衡的作用就是把请求均匀的分配给各个节点，它是一种动态均衡，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把请求理分配出去。对于不同的应用环境（如电子商务网站，它的计 算负荷大；再如网络数据库应用，读写频繁，服务器的存储子系统系统面临很大压力；再如视频服务应用，数据传输量大，网络接口负担重压。），使用的均衡策略(算法)是不同的。 所以均衡策略（算法）也就有了多种多样的形式，广义上的负载均衡既可以设置专门的网关、负载均衡器，也可以通过一些专用软件与协议来实现。在OSI七层协议模型中的第二（数据链路层）、第三（网络层）、第四（传输层）、第七层（应用层）都有相应的负载均衡策略（算法），在数据链路层上实现负载均衡的原理是根据数据包的目的MAC地址选择不同的路径；在网络层上可利用基于IP地址的分配方式将数据流疏通到多个节点；而传输层和应用层的交换（Switch），本身便是一种基于访问流量的控制方式，能够实现负载均衡。

 

系统负载能力浅析

 

一. 衡量指标

衡量一个系统的负载能力 : 每秒请求数（Requests per second），指的是每秒能够成功处理请求的数目。很多请求是不会在一定的时间内得到响应的，这并不作为一个成功的请求，其中成功得到响应的请求数即为每秒请求数，反应出系统的负载能力。

二. 相关因素

一般的，和系统并发访问量相关的几个因素如下：

• 带宽

• 硬件配置

• 系统配置

• 应用服务器配置

• 程序逻辑

带宽和硬件配置是决定系统负载能力的决定性因素。这些只能依靠扩展和升级提高。

2.1 带宽

带宽是决定系统负载能力的一个至关重要的因素，一个系统的带宽首先就决定了这个系统的负载能力，其单位为Mbps,表示数据的发送速度。

2.2 硬件配置

系统部署所在的服务器的硬件决定了一个系统的最大负载能力，也是上限。一般说来，以下几个配置起着关键作用：

• cpu频率/核数：cpu频率关系着cpu的运算速度，核数则影响线程调度、资源分配的效率。

• 内存大小以及速度：内存越大，那么可以在内存中运行的数据也就越大，速度自然而然就快；内存的速度从原来的几百hz到现在几千hz，决定了数据读取存储的速度。

• 硬盘速度：传统的硬盘是使用磁头进行寻址的，io速度比较慢，使用了SSD的硬盘，其寻址速度大大较快。

很多系统的架构设计、系统优化，最终都会加上这么一句：使用ssd存储解决了这些问题。

2.3 系统配置

对于Linux系统来说一般有以下配置关系着系统的负载能力。

• 文件描述符数限制：Linux中所有东西都是文件，一个socket就对应着一个文件描述符，因此系统配置的最大打开文件数以及单个进程能够打开的最大文件数就决定了socket的数目上限。

• 进程/线程数限制: 对于apache使用的prefork等多进程模式，其负载能力由进程数目所限制。对tomcat多线程模式则由线程数所限制。

• tcp内核参数：网络应用的底层自然离不开tcp/ip，Linux内核有一些与此相关的配置也决定了系统的负载能力。

2.3.1 文件描述符数限制

 

• 系统最大打开文件描述符数：/proc/sys/fs/file-max中保存了这个数目,修改此值

临时性

echo 1000000 > /proc/sys/fs/file-max

永久性：在/etc/sysctl.conf中设置

fs.file-max = 1000000

• 进程最大打开文件描述符数：这个是配单个进程能够打开的最大文件数目。可以通过ulimit -n查看/修改。如果想要永久修改，则需要修改/etc/security/limits.conf中的nofile。

通过读取/proc/sys/fs/file-nr可以看到当前使用的文件描述符总数。另外，对于文件描述符的配置，需要注意以下几点：

• 所有进程打开的文件描述符数不能超过/proc/sys/fs/file-max

• 单个进程打开的文件描述符数不能超过user limit中nofile的soft limit

• nofile的soft limit不能超过其hard limit

• nofile的hard limit不能超过/proc/sys/fs/nr_open

2.3.2 进程/线程数限制

• 进程数限制：ulimit -u可以查看/修改单个用户能够打开的最大进程数。/etc/security/limits.conf中的noproc则是系统的最大进程数。

• 线程数限制

  • 可以通过/proc/sys/kernel/threads-max查看系统总共可以打开的最大线程数。

  • 单个进程的最大线程数和PTHREAD_THREADS_MAX有关，此限制可以在/usr/include/bits/local_lim.h中查看,但是如果想要修改的话，需要重新编译。

  • 这里需要提到一点的是，Linux内核2.4的线程实现方式为linux threads，是轻量级进程，都会首先创建一个管理线程，线程数目的大小是受PTHREAD_THREADS_MAX影响的。但Linux2.6内核的线程实现方式为NPTL,是一个改进的LWP实现，最大一个区别就是，线程公用进程的pid（tgid），线程数目大小只受制于资源。

  • 线程数的大小还受线程栈大小的制约：使用ulimit -s可以查看/修改线程栈的大小，即每开启一个新的线程需要分配给此线程的一部分内存。减小此值可以增加可以打开的线程数目。

2.3.3 tcp内核参数

在一台服务器CPU和内存资源额定有限的情况下，最大的压榨服务器的性能，是最终的目的。在节省成本的情况下，可以考虑修改Linux的内核TCP/IP参数，来最大的压榨服务器的性能。如果通过修改内核参数也无法解决的负载问题，也只能考虑升级服务器了，这是硬件所限，没有办法的事。

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

使用上面的命令，可以得到当前系统的各个状态的网络连接的数目。如下：

LAST_ACK 14

SYN_RECV 348

ESTABLISHED 70

FIN_WAIT1 229

FIN_WAIT2 30

CLOSING 33

TIME_WAIT 18122

这里，TIME_WAIT的连接数是需要注意的一点。此值过高会占用大量连接，影响系统的负载能力。需要调整参数，以尽快的释放time_wait连接。

一般tcp相关的内核参数在/etc/sysctl.conf文件中。为了能够尽快释放time_wait状态的连接，可以做以下配置：

• net.ipv4.tcp_syncookies = 1 //表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

• net.ipv4.tcp_tw_reuse = 1 //表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

• net.ipv4.tcp_tw_recycle = 1 //表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭；

• net.ipv4.tcp_fin_timeout = 30 //修改系統默认的 TIMEOUT 时间。

这里需要注意的一点就是当打开了tcp_tw_reccycle，就会检查时间戳，移动环境下的发来的包的时间戳有些时候是乱跳的，会把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据，不是新的请求”，于是丢掉不回包，造成大量丢包。

此外，还可以通过优化tcp/ip的可使用端口的范围，进一步提升负载能力。，如下：

• net.ipv4.tcp_keepalive_time = 1200 //表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。

• net.ipv4.ip_local_port_range = 10000 65000 //表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为10000到65000。（注意：这里不要将最低值设的太低，否则可能会占用掉正常的端口！）

• net.ipv4.tcp_max_syn_backlog = 8192 //表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。

• net.ipv4.tcp_max_tw_buckets = 5000 //表示系统同时保持TIME_WAIT的最大数量，如果超过这个数字，TIME_WAIT将立刻被清除并打印警告信息。默认为180000，改为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于Squid，效果却不大。此项参数可以控制TIME_WAIT的最大数量，避免Squid服务器被大量的TIME_WAIT拖死。

2.4 应用服务器配置

说到应用服务器配置，这里需要提到应用服务器的几种工作模式,也叫并发策略。

• multi process:多进程方式，一个进程处理一个请求。

• prefork：类似于多进程的方式，但是会预先fork出一些进程供后续使用，是一种进程池的理念。

• worker：一个线程对应一个请求，相比多进程的方式，消耗资源变少，但同时一个线程的崩溃会引起整个进程的崩溃，稳定性不如多进程。

• master/worker：采用的是非阻塞IO的方式，只有两种进程：worker和master,master负责worker进程的创建、管理等，worker进程采用基于事件驱动的多路复用IO处理请求。mater进程只需要一个，woker进程根据cpu核数设置数目。

前三者是传统应用服务器apache和tomcat采用的方式，最后一种是nginx采用的方式。当然这里需要注意的是应用服务器和nginx这种做反向代理服务器（暂且忽略nginx+cgi做应用服务器的功能）的区别。应用服务器是需要处理应用逻辑的，有时候是耗cup资源的；而反向代理主要用作IO，是IO密集型的应用。使用事件驱动的这种网络模型，比较适合IO密集型应用，而并不适合CPU密集型应用。对于后者，多进程/线程则是一个更好地选择。

当然，由于nginx采用的基于事件驱动的多路IO复用的模型，其作为反向代理服务器时，可支持的并发是非常大的。淘宝tengine团队曾有一个测试结果是“24G内存机器上，处理并发请求可达200万”。

2.4.1 nginx/tengine

ngixn是目前使用最广泛的反向代理软件，而tengine是阿里开源的一个加强版nginx,其基本实现了nginx收费版本的一些功能，如：主动健康检查、session sticky等。对于nginx的配置，需要注意的有这么几点：

• worker数目要和cpu（核）的数目相适应

• keepalive timout要设置适当

• worker_rlimit_nofile最大文件描述符要增大

• upstream可以使用http 1.1的keepalive

典型配置可见：https://github.com/superhj1987/awesome-config/blob/master/nginx/nginx.conf

2.4.2 tomcat

tomcat的关键配置总体上有两大块：jvm参数配置和connector参数配置。

• jvm参数配置：

  这里对于栈大小有一点需要注意的是：在Linux x64上ThreadStackSize的默认值就是1024KB，给Java线程创建栈会用这个参数指定的大小。如果把-Xss或者-XX:ThreadStackSize设为0，就是使用“系统默认值”。而在Linux x64上HotSpot VM给Java栈定义的“系统默认”大小也是1MB。所以普通Java线程的默认栈大小怎样都是1MB。这里有一个需要注意的地方就是java的栈大小和之前提到过的操作系统的操作系统栈大小（ulimit -s）：这个配置只影响进程的初始线程；后续用pthread_create创建的线程都可以指定栈大小。HotSpot VM为了能精确控制Java线程的栈大小，特意不使用进程的初始线程（primordial thread）作为Java线程。

  其他还要根据业务场景，选择使用那种垃圾回收器，回收的策略。另外，当需要保留GC信息时，也需要做一些设置。

  典型配置可见：https://github.com/superhj1987/awesome-config/blob/master/tomcat/java_opts.conf

  • 堆的最小值：Xms

  • 堆的最大值：Xmx

  • 新生代大小: Xmn

  • 永久代大小: XX:PermSize：

  • 永久代最大大小: XX:MaxPermSize：

  • 栈大小：-Xss或-XX:ThreadStackSize

• connector参数配置

  典型配置可见：https://github.com/superhj1987/awesome-config/blob/master/tomcat/connector.conf

  一般的当一个进程有500个线程在跑的话，那性能已经是很低很低了。Tomcat默认配置的最大请求数是150。当某个应用拥有250个以上并发的时候，应考虑应用服务器的集群。

  另外，并非是无限调大maxTreads和maxConnection就能无限调高并发能力的。线程越多，那么cpu花费在线程调度上的时间越多，同时，内存消耗也就越大，那么就极大影响处理用户的请求。受限于硬件资源，并发值是需要设置合适的值的。

  • protocol: 有三个选项：bio；nio；apr。建议使用apr选项，性能为最高。

  • connectionTimeout：连接的超时时间

  • maxThreads：最大线程数，此值限制了bio的最大连接数

  • minSpareThreads: 最大空闲线程数

  • acceptCount：可以接受的最大请求数目（未能得到处理的请求排队）

  • maxConnection: 使用nio或者apr时，最大连接数受此值影响。

对于tomcat这里有一个争论就是：使用大内存tomcat好还是多个小的tomcat集群好？（针对64位服务器以及tomcat来说）

其实，这个要根据业务场景区别对待的。通常，大内存tomcat有以下问题：

• 一旦发生full gc，那么会非常耗时

• 一旦gc，dump出的堆快照太大，无法分析

因此，如果可以保证一定程度上程序的对象大部分都是朝生夕死的，老年代不会发生gc,那么使用大内存tomcat也是可以的。但是在伸缩性和高可用却比不上使用小内存（相对来说）tomcat集群。

使用小内存tomcat集群则有以下优势：

• 可以根据系统的负载调整tc的数量，以达到资源的最大利用率，

• 可以防止单点故障。

2.4.3 数据库

mysql是目前最常用的关系型数据库，支持复杂的查询。但是其负载能力一般。很多时候一个系统的瓶颈就发生在mysql这一点，当然有时候也和sql语句的效率有关。比如，牵扯到联表的查询一般说来效率是不会太高的。

当数据量单表突破千万甚至百万时（和具体的数据有关），查询和插入效率都会受到影响。此时，需要对mysql数据库进行优化，一种常见的方案就是分表：

• 垂直分表：在列维度的拆分

• 水平分表：行维度的拆分

对于系统中并发很高并且访问很频繁的数据，会放到缓存数据库中，以隔离对mysql的访问,防止mysql崩溃。

redis是目前用的比较多的缓存数据库（当然，也有直接把redis当做数据库使用的）。

此外，对于数据库，可以使用读写分离的方式提高性能，尤其是对那种读频率远大于写频率的业务场景。这里采用master/slave的方式实现读写分离，前面用程序控制或者加一个proxy层。

三. 一般架构

一般的web应用架构如下图所示：lvs+nginx+tomcat+mysql+redis

 

 

 

负载场景和解决方式

1、不同的负载场景

我们知道负载均衡层的作用是“将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上”，那么不同的业务场景需要的负载均衡方式又是不一样的，架构师还要考虑架构方案的成本、可扩展性、运维难易度等问题。下面我们先介绍几种典型的不同业务场景，大家也可以先想一下如果是您，会怎么架设这些场景的负载均衡层。

需要注意的是，这个系统的文章，我们都将使用这几个典型的业务场景来讲解系统架构的设计递归设计。在后续几篇介绍负载层架构的文章中，我们也将通过这几个典型的业务场景讲解负载层的架构方案。

1.1、负载场景一

这是一个国家级物流园区的货运订单和物流管理系统。在物流园区内的货运代理商、合作司机（货运车辆）、园区管理员和客服人员都要使用这套系统。每日RUV在1万人次，日PV在10万左右。甲方总经理使用这套系统的原有是抱着“试一下移动互联网对物流产品是否能起到提高效率的作用”。可以看出整个系统基本上没有访问压力，甲方对您设计的系统只有一个要求：能够保证系统以后的功能和性能扩展性。

1.2、负载场景二

效果不错！在第一版系统架设后的6个月，货场丢货的情况大大减少，并且由于货车在途情况的监控，按时到达率也显著提升，货车司机也反映由于整个货场货车信息都是共享的，货车的待货时间也明显缩短。在这期间物流园中越来越多的货运代理商、货车司机都开始使用这套系统了，整个系统的访问量成线性增长。

物流园的总经理对整个系统的作用感到满意，决定扩大系统的使用范围，并增加新的功能。经过讨论甲方最终决定把整套系统开放给货主：或者可以在系统上查看货运代理商的线路报价、线上通知代理商上门取货、监控目前自己货品的运输状态、了解第三方签收情况。初步估计系统的日RUV将达到10万，日PV将突破50万。

1.3、负载场景三

一年后，赞不绝口的大宗货品运输服务质量终于传到了政府领导的耳朵里。省里分管运输的领导亲自领队到物流园区参观考察，最终决定由省政府牵头，各地方政府参与，将这套管理办法在整个省级范围进行推广使用。全省10家大型物流园和50家二级物流园中的上万货运代理商、散落省内的零散代理商、10万个人/企业货主、40万优等资质车源共同接入系统。

新的功能上，增加了费用结算和运费保障功能，从货主预付款开始到第三方确认收货的整个环节都进行费用管理。为了保证线上收货环节的顺利，新版本中还增加了代理商之间的合作收货功能。新系统的日RUV将超过50万，日PV将突破250万。

1.4、负载场景四

服务效应、经济效应、口碑效应不断发酵，经过近两年多的发展，目前这套系统已经是省内知名的物流配送平台，专门服务大宗货运物流。联合政府向全国推广服务的时机终于到来。预计全国1000多个物流园区，50万左右物流代理商，500万货运车辆、数不清的个人和企业货主都将使用该系统。预估的RUV和PV是多少呢？无法预估，如果按照全国32省来进行一个简单的乘法，是可以得到一个大概的值（50万 * 32 = 1500万+；500万 * 32 = 1.5亿+，已经超过了JD.com的平峰流量），但是各省的物流业规模是不一样的，从业者数量也不一样，所以这样的预估并不科学。而且再这样的系统规模下我们应该更过的考虑系统的峰值冗余。

业务功能的情况：为了保证注册货车的有效性，您所在的公司被政府允许访问政府的车辆信息库，在车辆注册的过程中进行车辆信息有效性的验证（第三方系统接口调用，我们并不知道第三方系统是否能够接收一个较高水平的并发量，所以这个问题留给我我们的架构师，我们将在业务层讲解时进行详细的描述）。

1.5、沉思片刻

看到这里，我们已经将几个递进的业务场景进行了详细的说明（甚至在后文中我们讨论业务层、业务通信层、数据存储层时所涉及的业务场景也不会有什么大的变化了）。看客们看到这里，可以稍作休息，先想想如果是您，您会如何搭建负载层，甚至整个系统的顶层架构。

由于整个系统的性能除了和硬件有关外，业务层的拆分规则，代码质量，缓存技术的使用方式，数据库的优化水平都可能对其产生影响。所以：

我们在讨论负载层的几篇文章中，我们要假设系统架构中各层的设计都没有对系统性能产生瓶颈

如果您已经思考好了，那么可以继续看以下的内容。

2、负载方案构想

2.1、解决方案一：独立的Nginx/Haproxy方案

很显然，第一个业务场景下，系统并没有多大的压力就是一套简单业务系统，日访问量也完全没有“有访问压力”这样的说法。但是客户有一个要求值得我们关注：要保证系统以后的功能和性能扩展性。为了保证功能和性能扩展性，在系统建立之初就要有一个很好的业务拆分规划，例如我们首先会把用户信息权限子系统和订单系统进行拆分，独立的车辆信息和定位系统可能也需要拆分出来。

这也是我们在系统建立时就要引入负载均衡层的一个重要原因。也是负载均衡层的重要作用之一。如下图所示：

可以看出，这时负载均衡层只有一个作用，就是按照设定的访问规则，将访问不同系统的请求转发给对应的系统，并且在出现错误访问的情况下转发到错误提示页面。

2.2、解决方案二：Nginx/Haproxy + Keepalived方案

此后，系统的访问压力进一步加大，系统的稳定性越来越受到我们的关注。所以在单节点处理还能满足业务要求的情况下，我们为负载层（还有各层）引入热备方案，以保证一个节点在崩溃的情况下，另一个节点能够自动接替其工作，为工程师解决问题赢得时间。如下图所示：

2.3、解决方案三：LVS（DR）+ Keepalived+ Nginx方案

在第三版本架构方案中，为了保证负载层足够稳定的状态下，适应更大的访问吞吐量还要应付可能的访问洪峰，我们加入了LVS技术。LVS负责第一层负载，然后再将访问请求转发到后端的若干台Nginx上。LVS的DR工作模式，只是将请求转到后端，后端的Nginx服务器必须有一个外网IP，在收到请求并处理完成后，Nginx将直接发送结果到请求方，不会再经LVS回发（具体的LVS工作原理介绍将在后文中详细介绍）。

这里要注意的是：

• 有了上层的LVS的支撑Nginx就不再需要使用Keepalived作为热备方案。因为首先Nginx不再是单个节点进行负载处理，而是一个集群多台Nginx节点；另外LVS对于下后端的服务器自带基于端口的健康检查功能；

• LVS是单节点处理的，虽然LVS是非常稳定的，但是为了保证LVS更稳定的工作，我们还是需要使用Keepalived为 LVS做一个热备节点，以防不时之需。

2.4、解决方案四：DNS轮询 + LVS（DR）+ Keepalived + Nginx方案

场景四中，为了满足平均上亿的日PV访问，在对业务进行外网暴露的基础上，我们在互联网的最前端做了一个DNS轮询。然后将（对用户信息系统）访问压力首先分摊到两个对称LVS组上，再由每个组向下继续分拆访问压力。

注意上图的负载层方案的不同：

• 首先我们不在像前面的方案中，使用目录名分割业务系统了，而是直接将业务系统的访问使用不同的二级域名进行拆分。这样的变化有利于每个业务系统都拥有自己独立的负载均衡层。

• 请注意上图中的细节，这个负载均衡层是专门为“用户信息子系统”提供负载均衡支撑的，而可能还存在的“订单子系统”、“车辆信息子系统”都会有他们独立的负载均衡层。

• 在LVS下方的Nginx服务可以实现无限制的扩展，同样的就像场景三种所给出的解决方案一样，Nginx本身不在需要Keepalived保持热备，而是全部交由上层的LVS进行健康情况检查。而即使有一两台Nginx服务器出现故障，对整个负载集群来说问题也不大。

方案扩展到了这一步，LVS层就没有必要再进行扩展新的节点了。为什么呢？根据您的业务选择的合适的LVS工作模式，两个LVS节点的性能足以支撑地球上的所有核心WEB站点。如果您对LVS的性能有疑惑，请自行谷歌百度。这里我们提供了一份参考资料：《LVS性能，转发数据的理论极限》http://www.zhihu.com/question/21237968

3、为什么没有独立的LVS方案

在下一篇文章《架构设计：负载均衡层设计方案（2）——LVS、keepalived、Nginx安装和核心原理解析》中我们将提到这个问题。实际上通过本篇文章的架构演进分析，一些读者都可以看出端倪。如果用一句话说明其中的原因，那就是LVS为了保证其性能对配置性有所牺牲，单独使用的话往往无法满足业务层对负载层灵活分配请求的要求。

4、说明

4.1、术语说明

• TPS: 衡量业务层处理性能的重要指标（每秒钟request/事务的处理数量）。业务服务处理一个完整的业务过程，并向上层返回处理结果的过程就是一个 request/事务。那么在一秒钟内整个业务系统能够完成多少个这样的过程，其衡量单位就是TPS。TPS不但和系统架构有很大的关系（特别是业务层和业务通信层的架构祥泰），和物理环境、代码质量的关系也非常密切。

• PV: 网页浏览数是评价网站流量最常用的指标之一，简称为PV。Page Views中的Page一般是指普通的html网页，也包含php、jsp等动态产生的html内容。注意是完整的显示一个Page成为一个PV。但是一个PV，一般需要多次HTTP请求，以便获取多个静态资源，这是需要注意的。

• UV: Unique Visitor 一个独立IP，在一个单位时间内（例如一日/一小时）对系统的一个PV请求，成为一个UV（重复的PV不在进行计数）。

• RUV: Repeat User Visitor 一个独立用户，在一个单位时间内（例如一日/一小时）对系统的一个PV请求，并且重复的访问要进行计数。

4.2、后文介绍

下篇文章《架构设计：负载均衡层设计方案（2）——LVS、keepalived、Nginx安装和核心原理解析》中，我们将提到LVS的工作原理和Nginx中核心负载策略的工作原理（Hash、轮询、权重），以及独立的LVS、Nginx、keepalived的安装方式（虽然安装方式在网络上一个搜索就能搜出来一大把，但是很对都是抄袭，且没有经过详细的正误检查，所以我觉得还是需要重新进行一下说明）

 

常见问题：

什么是nginx的异步处理： 

• squid同步处理：浏览器发起请求，而后请求会立刻被转到后端，于是在浏览器和> 后台之间就建立了一个通道。从请求发起直到请求完成，这条通道都是一直存在的。

nginx异步处理：

• 浏览器发起请求，请求不会立刻转到后端，而是请求数据(header)先收到nignx上，然后nginx再把这个请求发到后端，后端处理完成后把数据返回到nginx上，nginx将数据流发到浏览器。

使用异步处理的好处

            

• 假设用户执行一个上传文件操作，因为用户网速又比较慢，因此需要花半个小时才能把文件传到服务器。squid的同步代理在用户开始上传后就和后台建立了连接，半小时后文件上传结束，由此可见，后台服务器连接保持了半个小时；而nginx异步代理就是先将此文件收到nginx上，因此仅仅是nginx和用户保持了半小时连接，后台服务器在这半小时内没有为这个请求开启连接，半小时后用户上传结束，nginx才将上传内容发到后台，nginx和后台之间的带宽是很充裕的，所以只花了一秒钟就将请求发送到了后台，由此可见，后台服务器连接保持了一秒。同步传输花了后台服务器半个小时，异步传输只花一秒，可见优化程度很大。

• 在上面这个例子中，假如后台服务器因为种种原因重启了，上传文件就自然中断了，这对用户来说是非常恼火的一件事情，想必各位也有上传文件传到一半被中断的经历。用nginx代理之后，后台服务器的重启对用户上传的影响减少到了极点，而nginx是非常稳定的并不需要常去重启它，即使需要重启，利用kill-HUP就可以做到不间断重启nginx。

• 异步传输可以令负载均衡器更有保障，为什么这么说呢？在其它的均衡器（lvs/haproxy/apache等）里，每个请求都是只有一次机会的，假如用 
  户发起一个请求，结果该请求分到的后台服务器刚好挂掉了，那么这个请求就失败了；而nginx因为是异步的，所以这个请求可以重新发往下一个后台，下一个后台返回了正常的数据，于是这个请求就能成功了。还是用用户上传文件这个例子，假如不但用了nginx代理，而且用了负载均衡，nginx把上传文件发往其中一台后台，但这台服务器突然重启了，nginx收到错误后，会将这个上传文件发到另一台后台，于是用户就不用再花半小时上传一遍。

• 假如用户上传一个10GB大小的文件，而后台服务器没有考虑到这个情况，那么后台服务器岂不要崩溃了。用nginx就可以把这些东西都拦在nginx上，通过nginx的上传文件大小限制功能来限制，另外nginx性能非常有保障，就放心的让互联网上那些另类的用户和nginx对抗去吧。用异步传输会造成问题：后台服务器有提供上传进度的功能的话，用了nginx代理就无法取得进度，这个需要使用nginx的一个第三方模块来实现。

 

Web系统架构

大型动态应用系统平台主要是针对于大流量、高并发网站建立的底层系统架构。大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。

大型动态应用系统又可分为几个子系统：

1）Web前端系统

2）负载均衡系统

3）数据库集群系统

4）缓存系统

5）分布式存储系统

6）分布式服务器管理系统

7）代码分发系统

Web前端系统

结构图：

为了达到不同应用的服务器共享、避免单点故障、集中管理、统一配置等目的，不以应用划分服务器，而是将所有服务器做统一使用，每台服务器都可以对多个应用提供服务，当某些应用访问量升高时，通过增加服务器节点达到整个服务器集群的性能提高，同时使他应用也会受益。该Web前端系统基于Apache/Lighttpd/Eginx等的虚拟主机平台，提供PHP程序运行环境。服务器对开发人员是透明的，不需要开发人员介入服务器管理

负载均衡系统

负载均衡系统分为硬件和软件两种。硬件负载均衡效率高，但是价格贵，比如F5等。软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs, nginx。大多数网站都是硬件、软件负载均衡系统并用。

数据库集群系统

结构图：

由于Web前端采用了负载均衡集群结构提高了服务的有效性和扩展性，因此数据库必须也是高可靠的，才能保证整个服务体系的高可靠性，如何构建一个高可靠的、可以提供大规模并发处理的数据库体系？

我们可以采用如上图所示的方案：

1) 使用 MySQL 数据库，考虑到Web应用的数据库读多写少的特点，我们主要对读数据库做了优化，提供专用的读数据库和写数据库，在应用程序中实现读操作和写操作分别访问不同的数据库。

2) 使用 MySQL Replication 机制实现快速将主库（写库）的数据库复制到从库（读库）。一个主库对应多个从库，主库数据实时同步到从库。

3) 写数据库有多台，每台都可以提供多个应用共同使用，这样可以解决写库的性能瓶颈问题和单点故障问题。

4) 读数据库有多台，通过负载均衡设备实现负载均衡，从而达到读数据库的高性能、高可靠和高可扩展性。

5) 数据库服务器和应用服务器分离。

6) 从数据库使用BigIP做负载均衡。

缓存系统

缓存分为文件缓存、内存缓存、数据库缓存。在大型Web应用中使用最多且效率最高的是内存缓存。最常用的内存缓存工具是Memcached。使用正确的缓存系统可以达到实现以下目标：

1、使用缓存系统可以提高访问效率，提高服务器吞吐能力，改善用户体验。

2、减轻对数据库及存储集服务器的访问压力。

3、Memcached服务器有多台，避免单点故障，提供高可靠性和可扩展性，提高性能。

分布式存储系统

结构图：

Web系统平台中的存储需求有下面两个特点：

1) 存储量很大，经常会达到单台服务器无法提供的规模，比如相册、视频等应用。因此需要专业的大规模存储系统。

2) 负载均衡cluster中的每个节点都有可能访问任何一个数据对象，每个节点对数据的处理也能被其他节点共享，因此这些节点要操作的数据从逻辑上看只能是一个整体，不是各自独立的数据资源。

因此高性能的分布式存储系统对于大型网站应用来说是非常重要的一环。（这个地方需要加入对某个分布式存储系统的简单介绍。）

分布式服务器管理系统

结构图：

随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，原来基于单机的服务器管理模式已经不能够满足我们的需求，新的需求必须能够集中式的、分组的、批量的、自动化的对服务器进行管理，能够批量化的执行计划任务。

在分布式服务器管理系统软件中有一些比较优秀的软件，其中比较理想的一个是Cfengine。它可以对服务器进行分组，不同的分组可以分别定制系统配置文件、计划任务等配置。它是基于C/S 结构的，所有的服务器配置和管理脚本程序都保存在Cfengine Server上，而被管理的服务器运行着 Cfengine Client 程序，Cfengine Client通过SSL加密的连接定期的向服务器端发送请求以获取最新的配置文件和管理命令、脚本程序、补丁安装等任务。

有了Cfengine这种集中式的服务器管理工具，我们就可以高效的实现大规模的服务器集群管理，被管理服务器和 Cfengine Server 可以分布在任何位置，只要网络可以连通就能实现快速自动化的管理。

代码发布系统

结构图：

随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，为了满足集群环境下程序代码的批量分发和更新，我们还需要一个程序代码发布系统。

这个发布系统可以帮我们实现下面的目标：

1) 生产环境的服务器以虚拟主机方式提供服务，不需要开发人员介入维护和直接操作，提供发布系统可以实现不需要登陆服务器就能把程序分发到目标服务器。

2) 我们要实现内部开发、内部测试、生产环境测试、生产环境发布的4个开发阶段的管理，发布系统可以介入各个阶段的代码发布。

3) 我们需要实现源代码管理和版本控制，SVN可以实现该需求。

这里面可以使用常用的工具Rsync，通过开发相应的脚本工具实现服务器集群间代码同步分发。

 

• • 1、Web层

  • 主体架构可以基于 Struts 1.X/2.X，当然有很多更好的控制层框架供选择，以快速敏捷为准则吧。 
    抽象出核心库封装 控制器和中间层的操作。 
    在大规模集群环境下，session复制会引起严重的性能问题。考虑用 集群缓存 + cookie验证 代替session实现权限控制吧。

    
    2、Cache层
    配置 Memcache 组成集群缓存 
    对 Memcache 客户端进行封装 
    Memcached 节点组成池，调用示意：opList (BizName, 策略 ...)

    3、中间层
    “中间层”可以理解为基于应用和数据之间的层次。它被设计用来为Web应用提供：数据缓存 和 对应用透明的数据访问——即应用不需要考虑数据表拆分的问题。以服务的方式提供对存储层的高性能调用以及分布式计算。可供选择的框架：ICE 、Hadoop 直接基于Memcache开发（减少复杂度，推荐）

    
    4、存储
    推荐MySQL，理由：免费，经过实践检验，有大量成熟的案例、解决方案、技术支持。
    小规模：一个 data table 维护存储服务器阵列，内容 -> mount …… 
    大规模：Master-Slave模式+MySQL Proxy，实现数据库读写分离。在中间层的包装下，可做如下扩展，以支持更大规模的数据存取： 
    数据库/表水平拆分，例 User -> User33% + User33% + User34% 
    数据库/表垂直拆分，例 User -> UserBaseInfo + UserAddrInfo 
    也可考虑使用 LongStore (龙存) 解决方案，由龙存管理存储阵列……

    
    5、部署
    划分子域名，每个子域名一个Web应用包，互不干扰 
    静态资源（css, js, image ...）使用专门的静态服务器

    
    6、负载均衡
    小规模：DNS轮询。
    大规模：F5， 2*X 台F5服务器，F5是L4/L7层交换机，每台至少可处理200万连接（与服务器内存有关）。
    Ngnix是L7层交换，LVS负载均衡也是一种方案

    
    7、Web中间件选择
    Tomcat - 最高400并发 
    Apache - 最高2000并发 
    Ngnix - 优于Apache 
    采用方案：Ngnix + Resin ，理由：
    Resin提供更为快速的servlet引擎 - 选择Resin。 
    gzip问题 - Resin在单独处理gzip时存在内存溢出的隐患，因此要加一层 Ngnix。 
    Ngnix 能减少单独使用Resin时的内存占用 - Resin建立1000个连接使用1000个线程；加Ngnix后，透过其“异步连接”、“建立长连接”机制使Resin内存压力大大减小。 
    Ngnix 针对Linux系统有性能优化措施 - 0 Copy, send file ... 
    因此采用：1 Ngnix + 1 Resin，一对一。
    静态服务器采用：Squid + Apache, why? because Squid has cache ability ...

    
    新变化 - Nginx从0.7.48版本开始，支持了类似Squid的缓存功能。这个缓存是把URL及相关组合当作Key，用md5编码哈希后保存在硬盘上，所以它可以支持任意URL链接，同时也支持 404/301/302 这样的非200状态码。虽然目前官方的Nginx Web缓存服务只能为指定URL或状态码设置过期时间，不支持类似Squid的PURGE指令，手动清除指定缓存页面，但是，通过一个第三方的Nginx 模块，可以清除指定URL的缓存。

    
    Nginx的Web缓存服务主要由proxy_cache相关指令集和fastcgi_cache相关指令集构成，前者用于反向代理时，对后端内容源服务器进行缓存，后者主要用于对FastCGI的动态程序进行缓存。两者的功能基本上一样。
    最新的Nginx 0.8.31版本，proxy_cache和fastcgi_cache已经比较完善，加上第三方的ngx_cache_purge模块（用于清除指定 URL的缓存），已经可以完全取代Squid。有的网站已经在生产环境使用了 Nginx 的 proxy_cache 缓存功能超过两个月，十分稳定，速度不逊于 Squid。

 

大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。

 

解决大型网站面临的高负载和高并发问题

1、HTML静态化

效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS。

在进行html静态化的时候可以使用一种折中的方法，就是前端使用动态实现，在一定的策略下进行定时静态化和定时判断调用

2、图片服务器分离

这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。

3、数据库集群和库表散列

4、缓存

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的mod_proxy缓存模块，也可以使用外加的Squid进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。

6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

6.1 硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

6.2 软件四层交换
大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

软件四层交换我们可以使用Linux上常用的LVS来解决，

典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

 

 

 

参考链接：

转载来源：https://blog.csdn.net/yinwenjie/article/details/46605451

https://blog.csdn.net/wuqingzhu8080/article/details/78693268

https://blog.csdn.net/boonya/article/details/38733787

https://mp.weixin.qq.com/s/fjBUzkUfDxYpBhGxKvz2CQ

 

链接： 

集群容错            ：     https://www.jianshu.com/p/9c74870dbde2

（mac 系统）我的项目经验总结——负载均衡的理解和实战：2 ： https://zhuanlan.zhihu.com/p/30526700

关于负载均衡的一切：总结与思考 ：   https://www.cnblogs.com/xybaby/p/7867735.html

实现Apache,Tomcat负载均衡和集群   ：   https://mp.weixin.qq.com/s/BJHoTzAnbL9YHlI01X-3AA

F5负载均衡上使用iRule 来选择SNAT pool   ：   http://blog.51cto.com/11555417/2082876

F5负载均衡器原理   :  http://blog.51cto.com/11555417/2049183

简单的服务器负载均衡设置介绍  :   http://blog.51cto.com/11555417/2049186

出口规划及F5调整  :  http://blog.51cto.com/11555417/2048527

F5负载均衡配置一例 (型号:BIG-LTM-1600-4G-R)               ：https://blog.csdn.net/qq_35611533/article/details/51917279

CentOS 部署Etcd集群            : http://blog.51cto.com/zlyang/1951164

 

负载均衡 （一） 工作模式以及工作原理  ：  http://blog.51cto.com/xmomo/2177814

 

亿级Web系统搭建：单机到分布式集群  : https://mp.weixin.qq.com/s/xMFWef6IeFDO_3yruZ4zKQ

 

 

 

转载于:https://my.oschina.net/u/3803405/blog/1923271