我希望你不介意问我这个问题，因为我找不到明确的答案。
我说没有问题。 我只是想研究一些我自己的研究。
我想知道如何负载平衡的工作。 我知道负载平衡器接受请求，然后处理所有不同的连接请求，然后连接到一个没有失败或接近失败的服务器。 我感兴趣的是，所有的服务器都必须被镜像才能工作？ 举例来说，Facebook将在其服务器上存储最可能的peta-bytes的信息。 如果服务器上的空间不足，他们将如何实现更多的空间？ 如果他们添加了一个新的服务器，他们希望平衡负载，而不是必须镜像以及它将变满。 我知道这可能不是最好的例子，但它是除Google之外唯一一家拥有如此多数据的公司，对于您可以在服务器上存储多less数据，他们。
我有另一个查询是有负载平衡服务器使用的数量的限制？ 我知道一些平衡器可以接受7000个并发连接，所以如果我安装了3个负载平衡服务器，理论上它能够处理21000个并发连接吗？ 我希望这是有道理的。 我是新来的服务器游戏。
“负载平衡器”这个术语是非常广泛的，因此没有人回答您的问题（对于不同types的负载平衡器，答案会有所不同）。 例如，您将负载均衡器描述为“接受[…]请求，然后将[连接]连接到未失败或接近失败的服务器”是不正确的某些types的负载平衡器。
通常，负载平衡器将工作分配给多个后端或“工作”服务器或进程。 它是如何随着分发工作的types而变化的（取决于工作和环境，它可以使用连接代理，连接redirect或工作人员从中检索作业的各种工作队列）。 负载平衡器确定哪个后端服务正常的algorithm，以及指向哪个后端以及何时从后端检索失败的工作请求的algorithm同样完全是应用程序特定的。
后端的状态和性质也是无限的变化。 一些体系结构涉及拥有大量完美镜像的后端执行相同的工作，而另一些则采用多层体系结构，其中服务器池接受请求，然后向基础架构内的其他负载平衡服务发出请求。 大型存储通常是它自己的一个层次，请求被送入存储集群并以其他方式处理 – Google的GFS就是一个例子。 在非常大的情况下，请求存储资源的工作人员将自己有一个查找机制来确定哪个存储集群将拥有他们需要的信息，如在Github的存储库存储系统中。
至于要使用的服务器的数量，这一切都归结为后端的性能和冗余。 正如你猜测的那样，如果一个服务器可以处理7000个并发连接，那么三台服务器将能够处理或多或less的21000个并发连接 – 假设另一个层中没有瓶颈（比如数据库服务器正在进入，或者负载均衡器本身无法处理那么多的连接）。 但是，如果每个服务器都有故障概率P，则单个机器故障的几率为N * P; 随着你越来越大，你将会经常遇到机器故障。 因此，您通常需要一定数量的过剩容量 – 这也会处理意外的负载峰值。