读到一篇关于服务器负载均衡(server Load Balancing)的介绍好文，原文还有动图，本文只做简单的笔记记录一下。

Load Balancing

当只有一台服务器时，每次处理完一个请求，才能处理下一个，所以请求同时到来的话，可能会出现请求丢失的情况。不过对于大部分网站而言，这样还是够用的。

但当请求速率 (RPS，Requests Per Second，总请求数/总处理时间) 增加后，即一瞬间来了很多的请求，那么请求丢失的情况就会变得很频繁(开发者一般会进行限流、服务降级的操作)。

为了更好地应对海量的请求(requests)，很多 web 应用会部署到多个服务器(servers)。

其中一种最简单的方式，是轮流地把请求发送到每个服务器，这种方式称为 “round robin” 负载均衡。理想情况下，每台服务器都性能良好，而每个请求的消耗(处理时间等) 都一致，那么这种方式会运转得挺好的。

但是现实是，每台服务器的性能不一样，每个请求也不一样，导致一些请求的处理会过长，没法去处理下一个又轮流到自己的请求，同样会出现请求丢失的情况。

一种解决方式是使用请求队列(request queue) 缓冲一下。

但同样无法完全解决问题，因为请求本身对服务资源的消耗是不一致的，一旦某台服务器堆积过多请求，也会需要丢弃一些请求。

这实际上是一种不平衡，因为性能比较强大的服务器，可能很快又回到了空闲状态。

我们可以给每台服务器，人为定义一个变量，代表权重，意味着可以有多少请求发送给它处理，这种方式称为 “weighted round robin”。但实际操作中，人为定义，并不会带来优化，而且把服务器性能定义为一个变量是很难的，需要进行很多的测试。

所以需要引入动态设置，使用时延(latency、延迟) 作为衡量指标，即如果服务器 A 处理请求，比 B 快 3 倍，那么 A 就应该处理 3 倍多的请求数量。这种方式称为 “dynamic weighted round robin”。

上面这种方式，可以有不错的表现效果，不过通过一个简单的算法，可以继续优化。这种算法是 “least connections” 负载均衡。因为负载均衡控制器，是在服务器和用户之间的一道桥梁，所以它能准确了解到服务器处理的情况，对于负担比较轻的，可以提高它的处理优先级。

虽然还是很难保证不会出现丢失请求的情况，但这种方式可以保证请求处理，处于一个良好的状态下。

而把 “dynamic weighted round robin” 和 “least connections” 结合在一起的算法，称为 “peak exponentially weighted moving average” (PEWMA)。使用这种算法，对于每个服务器，它会追踪最近 N 个请求的处理时延情况，但并不是直接求平均值，而是用指数递减因子来求和，越晚(越近) 的请求，它的权重就越高。然后会把这个值，乘以服务器自己的连接数，最后结果就是我们用来衡量的指标，越低越好(因为计算的是时延)。

不过由于用时延为指标，可能会导致一些服务器空转。但 PEWMA 算法其实有很多可配置的参数，这里只是简单描述下它的做法。

参考