我希望您不介意我问这个问题,因为我找不到明确的答案。
我个人觉得没什么问题。我只是想为自己的研究做些研究。
我想知道负载平衡是如何工作的。我知道负载平衡器接受请求,然后处理所有不同的连接请求,然后连接到没有故障或接近故障的服务器。我感兴趣的是,是否必须镜像所有服务器才能使其工作?例如,Facebook 的服务器上很可能存储了 PB 级的信息。如果他们的服务器上空间不足,他们将如何实现更多空间?如果他们添加了一个他们想要平衡负载的新服务器,那么这个服务器是否也必须镜像,然后它就会变满。我知道这也许不是最好的例子,但它是除了谷歌之外唯一一家拥有如此多数据的公司,即使对他们来说,在服务器上可以存储的数据量也必须有一个截止限制。
我还有一个疑问,即使用的负载平衡服务器数量是否有限制?我知道有些平衡器可以接受 7000 个并发连接,因此,如果我安装了 3 个负载平衡服务器,理论上它是否能够处理 21000 个并发连接?我希望这说得通。我是服务器游戏的新手。
答案1
“负载均衡器”一词的含义非常广泛,因此您的问题没有统一的答案(对于不同类型的负载均衡器,答案会有所不同)。例如,您对负载均衡器的描述是“接受请求 [...] 然后 [...] 连接到未发生故障或即将发生故障的服务器”,这对于某些类型的负载均衡器来说并不正确。
通常,负载平衡器会将工作分配给多个后端或“工作”服务器或进程。具体如何分配取决于要分配的工作类型(根据工作和环境,它可以使用连接代理、连接重定向或工作器从中检索作业的各种工作队列)。负载平衡器通过算法确定哪些后端可以提供服务、将特定请求定向到哪个后端或何时从后端检索失败的工作请求,同样完全是特定于应用程序的。
后端的状态和性质也是千差万别的。有些架构需要拥有大量完全镜像的后端来执行相同的工作,而另一些架构则采用多层架构,其中服务器池接收请求,然后向基础设施内的其他负载平衡服务发出请求。大型存储通常是它自己的一层,请求被输入到存储集群中并以其他方式处理——Google 的 GFS 就是一个例子。在非常大的情况下,对存储资源发出请求的工作人员自己会有一个查找机制来确定哪个存储集群将拥有他们需要的信息,就像 Github 的存储库存储系统一样。
至于要使用的服务器数量,一切都取决于每个后端的性能和冗余度。正如您所推测的那样,如果一台服务器可以处理 7000 个并发连接,那么三台服务器将能够处理大约 21000 个并发连接 - 假设另一层没有瓶颈(例如您的数据库服务器卡住,或者负载平衡器本身无法处理那么多连接)。但是,对于 N 台服务器,每台服务器的故障概率为 P,单台机器发生故障的几率为 N*P;随着服务器规模的扩大,机器故障的频率也会更高。因此,您通常需要一定量的超额容量 - 这也可以处理意外的负载峰值。