分布式系统的反应式负载平衡的制作方法

专利名称：分布式系统的反应式负载平衡的制作方法
技术领域：
本发明涉及负载平衡，并且更具体地涉及分布式系统中的反应式负载平衡。
背景技术：
常规的负载平衡系统可实现各种机制以便在机器集群上全局地分布负载。这些系统通常按照固定的时间表(例如每小时一次)或通过添加附加资源来为过载的机器重新分布资源。虽然这些方法对于解决长期负载模式可能是令人满意的，但是对需要重新分布资源的分析之间的长的间隔在短期负载尖峰发生时固有地限制了系统的有效性。例如，如果中央负载平衡器每小时一次地分析对于重新分布资源的需要，那么持久保持少于一小时的短期负载尖峰可能导致集群中机器子集上的热点，并且为其工作负载位于这些机器上的消费者带来不令人满意的性能。除了按照固定的时间表来操作，如今，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的工作负载活动水平，并且生成指示所检测到的工作负载活动水平的统计数据。在某些实施例中，工作负载活动组件106执行扼流(例如，由于DN 102上有限资源的过载，提高处理速度或者抑制无法被处理的用户请求)。扼流的速率、频率或出现可以与DN 102的工作负载相对应。工作负载增加或增加超过预定义的阈值时，扼流可以增加。工作负载活动统计数据可存储在数据库108的本地分区管理器(LPM)/动态管理视图(DMV)中。在某些实施例中，工作负载活动统计数据是指示DN 102所执行的扼流的出现、速率和/或量的统计数据。可以执行两个不同的协议。在某些情形中，DN 102的本地平衡代理(LB代理)110 确定DN 102何时正在执行过度扼流，并且随后使DN 102向全局负载平衡器(全局LB)发出DN 102需要(以资源分配的形式的)帮助的信号。全局LB随后可试图执行资源分配， 诸如从过载节点交换分区到负载不足的节点。该协议利用了来自DN 102的本地知识。在其他情形中，DN 102向全局LB请求帮助，以便全局LB用资源分配进行响应。随后由于集中式系统提供的全局知识作出关于集中式位置的负载平衡决定，该集中式系统允许作出更多最优的决定。参考以上描述的其中利用了本地知识的第一协议，DN 102的负载平衡代理(LB代理)110读取工作负载活动统计数据，或者基于该工作负载活动统计数据在数据库108中推断并存储的事件。当工作负载活动统计数据或事件指示DN 102正变得过载(或者已经变得过载)， 则DN 102生成并输出帮助消息。轮询线程112可用于执行这种任务。丽114可包括分区管理器(PM) 116，该分区管理器116包括反应式负载平衡器 (反应式LB) 118。反应式LB118可以执行此处描述的负载平衡任务中的一个或多个。例如，在一个实施例中，反应式LB 118的消息接收器120接收帮助消息并且将该帮助消息过滤到消息队列122中。LB IM从消息队列读取帮助消息，并且执行用于资源分配的负载平衡协议。LB IM可以使用重新分配的资源消息来更新MN 114的全局分区管理器(GPM)126ο在某些实施例中，MN 114处理帮助消息并且执行关于资源分配的决策制定，大约几秒钟。由此，在某些实施例中采用使用快速轮询间隔的快速消息处理和决策制定流水线， 以及“足够好的最优”解决方案。此外，在某些实施例中，确定DN 102是否过载和/或在MN 114被特定的DN 102重新激活以重新执行资源分配之前的延迟是否可被再一次激活的最佳等待时间是可调的。例如，这种因子被调至用于不同的集群配置的不同值。图2是示例性反应式帮助消息处理的说明性概览。如参考图1所描述的，DN 202 检测过多的工作负载活动，并向MN 204传送帮助消息。MN 204处理该帮助消息并为DN 202 重新分配资源。在某些实施例中，MN 204的LB (未示出)确定LB未被配备来处理来自DN 202的请求。在这些实施例中，MN 204可向DN 202传送NACK或者简单地无法向DN 202传送响应。一般而言，当DN 202检测到它已经变得过载时，它将随后经由协议将帮助消息发送到MN 204。万一 MN 204的负载平衡器不可用、DN 202最近得到过帮助、或者未找到用于 DN 202的修复，则该协议包括用于使MN 204压制节点在预定义的时间发送更多的帮助消息的工具。一旦MN 204接收并接受该帮助消息，就以本地化方式执行负载平衡算法以确定能否找到平衡负载的解决方案。机器集群中的各个机器(例如DN 102)经由帮助消息报告短期尖峰。向反应式LB 118报告帮助消息。反应式LB 118分析通常在常规的负载平衡系统中提供的负载统计数据的一部分。例如，在典型的系统中，反应式LB 118分析集群级数据以有效地解决短期尖峰。 在此处描述的某些实施例中，仅将时间敏感的本地数据提供给全局组件以便于短期本地优化。报告这种本地数据的新标准可被容易地扩展到适合具体的云数据库实现以及负载平衡目标。参考回到图1，ΜΝ 114处的反应式LB 118可被定义为以比常规的负载平衡器更小的时间标尺来操作。例如，反应式LB 118可以以分钟而非小时的时间标尺来操作。
以下描述专用于其中工作负载活动统计数据或事件被MN 114用来确定过载水平和/或DN 102是否实际上过载的实现。在此处还设想的其他实施例中，其他机制可用来确定过载水平和/或DN 102是否过载。此外，在其中结合全局视图使用重新配置和PM 116 来帮助重新分配负载的实施例中，此处还设想的其他实施例可使用其他方法和组件来重新分配负载并且监控各种负载的位置。为了执行对过载节点的快速检测，可以执行以下方法。诸如DN 102的过载节点确定其是否过载并直接联系MN 114。该方法代替等待中央负载平衡器从其他源接收统计数据并确定DN 102是否过载。由此，与常规系统不同，不存在依赖其来确定DN 102是否过载的中央机构。在某些实施例中，DN 102是否过载可以根据DN 102是否经历由过多的工作负载带来的扼流所导致的性能降级来定义。可以基于预定义的资源来确定性能降级，该预定义的资源包括但不限于中央处理单元(CPU)利用率和盘等待时间，由于某些资源是与机器无关的(例如消费者空间使用)，并且在这些资源被移至不同的机器的情况下也不会改善。在某些实施例中，检测过度扼流以确定性能降级的一个替换是创建监控节点是否正在应用过多的负载的新的服务/进程。在某些实施例中，基于窗口时间的采样被用于确定DN 102是否过载。对基于窗口时间的采样的使用可以减少由其中扼流被稀疏地调用的情形所导致的在过载和非过载状态之间震荡的问题。网络协议可以如下便于负载平衡。帮助消息和NACK消息在网络协议中被定义。帮助消息包含从DN 102收集的最新的统计数据，DN 102正在请求帮助以及可被用于通知反应式LB 118它应采取什么动作的辅助数据。NACK消息可用于使反应式LB 118通知DN 102在短的时间量内停止发送帮助消息；简言之，它是流控制设备。由于过载节点持续地重新发送帮助消息——除非通过接收NACK消息而被显式地压制，故障容忍被内置到协议中，并且该协议可使得为重新发送功能发送ACK消息的需要居先。由此，如果丢失了帮助消息，那么只要DN 102保持过载并且尚未接收NACK消息，它就继续发送新的帮助消息。如果MN 114从DN 102接收另一个帮助消息，那么反应式LB 118 重新发送另一个NACK消息。由此，尽管NACK可能丢失，但协议维持流控制操作。在各种实施例中，NACK消息可包括NACK为有效的时间跨度。NACK消息还可包括指示将NACK消息发送到DN 102的原因的信息。故障模型处理在DN 102和丽114之间丢失的网络消息。在某些实施例中，对于从DN 102发送到丽114的消息，丽114不会显式地发送对所接收的消息的确认(ACK)。 相反，将从丽114发送显式压制消息(例如NACK消息)。在DN 102接收压制消息之后，压制消息将不允许或临时地阻止DN 102发送附加消息。类似的原则应用于从MN 114发送到 DN 102的消息，因为DN102不会显式地发送对所接收的消息的ACK。仅有的差别是DN节点不会向丽114发送压制消息。以下是不同的故障模式。如果从DN发送到丽的帮助消息在成功到达MN之前被丢弃，若DN在过度扼流轮询间隔(在该期间DN确定在DN处过度扼流是否持续)之后仍然需要帮助，那么DN向MN重新发送帮助消息。
8
如果NACK消息在成功到达DN之前被丢弃，则DN下一次发送由MN接收的帮助消息时，丽将以适当的NACK超时间隔重新发送NACK。如果MN未能正确地操作，则待决帮助消息的存储器内的队列将丢失。然而，由于相关联的DN尚未接收到NACK，因此DN将在下一次运行过度扼流轮询线程时重新发送其帮助消息，并且存储器内的队列将被重建。如果DN未能正确地操作，则DN丢失其记录引擎扼流及其静止状态的本地状态。将重建带有时间的引擎扼流历史，并且如果DN开始发送帮助消息而又不允许DN发送帮助消息，则丽将向DN发送NACK，并通知DN不允许发送帮助消息的时间有多长。使用所描述的协议来执行负载平衡器算法中的流控制。如果无法帮助节点(可在集群执行更关键的任务时发生)，如果最近已经帮助过该节点，或者如果该节点以前已经请求过帮助并且未找到解决方案，那么该节点将被标记为受压制的。如果该节点再一次要求帮助，则将使用上述协议发送回NACK消息。压制时间已经过期时，将再一次允许帮助消息。可将用于本地化负载平衡的方法与常规方法相区分，常规方法运行整个负载平衡套件而同时要求负载平衡器具有整个集群的最新视图(并且因此在计算上是昂贵的，并可生成不适当的动作)，和/或试图平衡整个集群而不是仅响应于节点集群中过载节点的需求。相反，此处描述的实施例不需要整个节点集群的已更新的视图，从而仅为过载节点执行本地化负载平衡，来自该过载节点的帮助消息已被接收并处理。在某些实施例中，通过指派现有的负载平衡算法来实现负载平衡，现有的负载平衡算法被限于仅将负载从使用之前描述的协议来请求帮助的节点移走，并且仅执行在短的时间量内完成的操作的某个子集。由此，不执行诸如移动数据库的操作，因为这些操作是耗时的。在一个实施例中，每段用户数据都被存储在多台机器上(例如3台机器)。机器的数目可被限于诸如3或4的小数目以便快速地执行资源分配。由此，对于每个数据库节点， 存在两个其他候选机器，反应式LB 118可以分析该候选机器以确定该候选者是否可被提供来作为与过载DN 102的交换。当候选者被标识时，临时地停止DN 102的用户处理，并且该用户处理随后被重新路由到新机器。作为又一示例，如果一台机器遇到问题，若存在100 位消费者，则存在200个候选选择(采用存在可发生交换的两个候选者的以上模型)。反应式负载平衡器118可以基于过去的信息来执行负载平衡。例如，在某些实施例中，反应式负载平衡器118可以基于前30分钟的信息来执行负载平衡。虽然图1和2中未示出，在某些实施例中，反应式LB 118可从负载不足的节点接收消息，该消息向LB 118通知该负载不足的节点具有可供过载节点使用的资源(和/或该负载不足的节点不可用，和/或该负载不足的节点不再是可用的)。由此，可以通过减少反应式LB 118考虑用于重新分配资源的节点的数量来进一步增强此处描述的实施例，因为反应式LB 118可以考虑该反应式LB 118在过去指定量的时间内从其接收到适当消息的负载不足的节点。虽然在丽114的中央反应式LB 118的上下文中讨论图1和2的实施例，但在某些实施例中，多个节点(未示出)可以通过分布式的方式来便于负载平衡。在此实施例中， 执行非集中式的负载平衡。例如，网络中的设备可以执行资源的对等共享。设备可以是具有可由节点利用的处理能力的任何设备，包括但不限于蜂窝电话、个人计算机(PC)、膝上型计算机、个人数字助理(PDA)、膝上型计算机等。具体而言，已经检测到其工作负载活动水平为过度的节点轮询与其相关联的网络中的一个或多个设备。具有该节点可用的资源的所轮询的设备可以以根据记账模型设置的价格向节点提供资源。价格可以基于所使用的资源的量、所执行的处理的类型、资源被使用的时间等。记账模型可包括节点对设备提出的价格进行还价以得到更低的价格，使用条款的协商，和/或设备通过从节点获得报价并将资源提供给最高出价者来向请求帮助的一个或多个节点拍卖资源的拍卖模型。另外，尽管上述系统和技术中的大多数是在分布式数据库系统的上下文中提供的，但是此处描述的实施例可适用于其中资源利用变化并且可以进行动态的资源分配的任何系统。例如，在本发明的范围内所设想并包括的实施例是具有多个虚拟机(VM)的系统。 如果资源分配是动态的而不是静态的，则各个VM可将帮助消息发送到主机，因为VM正接近或达到容量，并且该主机可以实现此处描述的协议以确定替换资源是否可用，并且执行对这种替换资源的分配。在相关的实施例中，如果很多不同的应用程序共享单个VM(代替单个VM-单个应用程序模型)，那么可在诸如WINDOWS AZURE或类似平台的云平台上执行负载平衡。如果 VM变为过载，则应用程序可以提供对附加资源的请求，并且可在另一台VM上重新设置。作为另一个实施例，资源被过量预订/过量预定时，可以使用此处描述的负载平衡。具体而言，当消费者请求所承诺的服务质量(QoQ并且资源已被过量预订时，可以执行负载平衡以重新分配资源并在快速反应性下满足消费者的QoS需求。作为另一个实施例，协议可用于任何分布式环境中，包括分布SQL高速缓存使用的环境、或其他类似的环境。在各种实施例中，用于反应式负载平衡的协议可被一般地构建在存储器高速缓存系统之上。在各种实施例中，此处描述的实施例可用于采用SQL 服务器、SQL AZURE⑧平台、XST0R 框架等的系统。图3是示出根据此处描述的实施例便于反应式负载平衡的示例性、非限制性方法的流程图。在310，方法300包括以适用于对多个设备进行负载平衡的第一时间粒度来对跨多个设备的多个负载进行负载平衡。在320，方法300包括从多个设备的子集中的一个设备接收帮助信号，该帮助信号指示该多个设备的子集处的资源稀缺性，该多个设备适合于比第一粒度小得多的第二时间粒度。在330，方法300包括对该多个设备的子集进行反应性地负载平衡，包括分配来自该多个设备的子集以外的设备的资源以满足资源稀缺性。在340，方法300包括从多个设备的子集以外的设备中的一个设备接收信息，该信息指示提供该设备的可用资源的成本。在某些实施例中，该信息基于拍卖模型。在某些实施例中，该信息基于来自对多个设备进行轮询的设备的还价。在350，方法300包括基于确认该成本而接收对可用资源的使用。在某些实施例中，接收对可用资源的使用包括基于为提供可用资源的成本支付费用来接收使用。如下是便于反应式负载平衡的另一个实施例。当节点检测到它已变为过载时，该节点经由协议向中央负载平衡器发送帮助消息，该协议包含用于使中央负载平衡器的中央代理压制该节点使其在指定时间内不能发送更多帮助消息的工具。在其中负载平衡器不可用、节点最近刚被帮助过和/或未找到修复的情形中，压制该节点是有用的。—旦中央代理接收并接受该帮助消息，则中央代理以本地化方式(而不是集中式方式)运行负载平衡算法以确定能否找到平衡掉请求帮助的节点的负载的解决方案，并且应用所找到的任何修复。在某些实施例中，负载平衡的集中式方式包括在要求负载平衡器具有整个集群的最新视图的同时进行负载平衡。这种方法在计算上可能是昂贵的，并且可能生成不适当的动作。例如，诸如移动的某些负载平衡操作无法在可接受的短的时间量内完成。此外，反应式负载平衡的意图是响应于已经过载的节点，而执行集中式负载平衡的现有负载平衡算法试图平衡整个集群。在某些实施例中，在负载平衡器算法中可以执行流控制。如果无法帮助节点(其可在集群执行更关键的任务时发生)，如果最近已经帮助过该节点，或者如果该节点以前已经请求过帮助并且未能找到解决方案，那么该节点将被标记为受压制的。如果该节点再一次要求帮助，则将使用所描述的NACK/帮助消息协议来发送回NACK消息。压制时间已经期满时，将再一次允许帮助消息。在这些情形的某些中，虽然不是全部，如果集群的全局知识是已知的，那么可以执行用于流控制的以上协议。在此处描述的实施例中，发送帮助消息的节点能够确定其是否正在经历过多的负载，而不是等待将统计数据发送到中央负载平衡器并且随后由中央负载平衡器确定节点是否是过载的。在某些实施例中，如果节点正在经历性能降级，则该节点确定其是过载的。性能降低可以是由该节点的引擎的扼流导致的。例如，节点的引擎被配置为扼制与该节点相关联的机器由于有限的资源而无法处理的用户请求。对请求进行扼制的处理比要求中央机构确定该节点是否过载的方法更快。代替这种方法，节点本身通过检测其活动(例如扼流) 并且响应于这种检测而对请求进行扼制来确定其是否过载。在某些实施例中，基于窗口时间的采样被用于确定该节点实际上是否过载。在该节点已经确定其是过载的时间段期间采用基于窗口时间的采样。基于窗口时间的采样被用于避免由其中节点的引擎的扼流被稀疏地调用的情形所导致的在过载和非过载状态之间的快速摆动。可以基于预定义的资源来确定性能降级，该预定义的资源包括但不限于中央处理单元(CPU)利用率和盘等待时间，由于某些资源是与机器无关的(例如消费者空间使用)， 并且这些资源在被移至不同的机器的情况下也不会改善。如下是上述NACK/帮助消息协议。在协议期间采用帮助消息和NACK消息。帮助消息包含从正在请求帮助的节点收集的最新的统计数据。在某些实施例中，辅助数据也可被包括并用于通知负载平衡器其应采取什么动作。NACK消息是从负载平衡器发出的，并且是使负载平衡器通知节点在预定义的时间量内停止发送帮助消息的消息。由此，NACK消息被用作一种形式的流控制以控制来自请求帮助的节点的帮助消息通信量。无论中央负载平衡器何时从节点接收帮助消息，NACK消息都被发送到该节点，中央负载平衡器不期望从该节点接收任何附加帮助消息。故障容忍通过使过载节点持续地发送帮助消息——除非它们被来自该节点的 NACK消息显式地压制——而在该协议中产生。由于该协议已经重新发送帮助消息，因此该故障容忍允许该协议使重发功能的ACK消息居先。如果丢失了帮助消息，那么只要节点保持过载并且该节点没有接收到NACK消息，则该节点将继续地发送新的帮助消息。如果NACK消息丢失了(并因此未被该节点接收)，若该节点继续向中央负载平衡器发送帮助消息，则中央负载平衡器将简单地重新发送另一个NACK消息，参见图2。图4、5和6是示出根据此处描述的实施例便于反应式负载平衡的示例性、非限制性方法的流程图。首先转向图4，在410，方法400包括从节点集群内的一个节点接收帮助消息。该帮助消息由节点基于该节点标识了该节点处的过载状态而生成。帮助消息包括由该节点收集的统计数据，并且在某些情形中，还包括指示该节点所需的动作的信息。在420，方法400包括响应于接收帮助消息确定能否为该节点执行负载平衡。在430，方法400包括不允许预定义时间内来自该节点的附加帮助消息。在某些实施例中，预定义时间为300秒，尽管可以采用任何合适的秒钟数。可以响应于确定以下之一而采用不允许无法为该节点执行负载平衡，在第一预定义过去时间间隔期间为该节点执行负载平衡，在第二预定义过去时间间隔期间为该节点尝试负载平衡但没有负载平衡可被执行，或者帮助消息已被接收并且处理尚未完成。在440，方法400包括在预定义时间已经过去之后允许来自该节点的附加帮助消息。在450，方法400包括向节点发送否定确认信号以在预定义时间内压制来自该节点的不允许的附加帮助消息。现在转向图5，方法500包括如上所描述的方法400的410-440。在510，方法500 包括执行基于窗口时间的采样以确定节点是否已经正确地将其自身标识为具有过载状态。 在某些情形中，在节点基于性能降级标识过载状态的时间间隔期间执行基于窗口时间的采样，该性能降级由该节点在该节点标识。以多种不同的方式来标识性能降级，包括但不限于，标识由于节点处的有限资源该节点正在对在该节点接收的请求进行扼制。现在转向图6，方法600包括如上所描述的方法400的410-440。在610，方法600 包括响应于接收到帮助消息而拒绝将确认信号传输到节点。由此，在该方法中不采用确认信号。
参照图7和8，所示的是示出用于帮助消息协议的状态的两个状态机。图7是示出本地数据库节点上轮询线程的状态的框图。轮询线程的目的是使DN的LB代理响应于DN 的过度扼流并向反应式负载平衡器请求帮助。轮询线程响应于来自MN的NACK消息并将帮助消息的字段填充为MN。字段包括关于DN的负载度量、节点处的每个分区的事务日志大小的信息(以帮助MN确定执行交换并中止全部待决事务是否过于昂贵)。如图7所示，一个状态机运行在本地DN上以处理将帮助消息发送到中央负载平衡器。首先转向图7，在710，DN处于睡眠状态。在720处，帮助消息协议开始。状态机可在睡眠模式和协议的开始之间震荡，如图7所示。例如，如果DN的负载平衡代理未在DN 标识过度扼流，则状态机可移回到睡眠状态。在730，DN移至被标识出扼流的状态。在740，如果DN最近没有接收过NACK消息， 则DN移至帮助消息被从DN发送到中央负载平衡器的状态740。在发送帮助消息之后，DN 可以移回到位于710的睡眠状态。如果DN最近已经接收到NACK消息，并且该NACK消息尚未期满，则DN移回到位于 710的睡眠状态。轮询线程包括轮询间隔(以秒钟来表示)，该轮询间隔标识轮询线程调用之间的时间量。在某些实施例中，这是30秒。在某些实施例中，这还可以是与引擎扼流相关联的
12时间段的倍数(例如10秒)，而不是以秒计的具体时间。轮询线程还包括统计数据窗口(以秒来表示)。统计数据窗口确定要评估过去多久远以确定请求被DN扼制的时间的百分比。该值可以是扼流运行之间的时间间隔的倍数 (例如10秒)。然而，轮询线程可以接受任意值(例如300秒、或5分钟)。在某些实施例中，这可以是扼流间隔的计数或数目，而不是秒钟数。轮询线程还结合了扼流时间阈值(表达为比率)。如果统计数据窗口中花费在扼流上的时间百分比大于扼流时间阈值，则DN可以经由此处描述的帮助消息协议向全局负载平衡器请求帮助。在某些实施例中，扼流时间阈值是0. 80或80%。在某些实施例中，如果扼流事件的比率大于过去的统计数据窗口的扼流时间阈值，并且如果扼流的原因纯粹是预期的瞬时过载，则轮询线程将发出帮助消息。在发出帮助消息之后，轮询线程随后进入睡眠直到它被调度以再一次运行(如图7所示)。轮询线程不会等待ACK/NACK，因为如果原始帮助消息丢失并且如果过度扼流仍在发生，那么轮询线程的下一次运行将发送另一个帮助消息。由此，在负载平衡器不发送ACK消息来确认对帮助消息的接收的情况下设计协议。图8是示出全局负载平衡器上反应式负载平衡线程的状态的框图。如图8所示， 另一个状态机在中央负载平衡器上运行并控制帮助消息处理。现在转向图8，示出并描述了全局负载平衡器上反应式负载平衡线程的状态。在810，在全局负载平衡器处接收帮助消息。在820，如果帮助消息将要被丢弃并且不会由全局负载平衡器处理，则全局负载平衡器可移至状态820，在该状态820下，该全局负载平衡器向DN发送NACK消息的。在发送NACK 消息之前，全局负载平衡器将NACK的超时值设置为预定义时间。在该预定义时间期间，不允许或压制DN发送附加帮助消息。如果来自发送的DN的帮助消息正被处理，则全局负载平衡器移至状态830，在该状态830下，全局负载平衡器的状态被保持直到对帮助消息的处理和/或对于DN的资源分配完成。如果帮助消息未被处理并且该帮助消息不会被丢弃，则全局负载平衡器将帮助消息置于待决请求队列中并移至状态830。可在负载平衡器配置多个参数以便于此处的处理。例如，可为分区的日志的最大日志大小设置阈值(例如1MB(1048576字节))，该分区可以作为反应式负载平衡的一部分被重新定位。作为另一个示例，可以为DN在为该DN于其最近的分配后可请求反应式负载平衡分配之前必须等待的时间量设置参数(例如300秒)。作为另一个示例，可以为DN在该DN于最近的请求未产生解决方案后可请求反应式负载平衡分配之前必须等待的时间量设置参数(例如DN 300秒)。这是为了避免在未出现合适的分配时来自DN的过多的请求。作为另一个示例，可以为DN在该DN于其已经达到过度帮助请求计数阈值后可请求反应式负载平衡分配之前必须等待多久设置参数(例如3600秒)。作为另一个示例，可以为用于对给定DN上的成功的负载平衡操作的数目进行计数的窗口长度有多长设置参数(例如3600秒)。作为另一个示例，可以为DN节点被负载平衡器列入黑名单之前所允许的时间间隔内有多少成功的负载平衡操作来设置参数(例如3)。
现在转向图9，所示的是用于DN反应式负载平衡状态的状态机。如所示的，在910， DN处于安静状态。在安静状态中，帮助消息已被接收供在中央负载平衡器处理。如果帮助消息已被中央负载平衡器接收并丢弃，则DN可被从安静状态移至计时拒绝状态。计时拒绝状态是从DN 202接收的任何帮助消息将从MN 204接收NACK直到预定义指定时间的状态。在920，如果所接收的帮助消息被传递到中央负载平衡器处的队列，则DN移至进行中状态。进行中状态是帮助消息已被接收，或者位于已过滤帮助消息队列中，或者目前正被丽204处理的状态。接收之后未被丢弃的帮助消息经由生产者-消费者队列被转发给反应式负载平衡器线程。如果队列已满，则接收消息线程将简单地丢弃帮助消息。这是允许的，因为如果 DN仍然需要帮助，DN随后将在下一次轮询间隔重新发送帮助消息。在某些实施例中，如果帮助消息是从已经处于进行中状态的DN接收的，则负载平衡器的接收线程将试图在消息队列中寻找来自该DN的先前的消息，并更新该消息以保持队列中的消息是最新的。如果未发现消息，则第二帮助消息被丢弃。在930，如果已处理的帮助消息被拒绝(虽然是预定义时间)，则DN移至计时拒绝状态。在计时拒绝状态中，如果帮助消息已被接收并且预定义时间已经过去，则DN可移至位于910的安静状态。在图1-9此处描述的实施例中，并且为了说明性目的使用来自图1的附图标记，每个DN 102负责检测各个DN 102的过度扼流，并且向丽114上的负载平衡器通知DN 102处正被应用过度扼流。MN 114随后负责通过试图重新分配资源以解决过度扼流，随后通过将资源分配发送给适合的DN 102，或者如果MN 114未标识合适的资源分配则拒绝从DN 102 接收的对帮助的请求来响应于帮助请求。此外，功能可基于在DN 102执行的过度扼流检测来分布，而MN 114执行大量的计算以确定资源分配(例如确定应当如何移动分区负载)。虽然此处描述的实施例利用了用于负载平衡的集中式决策制定(例如，集中式负载平衡器执行资源分配)，但决策制定组件可以是分布式而非集中式以改善系统的可缩放性，并降低中央决策制定者导致的瓶颈的可能性。在实施例中，其中决策制定是分布式的， 负载平衡随后变为非集中式。在某些实施例中，并非所接收的全部帮助消息实际上都由反应式负载平衡器来处理。由于负载平衡机制目前正忙于重新配置，节点最近被授予资源分配，或者处于各种原因节点被列入黑名单，某些帮助消息被丢弃。示例性联网和分布式环境本领域普通技术人员可以理解，此处所描述的分布式事务管理系统与方法的各实施例可以结合任何计算机或其它客户机或服务器设备来实现，该任何计算机或其它客户机或服务器设备可作为计算机网络的一部分来部署或者被部署在分布式计算环境中，并且可以连接到可进行快照的任何种类的数据存储。就此，此处所描述的各实施例可以在具有任意数量的存储器或存储单元以及出现在任意数量的存储单元上的任意数量的应用程序和进程的任何计算机系统和环境中实现。这包括但不限于具有部署在具有远程或本地存储的网络环境或分布式计算环境中的服务器计算机和客户计算机的环境。分布式计算通过计算设备和系统之间的通信交换提供了计算机资源和服务的共享。这些资源和服务包括信息的交换、对于诸如文件等对象的高速缓存存储和盘存储。这些资源和服务还包括多个处理单元之间的处理能力共享以便进行负载平衡、资源扩展、处理专门化，等等。分布式计算利用网络连接，从而允许客户机利用它们的集体力量来使整个企业受益。就此，各种设备可具有可如参考本发明的各实施例描述地参与并发控制机制的应用程序、对象或资源。图10提供了示例性的联网或分布式计算环境的示意图。该分布式计算环境包括计算对象1010、1012等以及计算对象或设备1020、1022、1024、1026,1028等，这些计算对象或设备可包括如由应用程序1030、1032、1034、1036、1038表示的程序、方法、数据存储、可编程逻辑等。可以理解的是，计算对象1010、1012等以及计算对象或设备1020、1022、10M、 1026,1028等可包括不同的设备，诸如PDA、音频/视频设备、移动电话、MP3播放器、个人计算机、膝上型计算机等。每一个计算对象1010、1012等以及计算对象或设备1020、1022、ΙΟΜ、1026、10 等可经由通信网络1040或直接或间接地与一个或多个其他计算对象1010、1012等以及计算对象或设备1020、1022、1024、1026,1028等通信。尽管在图10中被示为单个元件，但通信网络1040可包括向图10的系统提供服务的其他计算对象或计算设备，和/或可表示未示出的多个互连网络。每个计算对象1010、1012等或计算对象或设备1020、1022、1024、1026、 1028等还可以包含应用程序，诸如可以利用API或其他对象、软件、固件和/或硬件的、适于实现根据本发明的各实施例所提供的并发控制或与其进行通信的应用程序1030、1032、 1034、1036、1038。存在支持分布式计算环境的各种系统、组件和网络配置。例如，计算系统可以由有线或无线系统、本地网络或广泛分布的网络连接在一起。当前，许多网络被耦合至因特网， 后者为广泛分布的计算提供了基础结构并包含许多不同的网络，但任何网络基础结构可用于变得与如各实施例中所描述的可串行化快照隔离系统相关联的示例性通信。因此，可以利用诸如客户机/服务器、对等、或混合体系结构等网络拓扑结构和网络基础结构的主机。“客户机”是使用与它无关的另一类或组的服务的一个类或组中的成员。客户机可以是进程，即大致上是请求由另一程序或进程提供的服务的一组指令或任务。 客户机进程利用所请求的服务，而不必“知道”有关其他程序或服务本身的任何工作细节。在客户机/服务器体系结构中，尤其在联网系统中，客户机通常是访问由例如服务器等另一计算机提供的共享的网络资源的计算机。在附图10的图示中，作为非限制性示例，计算对象或设备1020、1022、ΙΟΜ、1026、10 等可被认为是客户机而计算对象1010、 1012等可被认为是服务器，其中计算对象1010、1012等作为提供数据服务的服务器，诸如从客户机计算对象或设备1020、1022、10M、1026、1(^8等处接收数据、存储数据、处理数据、向客户机计算对象或设备1020、1022、10M、1026、10 等发送数据，但任何计算机都可取决于环境而被认为是客户机、服务器或两者。这些计算设备中的任一个都可以处理数据， 或请求可包含此处一个或多个实施例所描述的用于快照隔离系统的并发控制技术的事务服务或任务。服务器通常是可通过诸如因特网或无线网络基础架构等远程网络或本地网络访问的远程计算机系统。客户机进程可以在第一计算机系统中活动，而服务器进程可以在第二计算机系统中活动，它们通过通信介质彼此通信，从而提供分布式功能并允许多个客户机利用服务器的信息收集能力。按照用于执行读设置验证或幻影检查的技术来利用的任何软件对象可以单独提供或分布在多个计算设备或对象上。在其中通信网络1040或总线是因特网的网络环境中，例如，计算对象1010、1012 等可以是其他计算对象或设备1020、1022、10M、1026、10 等经由诸如超文本传输协议 (HTTP)等多种已知协议中的任一种与其通信的web服务器。计算对象1010、1012等作为服务器还可用作诸如计算对象或设备1020、1022、1024、1026,1028等的客户机，这可以是如分布式计算环境的特性。示例性计算设备如上所述，有利的是，此处所描述的技术可适用于期望执行分布式事务管理的任何设备。因此，应当理解的是，构想了所有种类的手持式、便携式和其他计算设备和计算对象来用于各实施例，即，在设备可能期望从数据存储读事务或向数据存储写事务的任何地方。因此，以下在图10中描述的通用远程计算机只是计算设备的一个示例。此外，数据库服务器可包括以下诸如并发控制组件或事务管理器的通用计算机或其他数据库管理服务器组件的一个或多个方面。尽管并非所需，但各实施例可以部分地经由操作系统来实现，以供设备或对象的服务开发者使用，和/或被包括在用于执行此处所描述的各实施例的一个或多个功能方面的应用软件中。软件可以在由诸如客户机工作站、服务器或其他设备等一个或多个计算机执行的诸如程序模块等计算机可执行指令的通用上下文中描述。本领域的技术人员可以理解，计算机系统具有可用于传递数据的各种配置和协议，并因此没有特定配置或协议应被认为是限制性的。因此，图11示出了其中可实现此处描述的各实施例的一个或多个方面的合适的计算系统环境1100的一个示例，尽管如上所述，计算系统环境1100仅为合适的计算环境的一个示例，并非对使用范围或功能提出任何限制。也不应将计算系统环境1100解释为对在示例性计算系统环境1100中示出的组件中的任何一个或其组合有任何依赖或要求。参考图11，用于实现一个或多个实施例的示例性远程设备包括计算机1110形式的通用计算设备。计算机1110的组件可以包括，但不仅限于，处理单元1120、系统存储器 1130，以及将包括系统存储器的各种系统组件耦合到处理单元1120的系统总线1122。计算机1110通常包括各种计算机可读介质，并可以是可由计算机1110访问的任何可用介质。系统存储器1130可以包括诸如只读存储器(ROM)和/或随机存取存储器 (RAM)等易失性和/或非易失性存储器形式的计算机存储介质。作为示例而非限制，系统存储器1130还可包括操作系统、应用程序、其他程序模块、和程序数据。用户可以通过输入设备1140向计算机1110输入命令和信息。监视器或其他类型的显示设备也经由接口，诸如输出接口 1150连接至系统总线1122。除监视器之外，计算机还可以包括其他外围输出设备，如扬声器和打印机，它们可以通过输出接口 1150连接。计算机1110可使用至一个或多个远程计算机，诸如远程计算机1170的逻辑连接在网络化或分布式环境中操作。远程计算机1170可以是个人计算机、服务器、路由器、网络 PC、对等设备或其他常见网络节点、或任何其他远程媒体消费或传输设备，并且可以包括上面关于计算机1110所描述的任何或全部元件。图11所示的逻辑连接包括诸如局域网(LAN) 或广域网(WAN)等的网络1172，但也可以包括其他网络/总线。这样的联网环境在家庭、办公室、企业范围计算机网络、内联网和因特网中是常见的。如上所述，尽管结合各种计算设备和网络体系结构描述了各示例性实施例，但基本概念可被应用于其中期望高可靠性且处于高容量或高并发性的可能条件下的读和/或写事务的任何网络系统和任何计算设备或系统。而且，存在实现相同或相似功能的多种方法，例如适当的API、工具箱、驱动程序代码、操作系统、控件、独立或可下载软件对象等，它们使得应用和服务能够使用事务并发控制技术。由此，从API (或其他软件对象)的观点以及从实现包括此处描述的确认测试的并发控制的一个或多个方面的软件或硬件对象构想此处的各实施例。因此，此处描述的各实施例可以具有完全采用硬件、部分采用硬件并且部分采用软件、以及采用软件的方面。在本文中使用的词语“示例性”意味着用作示例、范例或说明。为避免疑惑，本文公开的主题不受限于这样的示例。此外，本文描述为“示例性”的任何方面或设计不必解释成优于其他方面或设计或比其他方面或设计有利，它也不旨在排除本领域的普通技术人员所知的等效示例性结构和技术。而且，就术语“包括”、“具有”、“包含”和其他类似的词语的使用而言，为避免疑惑，这样的术语旨在以类似于术语“包括”作为开放的过渡词的方式解释而不排除任何附加或其他元素。如上所述，此处所述的各种技术可结合硬件或软件，或在适当时以两者的组合来实现。如在此所使用的，术语“组件”、“系统”等同样指的是计算机相关实体，或者是硬件、 硬件和软件的组合、软件或执行中的软件。例如，组件可以是，但不限于是，在处理器上运行的进程、处理器、对象、可执行码、执行的线程、程序和/或计算机。作为说明，运行在计算机上的应用程序和计算机本身都可以是计算机组件。一个或多个组件可以驻留在进程和/或执行线程中，并且组件可以位于一个计算机内和/或分布在两个或更多的计算机之间。如前所述的系统是利用多个组件之间的交互来描述的。可以了解，这样的系统和组件可以包括这些组件或其中指定的子组件，某些指定的组件或子组件，和/或附加的组件，并根据前述的内容的各种置换和组合。子组件也可以作为可通信地耦合到其他组件的组件来实现，而不是包括在父组件内(层次性)。另外，应注意到一个或多个组件可被组合成提供聚集功能的单个组件，或被分成若干单独的子组件，且诸如管理层等任何一个或多个中间层可被设置成通信耦合到这样的子组件以便提供集成功能。此处所描述的任何组件也可以与一个或多个此处没有专门描述的但本领域技术人员广泛地知道的其他组件进行交互。考虑到以上描述的示例性系统，参考各附图的流程图将也可以理解依照所描述的主题实现的方法。尽管为了说明简洁起见，作为一系列框示出和描述了方法，但是，应该理解，各实施例不仅限于所描述框的顺序，一些框可以按与此处所描绘和描述的不同的顺序进行和/或与其他框并发地进行。尽管经由流程图示出了非顺序或分支的流程，但可以理解，可实现达成相同或类似结果的各种其他分支、流程路径和框次序。此外，并非全部所示出的框都是实现下面所描述的方法所必需的。除了此处所描述的各实施例之外，可以理解，可以使用其他相似的实施例或者可对所述实施例作出修改和添加以便执行对应的实施例的相同或等效的功能而不背离这些实施例。此外，多个处理芯片或多个设备可共享此处所描述的一个或多个功能的执行，并且类似地，存储可以跨多个设备实现。因此，本发明不应限于任何单个实施例，而是应该根据
17所附权利要求书的广度和范围来解释。
权利要求
1.一种计算机实现的方法，包括从节点集群内的一个节点接收帮助消息410，其中所述帮助消息由所述节点基于所述节点标识所述节点处的过载状态而生成；响应于接收所述帮助消息确定能否为所述节点执行负载平衡420 ；在预定义时间内不允许来自所述节点的附加帮助消息430 ；以及在所述预定义时间已经流逝之后允许来自所述节点的所述附加帮助消息440。
2.如权利要求1所述的计算机实现的方法，其特征在于，还包括向所述节点传送否定确认信号以在所述预定义时间内压制来自所述节点的附加帮助消息450。
3.如权利要求1所述的计算机实现的方法，其特征在于，响应于确定以下之一来执行所述不允许所述附加帮助消息430 无法为所述节点执行负载平衡，在第一预定义过去时间间隔期间为所述节点执行负载平衡，在第二预定义过去时间间隔期间为所述节点尝试负载平衡但没有可执行的负载平衡，或者所述帮助消息已被接收并且处理尚未完成。
4.如权利要求1所述的计算机实现的方法，其特征在于，还包括执行基于窗口时间的采样以确定对所述过载状态的标识的准确性510。
5.如权利要求4所述的计算机实现的方法，其特征在于，所述执行基于窗口时间的采样510包括响应于基于由所述节点在所述节点处标识的性能降级所标识的所述过载状态， 执行所述基于窗口时间的采样。
6.如权利要求5所述的计算机实现的方法，其特征在于，如果所述节点标识了扼制在所述节点处接收到的请求，则标识所述性能降级。
7.如权利要求6所述的计算机实现方法，其特征在于，所述帮助消息包括由所述节点收集的统计数据。
8.如权利要求1所述的计算机实现的方法，其特征在于，还包括响应于接收所述帮助消息，拒绝将确认信号传输到所述节点610。
9.一种计算机实现的方法，包括以适合于对多个设备进行负载平衡的第一时间粒度来对跨所述多个设备的多个负载进行负载平衡310;检测来自所述多个设备中的设备的帮助信号320，所述帮助信号指示所述设备处的资源稀缺性，其中所述资源稀缺性适合于比所述第一粒度小得多的第二时间粒度；以及对所述设备进行反应性地负载平衡330以满足所述资源缺陷性，包括分配来自其他设备的资源。
10.如权利要求9所述的计算机实现的方法，其特征在于，还包括从所述其他设备中的一个接收指示向所述设备提供可用资源的成本的信息340 ；以及基于对所述成本的确认来接收对所述可用资源的使用350。
11.如权利要求10所述的计算机实现的方法，其特征在于，所述接收对所述可用资源的使用350包括基于支付所述成本的价格来接收使用。
12.如权利要求10所述的计算机实现的方法，其特征在于，所述信息是基于拍卖模型。
13.如权利要求10所述的计算机实现的方法，其特征在于，所述信息是基于来自对所述多个设备进行轮询的所述其他设备中的一个的还价。
14.如权利要求9所述的计算机实现方法，其特征在于，所述帮助信号包括由所述多个设备中的所述设备收集的统计数据。
15.如权利要求14所述的计算机实现方法，其特征在于，所述统计数据包括所述多个设备中的所述设备的工作负载活动水平。
全文摘要
本发明涉及负载平衡系统和方法。在一个实施例中，反应式负载平衡器可从第一数据库节点接收反馈，并且至少基于该反馈向第一数据库节点分配资源。反馈是动态的并且包括指示第一数据库节点的负载水平的信息。在某些实施例中，该反馈包括指示负载不足的第二数据库节点的负载水平的信息。在其他实施例中，负载平衡由轮询其上资源可用的一组设备(例如，蜂窝电话、个人计算机、PDA)的过载节点来执行。具体而言，方法包括向设备轮询关于该设备上的资源可用性，并且接收关于至少一个设备所提供的资源的价格信息。响应于提供对价格的支付，过载的节点利用资源。可以采用拍卖模型或者出价/还价方法。
文档编号G06F9/50GK102426545SQ201110354959
公开日2012年4月25日 申请日期2011年10月26日 优先权日2010年10月27日
发明者D·洛, M·本范诺托, S·林加姆, 张侃敏 申请人:微软公司