到达POP的请求将根据请求URI负载平衡到不同的服务器。
当请求到达POP时，前端服务器将处理请求，并根据请求的URI将请求映射到缓存服务器。 一致的哈希(或者，精确地说，使用CARP缓存阵列路由协议实现的Rendezvous哈希)可确保同一资源始终映射到同一个缓存服务器，只要该服务器运行正常。 这种一致的映射对性能至关重要。 将请求定向到其缓存中没有请求资源的服务器将需要从另一个服务器获取资源，从而增加响应延迟。 重要的是，一致的哈希还可以在POP中的所有缓存服务器之间实现相当统一的资源分配，从而帮助分配工作负载。
但是，不同的资源的受欢迎程度各不相同，而为受欢迎的资源提供服务的服务器最终可能比流行的其他服务器提供更多的流量。 因此，当资源迅速变得非常流行并开始占用服务器网络或CPU资源的相当一部分时，称为热归档的机制就会启动。 热归档可在一个或多个附加服务器上快速复制此资源。 它通知前端复本位于哪些服务器上，从而更广泛地分配资源生成的负载。
还有改进的空间
今天触发热归档的逻辑基于固定的阈值，该阈值可保证单个资源对服务器服务的请求或字节数的处理速率不会超过预定的速率。 如果资源负载超过该阈值，则会进一步分布资源负载。 但是，具有固定阈值的一个挑战是，如果服务器上服务器负载的相当一部分是由刚好低于该阈值的资源生成的，则这些资源将不会被热归档。 因此，不会分发它们各自的请求负载。
因此，我们发现，即使结合基于资源的负载平衡和热归档，POP中服务器之间的负载分布通常也可能不均匀，有些服务器提供的负载超过中位数的2个-3。
在任何给定时间，网络负载分布不均在许多POP中很常见，某些服务器提供的流量比中位数高出2倍。
这种不均匀性并不总是一个问题，因为只要服务器没有达到其容量，它们就可以保持性能。 但是，在极端情况下，影响可能非常明显。 下图说明了这种影响的一个实例。
两台服务器达到或超过其网络容量，而其余的POP流量较低。 离群服务器的运行状况检查明显增加(响应时间)。
在这一特定POP的网络负载分配快照中，当大多数服务器发送的流量较低时，两台服务器提供的负载超过中位数的两倍，由于一个或几个非常受欢迎的资源而达到其容量。 这对他们的健康检查指标有明显的影响，这是他们最短响应时间的代表。 此指标的正常值通常低于1毫秒，超过10毫秒时会发出警报。 在此示例中，运行状况检查增加到100毫秒以上，并持续至少一小时，在此期间过载的服务器可能表现不佳。
我们还观察到几台服务器的负载持续超过其余的POP几天的情况。 在这种情况下，这些加载的服务器对传入流量高峰的适应能力通常低于POP中的其他服务器。 在高峰时段，这种情况会加剧，因为它们的负载可能达到或超过其容量，但在其余流行时段仍有可用容量。
自适应请求负载平衡系统
基于这些观察结果，我们一直在研究使用动态阈值进行热归档的想法。 此方法考虑在 任何给定时间在服务器之间以及每个服务器在该分布中的位置分配负载 。 根据这些条件，特定于服务器的阈值计算为服务器在负载分布中所处位置的函数： 与负载较低的服务器相比，分配给负载高于中位数的服务器的阈值较低，有利于对分布末尾的服务器进行更多的卸载。
服务器阈值是根据每个服务器的当前负载分布位置生成的。 为负载高于中值的服务器分配的阈值低于负载较低的服务器。
更具体地说，我们定义了两个参数来控制热归档的级别:
- BaseThresh 控制每个服务器阈值的基线值。 特定于服务器的阈值从该值派生出来，并根据服务器的当前负载进行调整。
- α ∈(0, 2)控制算法为需要卸载的服务器调整权重的力度。
然后，对于POP中的每个服务器，我们使用以下公式生成权重W (s)∈(0，2)，该权重 与服务器的当前负载成反比：
其中：α∈(0，1) bw是当前服务器负载BWmin 是最低负载服务器的负载BWmin是 最高负载服务器的负载，然后，每个服务器的阈值T的 计算公式为：
在我们的实施中，我们将BaseThreshh配置为适合我们的工作负载的值。 我们让该算法动态选择 α 的值，这样，如果离群值(负载较高)的服务器的负载与中位值相差很远，则会对这些服务器实施更积极的卸载。
使用CDN生产工作负载进行评估
我们使用生产工作负载的快照来评估我们的模拟方法。 要测量POP中服务器负载分布的(变化)偏差，我们定义了”偏差系数”：
换言之，S测量负载最大的服务器距离中位数的距离。 例如，S=2意味着负载最大的服务器提供的负载是中位数的2倍。 理想情况下，我们希望所有服务器都接近中位数，因此S值越低越好(S=1是理论上的最佳值)。 下图显示了S如何根据动态阈值，每次迭代中生成的新热文件数量以及每次迭代中选取的 α 值在热归档过程的多个迭代中发生变化。
数次连续迭代算法后的负载分布。 负载最重的服务器上的负载从中位值的2.73倍减少到中位值的1.42倍，POP内的流量分布更加均匀。
蓝线(“开始”)显示起始状态，表示弹出时负载分布的真实快照。 我们注意到S在每次迭代后会减少，直到到达一个点，不再生成Hot Files (HF)。 随着尾部在每次迭代中被修剪，分布变得更加均匀，越来越多的服务器接近中位负载。
接下来，我们对6个不同的PoP重复相同的实验10次:
倾斜度因子(S)更改6个PoP。 S在5次迭代中收敛，平均下降92%。
图中的每组条形代表一个不同的弹出，而一组中的每一个条形代表一个后续迭代。 每个组中的第一个栏表示从生产工作负载快照中提取的开始状态。 每个条代表10次试验的值。 我们观察到，在所有情况下,S的下降在第一次迭代中比在S达到更多可接受值的任何后续迭代中都更加剧烈。 重要的是，分布的传播(如耳语所示)以及离群值(钻石)也同样减少。 我们观察到负载平衡机制会在少量迭代后收敛，并且只需要在S因新的不平衡流量而变得高时触发。
后续步骤
在POP中跨服务器分配负载对于性能非常重要。 虽然由于资源迅速普及，预计会出现某种程度的不均匀现象，但服务器持续过载(尽管其余流行地区有可用容量)可能会影响其性能和对更多传入流量高峰的恢复能力。 在这项工作中，我们探讨了对现有负载平衡机制的增强，它可以帮助缓解这种负载不均匀。
仿真结果很有希望，因此我们正在将这一变化融入我们的现有机制，并在生产过程中监控结果。 通过测试这种生产方法，我们可以获得更真实的结果，并评估在模拟中难以量化的其他因素。 这些因素包括对高度动态工作负载的恢复能力，一天中的时间影响，资源复制更改以及相关的开销。
