需求分析
互联网服务往往要处理来自全世界的流量，但是，一个服务器只能够同时服务有限数量的请求。因此，通常我们会有一个服务器集群来共同处理这些流量。那么问题来了，怎样才能够让这些流量均匀地分布到不同的服务器上呢？
从用户到服务器，会经过很多的节点和不同层级的负载均衡器。具体来讲，我们这次设计的需求是：
- 设计第7层的负载均衡器，位于数据中心的内部。
- 利用来自后端实时的负载信息。
- 服务每秒千万级的流量以及10 TB每秒级别的吞吐量。
补充：如果服务 A 依赖服务 B，那我们称 A 是 B 的下游服务，而 B 是 A 的上游服务。
挑战
为什么负载均衡会很难做？答案是很难收集准确的负载分布数据。
按照数量分布 ≠ 按照负载分布
最简单的做法是根据请求的数量，随机地或者循环地分布流量。然而，实际的负载并不是根据请求的数量来算的，比如有些请求很重很耗CPU，有些请求很轻量级。
为了更加准确地衡量负载，负载均衡器得保持一些本地状态 —— 比如，存当前的请求数、连接数、请求处理的延迟。基于这些状态，我们能够使用相应的负载均衡的算法 —— 最少连接、最少延迟、随机 N 取一。
最少连接：请求会被导向当前连接数最小的服务器。
最少延迟：请求会被导向最少平均反应时长且最少连接数的服务器。还可以给服务器加权重。
随机 N 取一 （N 通常是 2，所以我们也可以称之为二选一的力量）：随机的选两个服务器，取两者之中最好的，能够避免最坏的情况。
分布式的环境
在分布式的环境中，本地的负载均衡器难移了解上下游服务完整的状态，包括
- 上游服务的负载
- 上游服务可能超级大，因此很难选择一个合适的子集接入负载均衡器
- 下游服务的负载
- 不同种类的请求的具体处理时间很难预测
解决方案
有三种方案能够准确地搜集负载的具体情况并相应地处理：
- 中心化的一个均衡器，根据情况动态地处理
- 分布式但是各个均衡器之间要共享状态
- 服务器返回请求的时候捎带上负载信息，或者是均衡器主动询问服务器
Dropbox 在做 Bandai 的时候选择了第三种方案，因为这很好地适应了现行的随机 N 选一的算法。
然而，与原配的随机 N 选一的算法所不同的是，不是使用本地的状态，而是选择服务器实时返回的结果。
服务器使用率：后端服务器设置了最大负载，数当前的连接，然后计算出使用率，范围是从 0.0 到 1.0.
有两个问题需要考虑：
- 处理错误: 如果 fail fast ，由于处理得很快，反而会吸引更多的流量产生更多的错误。
- 数据要衰减: 如果服务器的负载太高，没有请求会发到那里。因此，使用一个类似于反 S 曲线的衰减函数来保证老数据会被清理掉。
结果: 服务器接收的请求更加的均衡了
