负载均衡都遵循类似的原则进行工作
最简单的第四层负载平衡的形式是使用循环（round robin）算法。在这个算法中，我们接收每个新来的连接，并将它导向列表中处于首位的后台服务器。当下一个请求到来时，就把它导向下一个后台服务器，依 此类推，直到向每个后台服务器都发送过一个请求。这时，下一个新的请求就发送到第一个后台服务器，并且重复整个过程。负载平衡器层需要的是真实服务器的列 表，还有一个变量，它负责标记最后被使用的服务器，如图9-2所示。
还有其他第四层的调度算法，但它们都遵循类似的原则进行工作，负载均衡利用可用的真实服务器和前一个连接或现有连接的信息。在最少 连接算法中，负载平衡器检查活跃连接（对经NAT处理过的连接，这些活跃连接会流经平衡器），并且将新的请求赋予当前服务请求数目最少的真正的服务器。这 样比循环调度好的地方在于，对于那些正在处理较慢查询的真实服务器给予了一定补偿，避免同时压给它们太多连接。
第四层调度算法也包含定制的度量值，比如检查每台真实服务负载均衡器的负载特定或程序特定的度量值，并且基于这些信息分配新的连接。只要所需查看的内容没有超出第四层的请求分组的内容，就认为它是属于第四层的平衡器。
第七层负载平衡是这个领域中的新来者。第七层负载平衡器检负载均衡测包括第七层的消息，检查HTTP请求自身。这能够查看请求和请 求的标头，并将这些信息纳入平衡策略的考虑中。因此在平衡请求时，可以基于查询字符串中含有的信息、cookie中的信息或任何标头中的信息，当然也可以 用第四层的信息，包括源地址和目标地址。
最常用于第七层平衡的是HTTP请求自己。基于URL平衡，可以确保对某个特定资源的所有请求都被调度到同一台服务器上。
要实现这种方式，可以一直保留一个hash表，或者使用简单的索引。采用hash表方式，在表中为每个被请求的URL创建 一个条目。当出现hash表中没有的URL请求时，就为它选择一台服务器，并且把这个选择作为hash的值存放在hash表中。有后续的相同URL的请求 时，会查看hash表，并且找到相应的服务器。
简单的 索引方式，是对URL执行某种hash算法或者CRC算法，负载均衡从而从URL中导出一个数字。如果为每台真实的服务器分配一个数字，比如说1到5，那么接着要 做的就是把得到的数字去模拟服务器的数目，再加一，就得到了这个URL映射到的真实的服务器。如果所使用的hash函数能够以相当均匀的分布来分发 URL，那么就能在每台服务器上分布相同数目的URL。如果某台服务器不可用，则需要有某种公式去重新计算一个hash值，它会映射到余下的真实服务器中 的某一台。比如说URL/foo.txt一般映射到4号服务器，但4号服务器不可用，那么就执行更进一步的hash计算，并且最终决定将它映射到2号。
所有后续的相同URL的请求都会采用相同的算法，并且URL会被调度到同一台服务器，当4号服务器重新可用之后，对/foo.txt这个URL的请求又被导向这台服务器。这种方式可以避免在负载平衡器上保留一个hash表，这意味着我们不需要很多内存或磁盘空间。一个轻微的缺陷在于，如果4号服务器发生颠簸，请求会在4号和2号服务器之间切换，而不是持续发送给某一台服务器。
相关信息