《构建高性能网站》这本书是很多年前读的，但是读的没那么深，时间久了几乎就忘了。如果你最近又看了一遍，不妨做些笔记，以保持良好的记忆力。

一些想法

对于网站的横向扩张，债务平衡是一种常见的手段。除了注重性能，高可用性也会涉及到。

一、针对http重定向的HTTP重定向。你并不陌生，他可以传递http请求，我们在web开发中经常用他来完成自动跳转，比如用户登录后跳转到对应的首页。这种重定向完全由http定义，由http代理和web服务器共同实现。比如http代理(比如浏览器)向web服务器请求一个URL后，web服务器可以通过HTTP响应头信息中的Location标记返回一个新的URL，这意味着HTTP代理需要继续请求这个新的URL，完成自动跳转。正是http重定向具有请求传递和自动跳转的能力，所以它不仅可以满足应用程序所需的各种自动跳转，还可以实现负载均衡，达到web扩展的目的。镜像下载在很多在线站点都有下载功能，大多使用http重定向，镜像下载的目的是为了实现负载均衡。

例如，我们看这个链接:www.php.net/get/php-5.2.9.tar.gz/from/a/mirror

我们在浏览器中访问这个地址，并监控http请求和响应，我们可以在请求头中看到这些

网址:http://cn . PHP . net/get/PHP-5 . 2 . 9 . tar . gz/from/a/mirror

而http的状态码是302。我们刚刚发送到php.net主站点的下载请求被转移到cn.php.net站点，这相当于主站点将部分负载转移到其他服务器。

+接下来，我们再次请求主站点php.net的网址，以查看请求标题信息:

http状态代码是302，

位置:http://cn 2 . PHP . net/get/PHP-5 . 2 . 9 . tar . gz/from/a/mirror

+在php.net这里，主站点负责判断地理来源，选择镜像服务，值得一提。这里的重定向方案不仅实现了负载均衡，还达到了就近访问的目的，加快了用户的下载速度。关注性能和可扩展性。我们在这里提到的性能实际上是针对主站点的，因为它负责将请求传输到其他服务器。主站点决定了整个负载均衡系统的可扩展性，也意味着整个系统的最大承载能力。重定向策略分析:随机策略；

每次请求访问主站点时，程序都会随机选择其中一个服务器，然后返回重定向指令。(更好的性能和轮询策略)轮询策略

*1.主站点为了达到绝对平衡，会将所有请求转移到所有服务器，同时性能成本必然会降低。

*2.Apache的mod_rewrite模块，可以轻松支持注重优劣对比的RR，一般重定向站点的首页，也就是站点入口，而站点内页面的连接地址一般采用首页上的相对地址或者根相对地址，这样一旦用户通过入口转移到实际的服务器，用户的一系列请求就会直接进入实际的服务器。不同的用户对站点中的页面有不同的访问深度，这是我们无法控制的。这样一来，几个实际服务器的负载是不可预测的，但是主站点对此一无所知。更何况，你也不能保证用户总是从站点的首页进入站点，也就是用户会跳过你精心设计的主站点调度器。所以大多数情况下，整个站点的负载均衡都是通过重定向来实现的，并不那么令人满意。虽然他有那么多缺点和性能问题，但在一些场景中，比如文件下载、广告展示等一次性请求，他仍然可以展现出它的优势，主站点调度器可以牢牢把握控制权。这种一次性请求也更容易保持多台服务器的负载平衡。2.域名系统负载平衡

DNS负责提供域名解析服务。当我们访问一个站点时，我们实际上需要通过该站点的DNS服务器获取域名所指向的IP地址。在这个过程中，我们的DNS服务器完成了从域名到IP地址的映射。同样，这种映射可以是一对多的。此时，DNS服务器充当负载平衡调度器(也称为均衡器)

与上述重定向负载均衡相比，基于DNS的负载均衡完全省掉了主站点，或者说DNS服务器充当了主站点。作为调度人员，我们几乎不用担心DNS服务器本身的性能，因为实际上DNS记录是可以被各级用户浏览器或互联网接入服务提供商的DNS服务器缓存的，缓存过期后才会重新请求域名的DNS服务器进行解析。所以即使采用RR调度策略，也很难遇到DNS服务器成为性能瓶颈的问题。另一方面，我们通常配置两个以上的DNS服务器来提高可用性。当我们不必考虑DNS服务器扩展和性能问题时，另一个问题就会暴露出来。怎么管理这么多服务器？比如内容同步、数据共享、状态监控等问题尤为重要，这些都是我们在使用DNS服务器时需要考虑的问题。智能解析虽然基于HTTP重定向的负载均衡系统受到主站点性能的限制，但不可否认，这个方案中的调度策略非常灵活，你可以通过web程序实现任何你想到的调度策略。相比之下，DNS服务器开发自定义的调度策略就没那么容易了，不过好在bind之类的DNS服务器提供了丰富的调度策略供你选择，最常用的是根据用户IP智能解析，也就是说DNS服务器可以在所有可用的A记录中找到最接近用户的服务器。故障转移当一台服务器出现故障时，我们需要立即将其从调度策略中删除，即挂起指向该服务器的DNS记录，以避免用户莫名其妙地访问故障服务器。基于DNS服务器的负载均衡，真的很头疼，因为一个实际问题是我们一般不会将DNS记录的TTL设置为0，这就使得对DNS记录的所有修改都需要一段时间才能生效。比如一个DNS记录的TTL是3600秒，更新需要一个多小时。解决以上问题更好的办法是动态DNS，这其实是DNS协议的一个特性。它允许DNS服务器为我们开发特定的服务并自动远程修改DNS。动态域名解析很简单，就是每次IP地址发生变化，DNS服务器及时更新。当然，一定的延迟还是不可避免的，这也是因为DNS记录的TTL。一些缺点是由DNS记录的缓存导致的更新延迟造成的，这导致我们对调度器的控制与HTTP重定向调度器相比总是跟不上节奏。DNS服务器更像一个魔术师，可以在用户面前很好的隐藏实际的服务器，但同时也给服务器运维人员的调试带来了一些不便。在基于DNS的负载均衡框架下，负载均衡调度器工作在DNS级别，导致其灵活性或多或少被削弱，策略的制定有一定的局限性。三.反向代理负载平衡

反向代理服务器的核心工作是转发HTTP请求，因为它工作在HTTP级别，也就是TCP七层中的应用层(第七层)，所以基于反向代理的负载均衡也称为第七层负载均衡。不难实现。目前几乎所有主流web服务器都热衷于支持基于反向代理的负载均衡。与上述HTTP重定向和DNS解析相比，作为负载均衡调度器的反向代理，HTTP请求的调度体现在-forwarding，而前者是transfer。

单纯区分这些概念并不具备上述含义。你需要理解的是，这种机制的改变使得调度器完全充当了用户和实际服务器之间的中间人，也就是说对实际服务器的任何HTTP请求都必须通过调度器；调度程序必须等待来自实际服务器的HTTP响应，并将其反馈给用户。根据权重分配任务

刚才我们提到，在这种新的调度模式下，任何对实际服务器的HTTP请求都必须经过调度器，这就使得解决长期遭受的问题成为可能，即可以对每一个HTTP请求实施调度策略，从而实现更加可控的负载均衡。

基于“谁能做更多的工作”的原则，一些反向代理服务器可以非常精确的控制分配权重，比如我们经常使用的nginx服务器。

比如我们有两台服务器10.0.12.100 | 10.0.12.201，在另一台IP10.1.0.210服务上运行nginx作为反向代理服务器，也就是负载均衡调度器，配置两台后端服务器，如下:上游后端{服务器10.0.10。服务器10.0.1.201:80权重= 1；} # weight就是设置服务器的权重比，这样我们就可以根据服务器的配置来设置权重比。反转代理服务器本身的并发处理能力尤为重要。扩展限制

前面我们谈到了调度问题和负载权重问题，那么我们还有一个最关心的问题，就是负载均衡系统的扩展能力。反向代理服务器在HTTP级别工作，HTTP请求必须亲自转发。你可能想知道它的能力有多强，能支持多少后端服务器。的确，直接关系到整个服务器的扩展能力。

Image.png从图中分析，当num=100000时，内容处理开销最大，负载均衡系统的整体吞吐量几乎等于两台后端服务器的吞吐量之和。然后当num减少时，整体吞吐量开始落后于两个后端服务器的吞吐量之和。当num=1000时，整体吞吐量甚至没有任何后端服务器高。虽然我们只使用两台后端服务器，但是负载均衡调度的瓶颈已经暴露出来，并且这种瓶颈效应随着后端服务器处理时间的减少而逐渐明显。不难理解反向代理服务器本身需要一定的转发操作费用，比如创建线程、与后端服务器建立TCP连接、接收后端服务器返回的处理结果、分析HTTP头信息、用户控件和内核空间频繁切换等。通常，这部分时间不长，但当后端服务器处理时间很短时，健康检测

下面简单介绍一下清漆的检测器。

冗长的谈话

负载均衡调度器使用户最大程度上不关心后端服务器。我们知道，当采用RR调度策略时，即使同一用户对同一内容的多个请求也可能被转发到不同的后端服务器，这听起来并不严重，但有时可能会带来一些问题:

当后端服务器启用会话来本地保存一些用户数据时，下次用户的请求被转发到其他后端服务器时，以前的会话数据将无法访问。后端服务器实现了一定的动态内容缓存，但是不规则的转发使得这些缓存的利用率降低。

你是如何解决这些问题的？我们需要做的是调整调度策略，让用户在一个会话周期内的所有请求总是被转发到特定的后端服务器。这个机制也叫粘性会话，实现的关键在于如何设计一个持久的调度算法:

既然调度器可以识别用户，那么用用户的IP地址作为识别标志是最合适的，有些反向服务器支持，比如nginx和HAProxy，可以对用户的IP地址进行Hash，然后哈希到不同的后端服务器。Cookies机制也可以用来设计持久化算法。例如，调度器将后端服务器的编号附加到写入用户的Cookies中，这样调度器就可以知道在用户的后续请求中应该转发到哪个服务器。我们希望同一个URL的请求总是被转发到同一个特定的后端服务器，以便充分利用后端服务器的本地缓存来获取这个URL。为了实现这一点，HAProxy也提供支持，我们使用uri策略