分布式系统的反应式负载平衡技术方案

本发明专利技术涉及负载平衡系统和方法。在一个实施例中，反应式负载平衡器可从第一数据库节点接收反馈，并且至少基于该反馈向第一数据库节点分配资源。反馈是动态的并且包括指示第一数据库节点的负载水平的信息。在某些实施例中，该反馈包括指示负载不足的第二数据库节点的负载水平的信息。在其他实施例中，负载平衡由轮询其上资源可用的一组设备(例如，蜂窝电话、个人计算机、PDA)的过载节点来执行。具体而言，方法包括向设备轮询关于该设备上的资源可用性，并且接收关于至少一个设备所提供的资源的价格信息。响应于提供对价格的支付，过载的节点利用资源。可以采用拍卖模型或者出价/还价方法。

【技术实现步骤摘要】

本专利技术涉及负载平衡，并且更具体地涉及分布式系统中的反应式负载平衡。
技术介绍
常规的负载平衡系统可实现各种机制以便在机器集群上全局地分布负载。这些系统通常按照固定的时间表(例如每小时一次)或通过添加附加资源来为过载的机器重新分布资源。虽然这些方法对于解决长期负载模式可能是令人满意的，但是对需要重新分布资源的分析之间的长的间隔在短期负载尖峰发生时固有地限制了系统的有效性。例如，如果中央负载平衡器每小时一次地分析对于重新分布资源的需要，那么持久保持少于一小时的短期负载尖峰可能导致集群中机器子集上的热点，并且为其工作负载位于这些机器上的消费者带来不令人满意的性能。除了按照固定的时间表来操作，如今，SQL AZURE 和类似技术中使用的负载平衡器通常试图通过将负载均勻地分散在整个机器集群来执行全局优化。然而，该方法的缺点是如果负载突然改变，那么集群将是不平衡的直到下一个负载平衡器运行。因此，如今， 负载平衡器没有充分地解决具有高度动态的负载改变的集群中的平衡。此外，当前反应式负载平衡器通过简单地将请求发送到另一个机器来对过载的机器作出反应。然而，这种形式的负载平衡要求用户请求是机器不可知的。然而，在采用 SQL AZURE 的系统中，这种形式的负载平衡本质上是不可能的，因为请求被绑定到一个具体的机器。由此，对于SQL AZURE 应用程序，负载平衡器必须物理上重新分配哪些机器可处理哪些请求，这不是机器不可知的。常规的负载平衡器的上述缺点仅旨在提供常规系统和技术的一些问题的概览，并且不旨在是穷尽性的。常规系统和技术的其他问题以及此处描述的各个非限制性实施例的对应益处可以在审阅以下描述后变得更显而易见。
技术实现思路
此处提供了简化的
技术实现思路
以帮助能够对以下更详细的描述和附图中的示例性、 非限制性实施例的各方面有基本或大体的理解。然而，本
技术实现思路
并不旨在作为详尽的或穷尽的概观。相反，本
技术实现思路
的唯一目的是以简化的形式来提出与一些示例性非限制性实施例相关的一些概念，作为以下各实施例的更为详细的描述的序言。在一个或多个实施例中，实现了反应式负载平衡。在一个实施例中，反应式负载平衡器可从第一数据库节点接收反馈，并且至少基于该反馈向第一数据库节点分配资源。反馈是动态的并且包括指示第一数据库节点的负载水平的信息。在某些实施例中，该反馈包括指示负载不足的第二数据库节点的负载水平的信息。在其他实施例中，负载平衡由轮询其上资源可用的一组设备(例如，蜂窝电话、个人计算机、PDA)的过载节点来执行。具体而言，方法包括向设备轮询关于该设备上的资源可用性，并且接收关于至少一个设备所提供的资源的价格信息。响应于提供对价格的支付， 过载的节点利用资源。可以采用拍卖模型或者出价/还价方法。在一个或多个实施例中，以第一粒度(例如每小时一次)为一组设备执行反应式负载平衡器。随后，从设备中的一个接收指示资源稀缺性的帮助信号。以比第一粒度小得多的第二粒度(例如以分钟的规模)接收帮助信号。随后为从其接收帮助信号的设备执行反应式负载平衡。在某些情形中，反应式负载平衡包括将资源从其他设备分配给从其接收帮助信号的设备。在一个或多个其他实施例中，另一个反应式负载平衡方法包括基于节点处的过载状态从节点接收帮助消息。该节点确定在发送帮助消息之前其具有过载状态。在接收帮助消息之后，反应式负载平衡器确定是否可为该节点执行负载平衡。在这期间，通过负载平衡器不允许预定义时间期间的附加帮助消息来压制这种附加消息。例如，否定确定(NACK)可被发送到节点以压制可由该节点发送的任何附加消息。在该实施例中，没有ACK消息被发送，而流控制是通过按需使用重复的NACK和/或重复的帮助消息来执行的。这些和其他实施例在下面将更详细地描述。附图说明各非限制性实施例参考附图来进一步描述，附图中图1是分布式数据库系统中反应式负载平衡的示例性系统体系结构的说明性概览；图2是示例性反应式帮助消息处理的说明性概览；图3、4、5和6是示出根据此处描述的实施例便于反应式负载平衡的示例性非限制性方法的流程图；图7是示出本地数据库节点上轮询线程的状态的框图；图8是示出全局负载平衡器上反应式负载平衡线程的状态的框图；图9是示出反应式负载平衡状态中数据库节点的状态的框图；图10是表示其中可实现此处所描述的各实施例的示例性、非限制性联网环境的框图；以及图11是表示其中可实现此处所描述的各实施例的一个或多个方面的示例性、非限制性计算系统或操作环境的框图。具体实施例方式此处在以下描述及附图中描述了某些说明性实施例。这些实施例仅是示例性、非限制性并且非穷尽性的。由此，此处设想并旨在覆盖在各实施例精神内的全部修改、更改和变型。如在本申请中所使用的，术语“组件”、“组件”、“系统”、“接口 ”等一般旨在表示硬件和/或软件、或者执行中的软件。例如，组件可以是但不限于在处理器上运行的进程、处理器、对象、可执行代码、执行的线程、程序和/或计算机。作为说明，运行在控制器上的应用程序和控制器都可以是组件。一个或多个组件可以驻留在进程和/或执行的线程内，且组件可以位于一台计算机上和/或分布在两台或更多的计算机之间。作为另一示例，接口可包括输入/输出(I/O)组件以及相关联的处理器、应用程序、和/或应用编程接口(API) 组件，并且可以像命令行那样简单，或者像集成开发环境(IDE)那样复杂。还有，这些组件可以从各种计算机可读介质和/或具有其上存储的各种数据结构的计算机可读存储介质来执行。反应式负载平衡虽然描述了反应式负载平衡的具体实施例，但此处描述的解决方案可被推广到其中接收用于数据的事务以及定义了工作负载的任意分布式系统。如果系统正在过于细粒度 (例如每小时)地进行负载平衡，则此处描述的解决方案可以补充这种负载平衡以处理负载中的短期尖峰。由此，这些实施例可以解决常规的负载平衡的缺点，提供允许节点执行对负载尖峰的快速检测的解决方案，提供协议以将该消息从单独节点传达给负载平衡器，和/ 或提供快速的本地化负载平衡。此处描述了对节点上的过度扼流(throttle)作出反应并且从全局负载平衡器请求帮助以将负载重新分配远离该节点的反应式负载平衡。此处描述的反应式负载平衡系统和方法还对诸如丢失帮助或NACK消息或节点变为不可操作等故障具有弹性。如此处所使用的，反应式负载平衡是指对由本地数据库节点生成的帮助请求/消息/信号作出反应的负载平衡。作为接下来的内容的向导，更详细地描述反应式负载平衡的各种示例性、非限制性实施例和特征。然后，为了附加说明给出一些非限制行的实现和示例，接着是可在其中实现这样的实施例和/或特征的代表性网络和计算环境。作为关于执行负载平衡的一个或多个非限制性方式的描述，图1 一般地考虑并示出用于平衡数据库节点(DN) 102的工作负载的示例负载平衡系统。尽管图1示出了单个主节点(MN) 114和单个DN 102，但是可以理解的是，DW02是为其执行负载平衡的节点集群或机器集群的一部分。在任意给定的时间，节点集群或机器集群可以是在为其执行负载平衡的特定的网络中活跃的那些节点集群或机器集群。DN 102的本地节点引擎104处理与DN 102相关联的任务。工作负载活动组件 106，也被称为引擎扼流组件，监控本地节点引擎104本文档来自技高网...

【技术保护点】

【技术特征摘要】
...

【专利技术属性】
技术研发人员：S·林加姆，张侃敏，M·本范诺托，D·洛，
申请(专利权)人：微软公司，
类型：发明
国别省市：