扩展负载均衡器设备和后端网络设备

扩展负载均衡器设备和后端网络设备

假设我们正在为世界上几乎无限的用户提供一个大型的网络服务。

许多文章提到使用负载平衡器扩展服务器(例如,AWS ELB) 和许多像这张图一样的服务器机器(或云虚拟机实例)。

在此处输入图片描述

这样就将服务器的负载分散到了多台服务器上。但是,我们如何才能分散负载均衡器的负载呢?

我猜循环 DNS 服务器或者工作负载感知型 DNS 服务器可能会有所帮助。对吗?(在这种情况下,让我们忽略 DNS 服务器本身的工作负载问题。)

在此处输入图片描述

在服务器后面,有一个数据库分片集群或分区实例。服务器实例与实例之间,有一个用于连接两组网络的设备。

在此处输入图片描述

如何解决数据库实例和服务器实例之间的网络设备中的工作负载问题?如果我们不解决它,该网络设备将成为性能瓶颈或单次功率因数校正

答案1

没有一个设备

如何解决数据库实例和服务器实例之间的网络设备的工作负载问题?

这假设所有 Web 服务器共享一个网络设备。并且所有数据库分片共享一个网络设备。但这不是必需的。

假设有一台 Web 服务器有两个网卡。其中一个连接到面向公众的网络,可能直接连接到负载均衡器。另一个可以连接到路由设备,该路由设备可以连接到一组统一设备。如果mWeb 服务器和nDB 分片之间的平均流量为,则总流量k为。但每个路由器只需要承载或流量。每个统一器只需要承载或流量。因此,添加更多服务器或分片会减少每个网络设备上的流量需求(假设总流量恒定)。 m*n*kTn*kT/mm*kT/nT

我们将网络设备连接到多台服务器,因为网络设备往往能够处理比服务器多得多的流量。这不是必需的。您不需要减少到单点故障 (SPOF)。

Amazon.com 示例

除此之外,还有其他地方可以减少流量。例如,考虑一下 Amazon.com 在 2008 年左右的工作方式。首先是循环 DNS,它将客户端引导到一组代理服务器的负载平衡器之一。代理服务器可以检查请求,然后引导到一组适当的 Web 服务器(可能根据会话、浏览器实例或产品以及页面类型进行区分)。然后,这些 Web 服务器将与处理会话、用户、订单或产品等信息的服务服务器进行通信。

然后,服务服务器将与数据库通信。它们只会与自己的数据库通信。如果需要其他类型的信息,它们将从另一台服务服务器获取。一些服务服务器可能是只读的,并缓存信息。因此后续读取只会命中缓存,而不会命中数据库。其他服务器将能够执行写入操作。

在某些方面,缓存层可能不如数据库层那么健壮。由于缓存层可以从数据库层重建,因此即使它处于可检测到的不一致状态,也没关系。这允许缓存层优化可用性和性能而不是一致性。同时,数据库层可以放弃写入性能以换取一致性(并保持可用性)。

数据库层仅面对写入流量和一小部分读取流量。对于 Amazon.com 来说,这大大减少了数据库流量。这是因为写入操作(如订单、添加产品和添加库存)发生的频率远低于读取操作(如查找和查看产品)。此外,请记住,我们在每个级别都分割了流量。因此,产品信息服务器仅向产品信息服务数据库写入数据。并且只针对一小部分产品。

分区

有多个地方可以发生分区。

  • DNS 可以地理。如果你在美国西海岸,你可能会获得一个西海岸的IP。
  • 负载平衡可以. 因此负载均衡器每次都可以将您引导至同一个代理服务器。
  • 代理服务器可以基于以下方式进行分区
    • 会话 ID。基于 cookie 或 URL 参数的当前会话标识符。单个用户。临时。
    • 浏览器实例。在特定机器上运行的特定浏览器。可能由一小组用户共享。永久的。
    • 页面类型。在 Amazon.com 上,这可能是产品页面、发现(搜索/浏览)页面、购物车页面、下订单页面、之前下订单的列表等。
    • 页面标识符。这可以是产品、订单或搜索标识符。
  • Web 服务器可能很粘。您可能会访问同一个服务器。因此它可以缓存您之前进行的服务调用。
  • 不同的页面调用不同的服务集。
  • 数据库可以分片.因此,有些行位于一个数据库上,有些位于其他数据库上。

标识符通常按数学方式划分。例如,您可以按奇数和偶数划分。或者按模数划分。或者通过一些更复杂的方法。

为什么这可能行不通

您可能会遇到的一些问题:

  1. 如果您的服务是多种类型的交叉,该怎么办?例如,如果您的服务必须访问会话和产品数据。并且它需要很多不同的组合(可能全部都需要)。
  2. 如果您的服务正在比较同一类型的多个实例,该怎么办?例如,游戏排行榜可能需要每个用户的数据。这也许可以解释为什么排行榜通常只显示前 100 名或其他信息。
  3. 如果您的数据没有自然分区怎么办?例如,用户的订单可能包含来自多个卖家的多种产品。您是否按产品、买家或卖家对订单项进行分区?问题是不同的用例可能会按其中任何一个进行查询。
  4. 也许您的数据需要进行更多写入,因此缓存帮助不大。在这种情况下,您可能需要考虑数据库是否是合适的持久存储。

您的实际用例可能会有更具体的问题。这些是一般的可能性。不要惊慌。其他系统克服了这些问题。例如,他们可能会添加重复信息的附加系统。这当然会增加自己的挑战。

相关内容