不十分なパフォーマンスをロード・バランシングが必要です
サーバトラフィックの上昇がすると
、
サーバーの回線の帯域幅を増やすことが効果的である
、
ではなく、ネットワークをより速く、あなたがすべての問題を解決することができなりました。
高速ラインは、追いつくために、サーバーのパフォーマンスを引き起こす、ネットワークパケットを大量に転送します
。
特にを通じて
CGI
、動的に生成されるデータやその他のアプリケーションの場合は
、サーバー上の
CPUの
負担重く
、
問題のサーバーのパフォーマンスがより明白に表示されます
。この問題を解決するために、
我々は最初のサーバーを置き換える、より良いパフォーマンスを考えることが
、
多くのユーザーが同時にアクセスに関係なく、サーバーのパフォーマンスが向上する、単一のサーバに頼ったりすることができなかったとき。この場合、複数のサーバを使用すると、負荷、より効率的な方法を配布します。
このアーキテクチャは、負荷分散のためのいくつかの方法がある分散アーキテクチャと呼ばれる、最も簡単な方法は、トラフィックに、各サーバーを削減、複数のWebサーバーを使用することです
。
今、私たちは3台のがあると
サーバを
、
各サーバーのトラフィックが1/3に削減されますので
、
負荷が軽減されます。
このような方法には
、
各クライアントからサーバに送られた割り振り要求するためのメカニズムが存在しなければなりません。
多くの特定の慣行がありますが
、
最も簡単な1は経由で
DNS
サーバーを割り当てます。
サーバーにアクセスする際
、
最初にクライアントのニーズ
のDNS
サーバは、サーバの照会
IPアドレスを、
場合
DNSが
同じレコードに複数のネームサーバを記入し
、
それぞれの時間は、DNSサーバーが異なる順序クエリ返します
のIP
アドレスを
。
たとえば
、
ドメイン名の
www.lab.glasscom.com、我々はそれを次のように割り当てた場合
3
のGe
のIP
アドレスを
。
192.0.2.60
192.0.2.70
192.0.2.80
最初のときに
1
市は、ドメイン名を照会し
、
サーバーには、以下の内容を返します
。
192.0.2.60 192.0.2.70 192.0.2.80
第二のクエリは、ときに、サーバーは以下のものを返します。
192.0.2.60 192.0.2.70 192.0.2.80
ときに最初の
3つの
市クエリ
、
サーバーは以下のものを返します
。
192.0.2.80 192.0.2.60 192.0.2.70
最初の場合
4は、
それが背中の照会するとき
クエリの結果（示されるように）。これは、同じように、このよう缶内のすべてのアクセスサーバに分散、ポーリング（ラウンドロビン）と呼ばれています。しかし、このアプローチは欠陥があります。
1）
複数のWebサーバが故障している場合は、私たちはお返しにIPアドレスが失敗したWebサーバーをスキップすることができますことを願っていますが、通常のDNSサーバー、Webサーバーが正常に動作していることを確認し、その場合でも、Webサーバーが停止しませんマシン、そしてそれはまだ、このサーバーのIPアドレスを返すことがあり
。
2）また、
ポーリングの割り当てにも問題が発生することがあります
。
CGIのなど動的に生成されたWebページの場合、いくつかの複数のページにまたがる操作、この期間中にサーバへのアクセスの場合は変更されている、この操作を続行することができないかもしれません。たとえば、サイトの買物で、最初のページのアドレスと名前に入力することができ、2ページ目であなたのクレジットカード番号を入力し、状況のだけの種類に属しています。
アクセスを割り当てるロードバランサを使用します
为了避免出现前面的问题，可以使用一种叫作负载均衡器的设备。使用负载均衡器时，首先要用负载均衡器的 IP 地址代替 Web 服务器的实际地址注册到 DNS 服务器上。假设有一个域名 www.lab.glasscom.com，我们将这个域名对应的 IP 地址设置为负载均衡器的 IP 地址并注册到 DNS 服务器上。于是，客户端会认为负载均衡器就是一台 Web 服务器，并向其发送请求，然后由负载均衡器来判断将请求转发给哪台 Web 服务器（如图）。
这里的关键点不言而喻，那就是如何判断将请求转发给哪台 Web 服务器
。
判断条件有很多种，
根据操作是否跨多个页面
，
判断条件也会有所不同。
如果操作没有跨多个页面
，
则可以根据
Web
服务器的负载状况来进行判断。
负载均衡器可以定期采集 Web 服务器的 CPU、内存使用率，并根据这些数据判断服务器的负载状况，也可以向 Web 服务器发送测试包，根据响应所需的时间来判断负载状况
。
当然
，
Web
服务器的负载可能会在短时
间内上下波动
，
因此无法非常准确地把握负载状况
，
反过来说，如果过于密集地去查询服务器的负载，这个查询操作本身就会增加 Web 服务器的负载
。
因此也有一种方案是不去查询服务器的负载
，
而是根据事先设置的服务器性能指数，
按比例来分配请求
。
将用户的请求绑定到一台固定的服务上
无论如何
，
这些方法都能够避免负载集中在某一台服务器上。
当操作跨多个页面时，则不考虑 Web 服务器的负载，而是必须将请求发送到同一台 Web 服务器上
。
要实现这一点
，
关键在于我们必须要判断一个操作是否跨了多个页面。
HTTP 的基本工作方式是在发送请求消息之前先建立 TCP 连接，当服务器发送响应消息后断开连接，下次访问 Web 服务器的时候，再重新建立 TCP 连接
。
因此
，
在
Web
服务器看来
，
每一次HTTP 访问都是相互独立的
，
无法判断是否和之前的请求相关
。之所以会这样，
是因为
Web
中使用的
HTTP
协议原本就是这样设计的。
如果要判断请求之间的相关性，就必须在 Web 服务器一端保存相应的信息，这会增加服务器的负担
。
此外
，
Web
服务器最早并不是用来运行CGI 程序的
，
而是主要用来提供静态文件的
，
而静态文件不需要判断请求之间的相关性，
因此最早设计
HTTP
规格的时候
，
就有意省略了请求之间相关性的判断。
那么在不知道请求之间的相关性时，能不能根据一系列请求的发送方IP 地址相同这一点来判断呢？也不行
。
如果使用了我们后面要讲的代理机制
，
所有请求的发送方
IP
地址都会变成代理服务器的
IP
地址
，
无法判断实际发送请求的客户端是哪个。
此外
，
如果使用了地址转换
，
发送方
IP
地址则会变成地址转换设备的 IP
地址
，
也无法判断具体是哪个客户端
。于是，
人们想出了一些方案来判断请求之间的相关性
。
例如
，
可以在发送表单数据时在里面加上用来表示关联的信息，或者是对 HTTP 规格进行扩展，在 HTTP 头部字段中加上用来判断相关性的信息
。
这样
，
负载均衡器就可以通过这些信息来作出判断，
将一系列相关的请求发送到同一台Web 服务器
，
对于不相关的请求则发送到负载较低的服务器了
。
缓存服务器：分担负载
除了使用多台功能相同的
Web
服务器分担负载之外
，
还有另外一种方法，
就是将整个系统按功能分成不同的服务器，如 Web 服务器、数据库服务器。
缓存服务器就是一种按功能来分担负载的方法。缓存服务器是一台通过代理机制对数据进行缓存的服务器
。
代理介于Web 服务器和客户端之间，具有对 Web 服务器访问进行中转的功能
。
当进行中转时，它可以将 Web 服务器返回的数据保存在磁盘中，并可以代替Web 服务器将磁盘中的数据返回给客户端。这种保存的数据称为缓存，缓存服务器指的也就是这样的功能。
Web 服务器需要执行检查网址和访问权限
，
以及在页面上填充数据等内部操作过程，
因此将页面数据返回客户端所需的时间较长
。
相对地，缓存服务器只要将保存在磁盘上的数据读取出来发送给客户端就可以了
，
因此可以比 Web
服务器更快地返回数据
。 不过，
如果在缓存了数据之后
，
Web
服务器更新了数据
，
那么缓存的数据就不能用了，
因此缓存并不是永久可用的
。
此外
，
CGI
程序等产生的页面数据每次都不同，
这些数据也无法缓存
。
无论如何
，
在来自客户端的访问中，
总有一部分访问可以无需经过
Web
服务器
，
而由缓存服务器直接处理。
即便只有这一部分操作通过缓存服务器提高了速度
，整体性能也可
以得到改善
。
此外
，
通过让缓存服务器处理一部分请求
，
也可以减轻
Web
服务器的负担
，
从而缩短
Web
服务器的处理时间
。
缓存服务器通过更新时间管理内容
下面来看一看缓存服务器的工作过程
。
缓存服务器和负载均衡器一样，
需要代替
Web
服务器被注册到
DNS
服务器中
。
然后客户端会向缓存服务器发送 HTTP
请求消息
（
图
（
a
）
①
、
图
（
a
））。
这时
，
缓存服务器会接收请求消息，
这个接收操作和
Web
服务器相同
。
简单来说就是创建用来等待连接的套接字，
当客户端进行连接时执行连接操作
，
然后接收客户端发送的请求消息。
从客户端来看，缓存服务器就相当于 Web 服务器
。
接下来
，
缓存服务器会检查请求消息的内容，
看看请求的数据是否已经保存在缓存中
。 根据是否存在缓存数据，
后面的操作会有所不同
，
现在我们假设不存在缓存数据。
这时
，
缓存服务器会像图
（
b
）
②这样
，
在 HTTP 头部字段中添加一个 Via 字段，表示这个消息经过缓存服务器转发，然后将消息转发给 Web 服务器（图（a）②）
。 在这个过程中，
我们需要判断应该将请求消息转发给哪台
Web
服务器。
如果只有一台
Web
服务器
，
那么情况比较简单
，
只要将
Web
服务器的域名和 IP
地址配置在缓存服务器上
，
让它无条件转发给这台服务器就可以了。
不过
，
如果一台缓存服务器对应多台
Web
服务器就没那么简单了
，需要根据请求消息的内容来判断应该转发给哪台 Web
服务器
。
要实现这个目的有几种方法，
其中比较有代表性的是根据请求消息的
URI
（
图
（
b
）
①
）中的目录名来进行判断。
使用这种方法时
，
我们首先需要在缓存服务器上进行如下设置。
•
当
URI
为
/dir1/
这个目录时
，
转发给
www1.lab.glasscom.com
•
当
URI
为
/dir2/
这个目录时
，
转发给
www2.lab.glasscom.com
缓存服务器会根据上述规则来转发请求消息
，
在这个过程中
，
缓存服务器会以客户端的身份向目标 Web
服务器发送请求消息
。
也就是说
，
它会先创建套接字，
然后连接到
Web
服务器的套接字
，
并发送请求消息
。
从Web 服务器来看，缓存服务器就相当于客户端。
于是
，
缓存服务器会收到来自 Web
服务器的响应消息
（
图
5.5
（
a
）
③
、
图
5.6
（
c
）），
接收消息的过程也是以客户端的身份来完成的。
接下来
，
缓存服务器会在响应消息中加上图
（
d
）
①这样的
Via
头部字段，
它表示这个消息是经过缓存服务器中转的
，
然后缓存服务器会以Web 服务器的身份向客户端发送响应消息
（
图
5.5
（
a
）
④
）。
同时
，
缓存服务器会将响应消息保存到缓存中，
并记录保存的时间
（
图
5.5
（
a
）
④
’）。
这种在客户端和 Web 服务器之间充当中间人的方式就是代理的基本原
理。
在中转消息的过程中
，
缓存服务器还会顺便将页面数据保存下来
，
随着缓存数据的积累，用户访问的数据命中缓存的几率也会提高
。
接下来我
们来看一看命中缓存的情况
。
命中缓存的情况
首先
，
接收客户端的请求消息并检查缓存的过程和刚才是一样的
。
然后
，
如图
5.7
（
a
），
缓存服务器会添加一个 If-Modified-Since 头部字段并将请求转发给 Web 服务器，询问 Web 服务器用户请求的数据是否已经发生变化
。 然后，
Web
服务器会根据
If-Modified-Since
的值与服务器上的页面数据的最后更新时间进行比较，
如果在指定时间内数据没有变化
，
就会返回一个像图 5.7
（
b
）
一样的表示没有变化的响应消息
（
图
5.5
（
b
）
③
）。
这时
，
Web 服务器只要查询一下数据的最后更新时间就好了，比返回页面数据的负担要小一些。而且返回的响应消息也比较短，能相应地减少负担
。
接下
来
，
返回消息到达缓存服务器
，
然后缓存服务器就会知道
Web
服务器上的
数据和本地缓存中的数据是一样的
，
于是就会将缓存的数据返回给客户端
（
图
5.5
（
b
）
④
）。
缓存服务器返回的响应消息的内容和没有命中缓存的情况是一样的
。
此外，
当
Web
服务器上的数据有变化时
，
后面的过程和没有命中缓存的情况是一样的。
Web
服务器会返回最新版本的数据
，
然后缓存服务器加上
Via
字段发送给客户端
，
同时将数据保存在缓存中。
