【问题标题】:Application server "sharding"应用服务器“分片”
【发布时间】:2017-11-09 22:34:43
【问题描述】:

如果不是负载均衡,而是直接将客户端连接到集群节点会怎样?

所以:

  1. 客户端向Dispatcher发送请求
  2. Dispatcher 告诉客户端使用哪个服务节点
  3. 客户端继续使用给定的服务节点,直到失败。然后客户端进入步骤(1)

缺点

  • 所有服务节点必须对客户端可见
  • @Alma Do:此配置使您的队列的可扩展性降低,因为您必须保持客户端节点连接,这也可能意味着整体负载分布更差

优点

  • Dispatcher 比 Balancer 更简单,所需资源更少

还有什么想法吗?如果在某处使用这种方法,您可以分享一个描述链接吗?

【问题讨论】:

  • 为什么“调度员”更容易?此外,您所说的可以在大多数负载平衡软件中轻松实现,带有“粘性会话”或类似标志(在 Web 环境中,这只是一个 cookie)。还有更多 - 这种配置使您的车队的可扩展性降低,因为您必须保持客户端节点连接,这也可能意味着整体负载分布更差
  • “Dispatcher”不路由整个集群流量,它分配节点地址,我认为它更容易。但你是对的 - 整体负载分布可能更糟。

标签: architecture cluster-computing


【解决方案1】:

调度程序如何知道要发送到哪个节点?负载均衡器的优点是它可以获取所有请求,因此它知道哪些节点负载很重。调度员不会,他们只见客户一次,就再也见不到了。

另外,当一个节点发生故障时,客户端如何知道返回到调度程序?失败的本质意味着重定向客户端是无效的。

【讨论】:

  • 作为一种简单的方法,调度程序可以使用将客户端 ID 除以活动节点数的余数。在更复杂的场景中,可以使用活动节点的 CPU 使用率。当节点不再接受连接时,客户端返回调度程序。
  • 所以你正在制作一个智能客户端,它知道如何自己进行负载平衡。在这一点上,你甚至需要一个调度程序吗?每个操作都需要能够决定它是“太慢”还是“宕机”,并且知道返回到调度程序,只需采用相同的算法,并将其放入客户端。
猜你喜欢
  • 2011-08-03
  • 1970-01-01
  • 1970-01-01
  • 2014-11-18
  • 2019-01-30
  • 1970-01-01
  • 2011-07-25
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多