负载均衡
负载平衡是一种将任务分配到多台计算机的方法。例如，将Web应用程序的HTTP请求（任务）分发到多个Web服务器上。有几种不同的方法来实现负载平衡。在本文中，我将解释一些常见的负载平衡方案。下面是一个说明负载平衡的基本原理的图表：
负载平衡的主要目的是将应用程序的工作负载分配到多台计算机上，因此应用程序可以处理更高的工作负载。负载平衡是扩展应用程序的一种方式。
负载平衡的次要目标通常是（但并非总是）在应用程序中提供容错。也就是说，如果一个服务器集群中的一个服务器失败，负载均衡器可以临时从集群中删除该服务器，并将负载划分到运行的服务器上。有多个服务器以这种方式互相帮助通常被称为“容错”。当错误发生时，任务从故障服务器移动到功能服务器，这通常被称为“故障转移”。
合作运行同一应用程序的一组服务器通常被称为服务器的“集群”。集群的目的通常是上述两个目标：将负载分配到不同的服务器上，并为彼此提供冗余/故障转移。
常用负载均衡方案
最常见的负载平衡方案是：
- 均匀任务分配方案
- 加权任务分配方案
- 粘性会话方案
- 均匀大小任务队列分配方案
- 自主队列方案
下面将更详细地说明这些方案中的每一个。
均匀任务分配方案
均匀任务分配方案意味着任务在集群中的服务器之间均匀分布。因此，该方案非常简单。这使得它更容易实现。偶数任务分配方案也称为“Round Robin”，这意味着服务器以循环方式接收工作（均匀分布）。下面是一个说明任务分配负载平衡的图表：
即使在集群中的服务器都具有相同的容量，并且传入任务统计上需要相同数量的工作时，任务分配负载平衡也是合适的。
即使是任务分配也忽略了处理每个任务所需的工作差异。这意味着，即使每个服务器被赋予相同数量的任务，也可以有一个服务器需要比其他服务器重处理的任务的情况。这可能是由于输入任务的随机性造成的。由于过载服务器可能突然接收到一组轻量级工作负载任务，这一点甚至会随着时间的推移而自行消失。
因此，即使任务分配负载平衡均匀地将任务分配到集群中的服务器上，也可能不会导致工作负载的均匀分布。
基于DNS的负载均衡
基于DNS的负载平衡是一种简单的方案，在配置DNS时，当它们请求您的域名的IP地址时，将不同的IP地址返回给不同的计算机。这实现了类似于均匀任务分配方案的效果，除了大多数计算机缓存IP地址并因此返回到相同的IP地址，直到作出新的DNS查找为止。
虽然基于DNS的负载平衡是可能的，但它不是可靠地跨多个计算机传输业务的最佳方式。最好使用专用的负载平衡软件或硬件。
加权任务分配方案
加权任务分配负载平衡方案使用权重将传入的任务分配到集群中的服务器上。这意味着您可以指定服务器相对于其他服务器接收的任务的权重（比率）。如果集群中的服务器并不都具有相同的容量，这是有用的。
例如，如果三个服务器中的一个只有两个2/3的容量，则可以使用权重3, 3, 2。这意味着第一个服务器应该接收3个任务，第二个服务器3个任务，最后一个服务器只有2个任务，每8个任务被接收。这样，与集群中的其他服务器相比，具有2/3容量的服务器只接收2/3个任务。下面是一个说明这个例子的图表：
如前所述，当集群中的服务器不具有相同的容量时，加权任务分配负载平衡是有用的。然而，加权任务分配仍然不考虑处理任务所需的工作。
粘性会话方案
这两种先前的负载平衡方案是基于任何输入的任务可以独立于先前执行的任务来处理的假设。然而，情况并非总是如此。
想象一下，如果集群中的服务器保持某种会话状态，就像在一个java web应用程序的会话对象（或PHP，或ASP）。如果任务（HTTP请求）到达服务器1，并导致向会话状态写入一些值，如果将来自同一用户的后续请求发送到服务器2或服务器3会发生什么情况？然后该会话值可能丢失，因为它存储在服务器1的内存中。下面是一个说明情况的图表：
这个问题的解决方案称为粘性会话负载平衡。属于同一会话（例如同一用户）的所有任务（例如HTTP请求）被发送到同一服务器。这样，任何后续任务（请求）可能需要的存储会话值都可用。
使用粘性会话负载平衡，不是分配给服务器的任务，而是任务会话。这当然会导致工作量的增加，因为某些会话将包含很少的任务，而其他会话将包含许多任务。
另一种解决方案是完全避免使用会话变量，或者将会话变量存储在数据库或缓存服务器中，可访问集群中的所有服务器。如果可能的话，我更喜欢完全避免会话变量，但是您可能有充分的理由使用会话变量。
避免会话变量的一种方法是使用RIA GUI +架构，该架构可以包含RIA客户端内存中的任何需要的会话范围变量，而不是Web服务器的内存内。
均匀大小任务队列分配方案
均匀任务队列分配方案类似于加权任务分配方案，但又有些不同。而不是盲目地将任务分配到集群中的服务器上，负载均衡器为每个服务器保留一个任务队列。任务队列包含每个服务器当前正在处理的或正在等待处理的所有请求。下面是一个说明这个原理的图表：
当服务器完成任务时，例如已完成向客户端发送HTTP响应时，任务将从该服务器的任务队列中删除。
均匀任务队列分配方案通过确保每个服务器队列同时具有相同数量的任务来工作。具有更高容量的服务器将比低容量服务器更快地完成任务。因此，高容量服务器的任务队列将空得更快，从而更快地具有新任务的空间。
可以想象，这种负载平衡方案隐含地考虑处理每个任务所需的工作和每个服务器的容量。新任务以最少的任务排队发送到服务器。当任务完成时，任务从队列中被清空，这意味着处理任务所花费的时间会自动影响队列的大小。由于完成任务的速度取决于服务器容量，所以服务器容量也会自动考虑。如果服务器临时重载，其任务队列大小将大于群集中其他服务器的任务队列。因此，重载服务器在其队列执行完毕之前不会有新的任务分配给它。
负载平衡器将不得不做更多的考虑使用此方案。它必须跟踪任务队列，并且它必须跟踪任务何时完成，所以它可以从相应的任务队列中移除。
自主队列方案
自主队列负载平衡方案，所有输入的任务都存储在任务队列中。服务器集群中的服务器连接到该队列并获取它们可以处理的任务数量。这里有一个图解说明这个方案：
在这个方案中没有真正的负载均衡器。每个服务器都承担它能够处理的负载。只有任务队列和服务器。如果服务器从群集中掉出来，它的任务在任务队列上不被处理，并且稍后被其他服务器处理。因此，每个服务器自主地运行其他服务器和任务队列。无负载均衡器需要知道服务器是集群的一部分。任务队列不需要知道服务器。每个服务器只需要知道任务队列。
自治队列负载平衡也隐含地考虑了每个服务器的工作负载和容量。服务器只从队列中获取任务，然后它们有能力处理它们。
自主队列与均匀队列大小分布相比有一点缺点。需要任务的服务器需要首先连接到队列，然后下载任务，然后提供响应。这是2到3个网络往返行程（取决于是否需要回送响应）。
均匀队列大小分配方案具有较少的网络往返行程。负载均衡器向服务器发送请求，服务器回送响应（如果需要的话）。这只是1到2次网络往返。