首页大数据技术文章正文

云计算大数据：构建高性能Web站点

更新时间:2017年12月19日15时18分来源:传智播客浏览次数:

交流目标：

1、熟悉网站演进过程中的各个阶段及技术方案(重要)

2、熟悉大型网站中缓存的应用

3、熟悉常见负载均衡的手段

4、熟悉内存数据库Redis

http://item.jd.com/1027067140.html

http://item.jd.com/11449803.html

大型网站及其架构的演进过程

1、什么是大型网站

访问量大、数据量大、业务复杂度高、分布式

网站是用来访问的，访问量大就应该是大型网站?!

大量的数据，或者说海量数据。从数据中分析业务和系统的复杂性。

总结：

那么要支持海量的数据和非常高的并发量，那么他可能是一个分布式系统。

2、网站的架构演进

2.1、构建网站技术手段

发布一个网站需要哪些要素?

一个物理机、一个WEB容器、一个数据库

开发网站的技术手段?

SpringMVC/Spring/Ibatis/JDBC/Mysql

2.2、业务系统-电商网站

l 各个功能模块通过JVM内部方法调用来进行交付

l 访问数据库通过JDBC的方式链接

2.3、单机负载告警、数据库与应用分离

l 随着业务量的发展，单台物理机不能支撑。

l 重新购置一台物理机，将数据库服务器迁移出去。

2.4、应用服务器负载告警、如何让应用服务器走向集群

l 应用服务器压力变大，从一台变成两台。

l 他们都依赖底层数据库对外提供服务。

l 应用负载均衡一般使用Nginx或者apache

问题：

1、用户的请求应该打在哪台应用服务器上?(负载均衡服务)

2、 Sesssion共享的问题

解决：

1、什么是session?

在会话开始时，HTTP协议的会话机制分配一个唯一的会话标志(SessionId)，通过Cookie把这个标志告诉浏览器，以后每次请求的时候浏览器都会带上这个标志来告诉Web服务器请求是属于哪个会话的。(比如保持登陆状态、购物车数据)

2、为什么有session共享的问题?

用户通过负载均衡的方式，随机访问到服务器A，sessionId就会创建到A服务器上，如果不做处理就不能保证接下来的每次请求都落在A服务器上。

方法一：让同样的seesionId每次都打在一台服务器上。(宕机怎么办?)

方法二：session replication 共享

方法三：使用cookies保存session中的信息

2.5、数据库压力变大、读写分离

l 写操作主要走主库，事物中的查询也要走主库。

l 搜索引擎也是一个读库

1、搜索一个商品的名称，like

2、根据被搜索的数据来创建索引(被搜索的数据变化时，索引也变化)

搜索引擎提供了站内搜索的某些场景读的问题，提供了更好的查询效果。

2.6、弥补关系型数据库的不足，引入分布式存储系统(Redis)

分布式文件系统、分布式Key-Value系统和分布式数据库

2.7、读写分离后数据库又遇到瓶颈

数据拆分有两种方式，一个是垂直拆分，一个是水平拆分。垂直拆分就是把一个数据库中不同业务单的数据分到不同的数据库里面，水平拆分是根据一定的规则把同一业务单元的数据拆分到多个数据库中。

2.7.1、专库专用，垂直拆分

垂直拆分带来的影响：

l 一些join操作会变得比较困难，因为数据可能已经在两个数据库中了。

需要应用或者其他方案解决

2.7.2、表中的数据量比较大，水平拆分

水平拆分带来的影响：

l 访问用户信息的应用系统需要解决sql路由的问题

l 主键的处理也会不同，不能依靠数据库的自增长序列了

l 查询分页的问题

l 包含垂直拆分的影响

2.8、分库分表之后，应用面对新的挑战-服务化

前面所讲的读写分离、分布式存储、数据分库分表都是在解决数据方面的问题。

随着应用的的发展，应用的功能会越来越多，应用越来越大。我们需要考虑不让应用持续变大，就需要把应用拆开。

将应用拆分开来。

1、按照业务的特性把应用拆分，(用户系统、商品系统，订单系统)

2、按照功能进行拆分，(用户注册系统、用户登陆系统、用户信息系统、商品展示系统、商品管理系统……)

服务化之后，涉及到应用与应用之间的通信。即进程与进程间的通信。

远程过程调用(RPC、Netty等)

3、分布式网站介绍

3.1、分布式网站的整体结构

在分布式网站中，我们会将web服务器和数据库服务器做整体的规划，并非采用某一台机器做web服务器或者数据库服务器，而是采用集群的架构。

3.2、分布式网站中的服务化框架

在分布式网站中，会出现很多为了负载均衡和failover做支持而出现的框架，还有为项目解耦而出现的大量的RPC框架，例如做主备的keepalived、做反向代理的nginx、做负载均衡的lvs、做RPC的dubbo、netty、thrift等等。

Nginx是一个自由、开源、高性能及轻量级的HTTP服务器及反转代理服务器。Nginx以其高性能、稳定、功能丰富、配置简单及占用系统资源少而著称。

Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多.

Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。

LVS的英文全称是Linux Virtual Server，即Linux虚拟服务器。

这些框架会在接下来的学习中一一涉猎。

RPC(Remote Procedure Call Protocol)：远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

3.3、分布式网站中的消息机制

在分布式的网站中，消息机制不可或缺，消息机制的出现不仅为项目的解耦做了不可磨灭的共现，也为消息的传递提供了另一种解决途径。

在常用的消息机制中，ActiveMQ，RabbitMQ等简单的基于JMS规范的消息机制被广泛应用，而最近几年，一种非JMS的消息机制也在互联网市场上崛起，名为kafka。

kafka在互联网中最为一种非JMS规范的消息机制，应用越来越广，此外，在大数据的生态圈里，kafka也有一席之地。kafka和flume、storm的结合是时下最流行的流式计算框架之一。

缓存篇

为什么要缓存?

减少数据库访问(减少文件IO操作)

1.1、动态内容缓存

动态内容缓存

将动态内容的HTML输出结果缓存起来(页面缓存)，在随后的一段时间内，当有用户访问时变跳过重复的动态内容计算而直接输出。

缓存信息可以保存在文件系统中，也可以保存在内存中。

需要寻找和判断是否过期。需要更新缓存。

动态内容缓存技术 CSI,SSI,ESI介绍 http://my.oschina.net/coldlemon/blog/341269

动态内容静态化

动态内容缓存，虽然可以避免重复的计算，但是每次还需要调用动态脚本的解释器来判断缓存是否过期以及如何读取缓存，消耗了不少时间。

直接将内容生成HTML文件，做成静态页面，返回给浏览器。

不是所有的内容都能做成HTML,该技术主要使用在CMS等内容管理系统上。

局部缓存

对页面静态资源生成HTML，动态内容使用异步加载(ajax)的技术。

目前该技术使用在主流的电商网站中。

1.2、浏览器缓存

对于一些CSS样式、图片、脚本等静态资源，告知浏览器缓存起来，不要重复请求。

浏览器一般会在用户的文件系统中创建一个目录，用户存放缓存文件，并给每个缓存文件上一些必要的标记，比如过期时间等。

IE保存在磁盘，火狐在使用磁盘的同时也使用了内存，将命中率较高的缓存内容保存在内存。

浏览器缓存原理

1、当浏览器向Web服务器请求一些内容是，Web服务器需要告诉浏览器哪些内容可以被缓存。

2、浏览器将可以被缓存的内容缓存起来。

3、当下次请求内容时，浏览器不会直接请求内容，而是询问Web服务器是否需要更新本地缓存。

4、 Web服务器做出应答，是否需要更新，如需要更新就将最新的内容返回。

如何标记哪些内容可以被缓存?

1、在HTTP响应都中增加last-modified关键词即可。

2、浏览器发送请求是，携带：If-modied-sine: {时间}

3、Web服务器检查文件最后修改的时间，特别是静态文件，只需要判断两个时间是否一致。如果没有修改携带：HTTP/1.1 304 Not Modified

304意味着没有修改。

另一种方法：(ETag)

1、由服务器端为文件生成一个标识号，放在HTTP响应头中

ETag：“744177-b-21aa21cd232ee34”

2、浏览器在下次请求的时候，携带ETag

If –node-match: 744177-b-21aa21cd232ee34

3、 Web服务器重新计算文件的ETAG，然后与接受到的ETG比较。如果同，及返回304，不同就返回新的内容。

有没有最优解?

直接给文件标记Expires,是否过期。

对于静态内容，Web服务器默认情况下回开启Expires标记，浏览器不需要重复请求。

谷歌日历的CSS样式表设置的expires 为1年，js脚本设置为1个月。

Http://www.baidu.com/css/1.css?v=2

Apache服务器如何设置js css 图片等在本地缓存

配置文件中打开过期扩展#LoadModule expires_module modules/mod_expires.so

在.htaccess中加入ExpiresActive On ExpiresDefault "access plus 30 days"

1.3、 Web服务器缓存

缓存URL映射

将url地址转换成资源路径

www.baidu.com/12306.html à /data/www/12306.html

经rewrite重写的地址指向对应的静态资源路径

www.baidu.com/12306.html à /data/www/product/12306.html

经rewrite重写的地址指向对应的动态资源地址

www.baidu.com/12306.html à www.baidu.com/?prodcutId=12306

缓存URL 重写到Real Server的真实地址

www.baidu.com/12306.html à www.back-end.com/?prodcutId=12306

缓存响应内容

缓存静态文件

缓存变更较小的动态资源

缓存有效期控制，和HTTP缓存一样的逻辑。设置expire即可。

缓存存放在哪里?开启磁盘缓存或者内存缓存。

缓存文件描述符

大量静态的小文件，需要打开。每个文件占用一个文件描述符。

可以将文件描述符缓存在内存中，当需要访问这个文件时，直接对应到文件描述符。

Apache中关于页面缓存的设置

http://www.cnblogs.com/yyyyy5101/articles/1899350.html

1.4、反向代理缓存

正向代理：

用户主动使用代理服务，服务器不知道用户在哪里。Web服务器只知道代理服务器或者网关发来的请求，并不知道幕后还存在操作者

反向代理：

反向代理服务器的特点与正向代理正好相反，Web服务器隐藏在代理服务器之后。

反向代理的特点

调度器扮演的是用户和实际服务器中间人的角色：

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

2、调度器必须等待实际服务器的HTTP响应，并将它反馈给用户

内容缓存

正向代理服务器可以设置缓存，比如一个机构内部网络通过代理上网，一旦某个用户访问的网页被缓存在代理服务器，内部往来的其他用户就可以快速的获得这个网页。

反向代理服务器同样可以缓存内容，所有的缓存机制使用仍然是使用HTTP/1.1协议。和WEB服务器缓存、浏览器缓存一样。在选用反向代理服务器配置即可。

详见Nginx反向代理的配置一项。

1.5、应用逻辑缓存

将动态内容中访问数据库的操作，提取到内存数据库中，比如Redis，减少数据库访问的次数，即减少文件IO操作。

实际的操作中，可以将用户基础信息、商品的基础信息、收货地址、购物车数据、历史购买记录，保存在Redis中。

将大字段保存在Mongodb(分布式文档存储数据库)。

是我们能够自定义的，详见Redis数据结构及案例分享

1.6、数据库查询缓存

当你的数据库打开了Query Cache(简称QC)功能后，数据库在执行SELECT语句时，会将查询结果放到QC中，当下一次处理同样的SELECT请求时，数据库就会从QC取得结果，而不需要去数据表中查询。

mysql的cache功能的key的生成原理是：把select语句按照一定的hash规则生成唯一的key，select的结果生成value，即 key=>value。

注意，所以对于cache而言，select语句是区分大小写的，也区分空格的。两个select语句必须完完全全一致，才能够获取到同一个cache。

生成cache之后，只要该select中涉及到的table有任何的数据变动(insert，update，delete操作等),相关的所有cache都会被删除。

因此只有数据很少变动的table，引入mysql 的cache才较有意义

1.7、前端优化

1、设计更加简单的网页，时期包含较少的图片和脚本，牺牲美观和交互

2、将多个图片合并为一个文件，使用CSS背景偏移的技术呈现

3、合并JavaScript脚本或者CSS样式表，减少浏览器下载次数

4、充分利用HTTP中的浏览器Cache策略，减少重复下载。

5、将网站资源分布在多个域名之下，增加浏览器的并发下载。

默认情况下，浏览器对一个域名下的资源下载有并发数据限制，从2-6不等。

通过将css样式，图片，js代码放在不同的域名下，可以增加并发。

负载均衡篇

2.1、Web负载均衡

不能狭义地理解为分配给所有实际服务器一样多的工作量，因为多台服务器的承载能力各不相同，这可能体现在硬件配置、网络带宽的差异，也可能因为某台服务器身兼多职，我们所说的“均衡”，也就是希望所有服务器都不要过载，并且能够最大程序地发挥作用。

接口人故事

公司有团队，各尽其能，工作量增加，外包。

外包接口人管理，接口人休假任务无法沟通，单点故障。助理。

接口人工作量分配，有的外包公司任务多，任务少，能力差，能力强。(负载均衡)

2.1.1、HTTP重定向

Http重定向，它可以将HTTP请求进行转移，在Web开发中我们经常会用它来完成自动跳转，比如用户登陆成功后跳转到相应的管理页面。

这种重定向完全由HTTP定义，并且由HTTP代理和Web服务器共同实现。原理如下：

1、当HTTP代理(浏览器)向Web服务器请求某个URL后，Web服务器可以通过HTTP的响应头信息中的location标记来返回一个新的URL

2、 HTTP代理(浏览器)接收到响应头中的location标记，会接着请求location中URL，便完成了自动跳转。

案例展示：

http://www.php.net/downloads.php

http://php.net/get/php-7.0.2.tar.bz2/from/a/mirror

除了按照地域就近分配外，还可以使用轮询(Round Robin)的方式请求方式打到不同的域名上，还以使用随机分配等策略。

随着吞吐率的增加，随机调度也会逐渐趋近于顺序调度的均衡效果。

结论：

不同用户对站点内页的访问深度是不同的，也是我们无法控制的，如此，多台实际服务器的实际负载差异是不可预料的，而主站点却对此一无所知。

所以，在大多数情况下通过重定向来实现整个站点的负载均衡并不那么让人满意。但对于文件下载、广告展示等一次性的请求，主站点调度程序可以牢牢把握控制，实际服务器的URL甚至可以含蓄的隐藏起来。

在实际的的使用中，对于不同的应用场景，我们仍然需要认真考虑基于重定向的负载均衡是否适用，权衡转移请求的开销和实际请求的开销，前者的开销越小，越有意义。

2.1.2、DNS负载均衡

我们知道DNS负责提供域名解析，当我们访问某个站点时，实际上需要通过该站点的域名的DNS服务器来获取域名指定的IP地址，这一过程中，DNS服务器完成了域名到IP地址的映射，这种映射也是一对多的。

这时候，DNS便充当了负载均衡调度器，如同HTTP的请求一样，起到了重定转移策略。

多个A记录

在DNS的各种记录类型中，A记录用来指定域名对应的IP地址。

常见的比较成熟的DNS系统如linux的bind，windows的DNS服务都支持一个域名指定多个IP地址，并且可以选择使用各种调度策略，常见的便是RR(Round Robin)方式。

下图中百度使用的最近地域(根据用户的IP地址智能解析)

在linux下使用命令： dig baidu.com

一般情况下，可以给域名绑定多个A记录，在实际的使用中，建议如下配置：先为每个域名配置多个CNAME,然后给CNAME指定的域名配置A记录。这样至少能兼顾两个问题：

1、老用户如果收藏了你的www1.baidu.com的域名，还能继续提供服务。

2、当你拥有很多DNS记录时，这样做更容易维护。比如，你希望多个二级域名都指向同一个IP地址，那么你只需要添加一个别名来代替IP地址，随后当你需要修改IP地址，只需要修改别名的IP地址即可。

结论：

DNS负载均衡的实现主要依赖DNS服务器的设置，如果你的站点拥有自己的DNS服务器，那么以上设置对于DNS管理员来说，并不困难，但是，大多数站点仍然使用第三方DNS服务商，幸运的是，现在有很多DNS服务商完全支持多个A记录的轮询设置，我们可以根据需要设置。

对比HTTP重定向

和前面HTTP重定向相比，基于DNS的方案完全节省了所谓的主站点，或者说DNS服务器已经充当了主站点的职责。

不过，尽管基于HTTP重定向的负载均衡系统受到主站点性能的制约，但是不可否认重定向的方案中的调度策略具有非常好的灵活性，完全可以通过Web应用程序实现任务和你能想到的调度策略。

相比之下，为DNS服务器让开发自定义的调度策略就不是那么容易了，但幸运的是，类似linux bind这样的DNS服务软件提供了丰富的调度策略供你选择，其中最常用的就是根据用户IP来进行只能解析(上文中的百度就是如此)，这意味着DNS服务器可以再所有可用的A记录中寻找用户最近的一台服务器。

如何利用这种策略，完全取决于业务的状况，可以为用户比较集中的的一些城市提供专用的服务器，接入城市核心节点。也可以为为各互联网运营商网络中的用户提供专用的服务器(联通的归联通，电信的归电信)，并接入运营商骨干网络。

2.1.3、反向代理负载均衡

几乎所有主流的Web服务器都热衷于支持基于反向代理的负载均衡。它的核心工作就是转发HTTP请求。

相比前面的HTTP重定向和DNS解析，反向代理的调度器扮演的是用户和实际服务器中间人的角色：

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

2、调度器必须等待实际服务器的HTTP响应，并将它反馈给用户

特性：

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

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

3、反向代理服务器进行转发操作本身是需要一定开销的，比如创建线程、与后端服务器建立TCP连接、接收后端服务器返回的处理结果、分析HTTP头部信息、用户空间和内核空间的频繁切换等，虽然这部分时间并不长，但是当后端服务器处理请求的时间非常短时，转发的开销就显得尤为突出。例如请求静态文件，更适合使用前面介绍的基于DNS的负载均衡方式。

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

5、反射代理服务器可以让用户在一次会话周期内的所有请求始终转发到一台特定的后端服务器上(粘滞会话)，这样的好处一是保持session的本地访问，二是防止后端服务器的动态内存缓存的资源浪费

2.1.4、IP负载均衡

因为反向代理服务器工作在HTTP层，其本身的开销就已经严重制约了可扩展性，从而也限制了它的性能极限。那能否在HTTP层面以下实现负载均衡呢?

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

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

总结：

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

使用策略：

一个简单有效的办法就是将基于NAT的集群和前面的DNS混合使用，比如5个100Mbps出口宽带的集群，然后通过DNS来将用户请求均衡地指向这些集群，同时，你还可以利用DNS智能解析实现地域就近访问。这样的配置对于大多数业务是足够了，但是对于提供下载或视频等服务的大规模站点，NAT服务器还是不够出色

2.1.5、直接路由

NAT是工作在网络分层模型的传输层(第四层)，而直接路由是工作在数据链路层(第二层)，貌似更屌些。它通过修改数据包的目标MAC地址(没有修改目标IP)，将数据包转发到实际服务器上，不同的是，实际服务器的响应数据包将直接发送给客户端，而不经过调度器。

2.1.6、IP隧道

基于IP隧道的请求转发机制：将调度器收到的IP数据包封装在一个新的IP数据包中，转交给实际服务器，然后实际服务器的响应数据包可以直接到达用户端。目前Linux大多支持，可以用LVS来实现，称为LVS-TUN，与LVS-DR不同的是，实际服务器可以和调度器不在同一个WANt网段，调度器通过 IP隧道技术来转发请求到实际服务器，所以实际服务器也必须拥有合法的IP地址。

总体来说，LVS-DR和LVS-TUN都适合响应和请求不对称的Web服务器，如何从它们中做出选择，取决于你的网络部署需要，因为LVS-TUN可以将实际服务器根据需要部署在不同的地域，并且根据就近访问的原则来转移请求，所以有类似这种需求的，就应该选择LVS-TUN。

2.1.7、负载均衡总结

l HTTP重定向负载均衡，通过HTTP协议进行转发，常用的技术点是一次性下载。分配策略自己定义。

l DNS负载均衡，通过DNS服务器对域名进行解析，按照一定的分配策略进行分配，如就近分配和轮询分配。灵活性没有HTTP重定向负载均衡高。

l 反向代理负载均衡，是通过一组基于Web服务器与用户之间的服务器来进行的，可以配置静态和动态两种策略方式来实现负载均衡。一般会遇到黏滞会话的问题，需要考虑是否通过实现黏滞会话来迁就系统的特殊需求，可以考虑使用cookie、分布式session、分布式缓存的技术手段，让后端服务器的应用尽量与本地无关。

l IP负载均衡(DNAT端口映射)，通过修改数据包请求转发的IP地址，避免网络数据包进入用户进程，直接在Linux内核阶段就转发到实际服务器上。收到时候服务的反馈之后，再修改返回数据包的的IP地址将返回数据包执行用户的真正请求。常见的技术手段是Linux内核模块NetFilter。常用的框架就是LVS，LVS不仅可以用来做IP负载均衡，还可以使用用来做直接路由和IP隧道。

l 直接路由，通过修改数据包的目标MAC地址，将实际服务器的响应数据包将直接发送给用户端，而不经过调度器。在LVS框架中叫做LVS-DR。直接路由是基于IP别名的实现。

l IP隧道(IP Tunneling),简单的说，它价格调度器收到的IP数据包封装在一个新的IP数据包中，转交给实际服务器，然后实际服务器的响应数据包可以直接到达客户端。

2.1.8、负载均衡策略总结

1、轮循均衡(Round Robin)：每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

2、权重轮循均衡(Weighted Round Robin)：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是3，C的权值是6，则服务器A、B、C将分别接受到10%、30%、60%的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。

3、随机均衡(Random)：把来自网络的请求随机分配给内部中的多个服务器。

4、权重随机均衡(Weighted Random)：此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

5、响应速度均衡(Response Time)：负载均衡设备对内部各服务器发出一个探测请求(例如Ping)，然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快响应时间。

6、最少连接数均衡(Least Connection)：客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。

7、处理能力均衡：此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成)最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层(应用层)负载均衡的情况下。

8、DNS响应均衡(Flash DNS)：在Internet上，无论是HTTP、FTP或是其它的服务请求，客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的IP地址(即与此负载均衡设备在同一位地理位置的服务器的IP地址)并返回给客户端，则客户端将以最先收到的域名解析IP地址来继续请求服务，而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下，对本地负载均衡是没有意义的。

服务故障的检测方式和能力：

1、Ping侦测：通过ping的方式检测服务器及网络系统状况，此种方式简单快速，但只能大致检测出网络及服务器上的操作系统是否正常，对服务器上的应用服务检测就无能为力了。

2、TCP Open侦测：每个服务都会开放某个通过TCP连接，检测服务器上某个TCP端口(如Telnet的23口，HTTP的80口等)是否开放来判断服务是否正常。

3、HTT PURL侦测：比如向HTTP服务器发出一个对main.html文件的访问请求，如果收到错误信息，则认为服务器出现故障。

2.2、LVS负载均衡

2.2.1、LVS是什么

1、LVS的英文全称是Linux Virtual Server，即Linux虚拟服务器。

2、它是我们国家的章文嵩博士的一个开源项目。

2.2.2、LVS能干什么

1、 LVS主要用于多服务器的负载均衡。

2、它工作在网络层，可以实现高性能，高可用的服务器集群技术。

3、它可把许多低性能的服务器组合在一起形成一个超级服务器。

4、它配置非常简单，且有多种负载均衡的方法。

5、它稳定可靠，即使在集群的服务器中某台服务器无法正常工作，也不影响整体效果。

6、可扩展性也非常好。

2.2.3、Nginx和lvs作对比的结果

1、nginx工作在网络的应用层，主要做反向代理;lvs工作在网络层，主要做负载均衡。Nginx也同样能承受很高负载且稳定，但负载度和稳定度不及lvs。

2、nginx对网络的依赖较小，lvs就比较依赖于网络环境。

3、在使用上，一般最前端所采取的策略应是lvs。 nginx可作为lvs节点机器使用。

2.2.4、负载均衡机制

前面我们说了LVS是工作在网络层。相对于其它负载均衡的解决办法，它的效率是非常高的。LVS的通过控制IP来实现负载均衡。IPVS是其具体的实现模块。IPVS的主要作用：安装在Director Server上面，在Director Server虚拟一个对外访问的IP(VIP)。用户访问VIP，到达Director Server，Director Server根据一定的规则选择一个Real Server，处理完成后然后返回给客户端数据。这些步骤产生了一些具体的问题，比如如何选择具体的Real Server，Real Server如果返回给客户端数据等等。IPVS为此有三种机制：

1. VS/NAT(Virtual Server via Network Address Translation)，即网络地址翻转技术实现虚拟服务器。

当请求来到时，Diretor server上处理的程序将数据报文中的目标地址(即虚拟IP地址)改成具体的某台Real Server,端口也改成Real Server的端口，然后把报文发给Real Server。Real Server处理完数据后，需要返回给Diretor Server，然后Diretor server将数据包中的源地址和源端口改成VIP的地址和端口，最后把数据发送出去。由此可以看出，用户的请求和返回都要经过Diretor Server，如果数据过多，Diretor Server肯定会不堪重负。

2. VS/TUN(Virtual Server via IP Tunneling),即IP隧道技术实现虚拟服务器。

IP隧道(IP tunneling)是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。它跟VS/NAT基本一样，但是Real server是直接返回数据给客户端，不需要经过Diretor server,这大大降低了Diretor server的压力。

3. VS/DR(Virtual Server via Direct Routing)，即用直接路由技术实现虚拟服务器。

跟前面两种方式，它的报文转发方法有所不同，VS/DR通过改写请求报文的MAC地址，将请求发送到Real Server，而Real Server将响应直接返回给客户，免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最高最好的，但是必须要求Director Server与Real Server都有一块网卡连在同一物理网段上。