计算集群中的分布式组件的制作方法

分布式计算系统可以具有软件组件，诸如软件对象或其他类型的个体可寻址的孤立实体，诸如分布式对象、代理、动作方(actor)、虚拟组件等。通常，每个这样的组件个体可寻址，并且在分布式系统中具有唯一的身份(诸如整数、GUID、字符串或不透明数据结构等)。

在允许地理分布(包括当被布置为集群的两个服务器集合在相同数据中心内或在不同数据中心中时)的分布式系统中，应用部署可以驻留在一个集群中。在这种情况下，其客户端广泛分布(例如，在世界各地)的应用在单个数据中心处处理请求，由此远离数据中心的客户端可能经历高的等待时间。

技术实现要素：

提供本发明内容以便以简化的形式介绍在下面的具体实施方式中进一步描述的代表性概念的选择。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在以限制所要求保护的主题的范围的任何方式来使用。

简言之，本文中所描述的主题的各个方面中的一个或多个方面涉及尝试确定组件是否在尝试集群能够与其通信的任何其他集群中已经被激活，并且如果是，则使用已经激活的组件。如果尚未激活，则关于在至少两个集群之间是否存在分割进行确定；如果存在分割，则组件被激活并且与指示所激活的组件是可能的副本的状态数据相关联，例如与分割的集群中的另一实例相关联。

从下面结合附图的详细描述中，其他优点将变得显而易见。

附图说明

本公开通过示例的方式示出并且不限于附图，在附图中，相同的附图标记指示相似的元件，并且在附图中：

图1是根据一个或多个示例实现的表示具有可以用于提供和管理组件的分割的集群的分布式计算系统的示例组件的框图。

图2是根据一个或多个示例实现的表示具有可以用于提供和管理组件的不再分割的集群的分布式计算系统的示例组件的框图。

图3是根据一个或多个示例实现的具有可以用于提供关于组件激活的不同操作模式的示例步骤的流程图。

图4是根据一个或多个示例实现的表示分割的集群中的组件以及副本组件的激活和去激活的示例的框图。

图5是根据一个或多个示例实现的表示在集群之间传送的组件激活请求和响应的框图。

图6是根据一个或多个示例实现的由集群(或集群的个体服务器)维护的数据的表示，其包括针对组件的激活状态数据。

图7是根据一个或多个示例实现的具有可以用于发送激活请求并且将响应处理为动作的示例步骤的流程图。

图8是根据一个或多个示例实现的具有可以在接收激活请求并且输出响应时采取的示例步骤的流程图。

图9是根据一个或多个示例实现的具有以下示例步骤的流程图，该示例步骤可以在不再被分割的集群通过将可能的副本的集合发送给其他集群并且处理响应以去除被选择为不能存活的任何副本来从分割中恢复时被采取。

图10是根据一个或多个示例实现的具有以下示例步骤的流程图，该示例步骤可以在接收和处理可能的副本的集合以确定是否存在任何副本以及在存在副本的情况下确定哪些副本存活并且输出响应时被采取。

图11是表示其中可以实现本文中所描述的各种示例的一个或多个方面的示例非限制性网络化或分布式计算环境的框图。

图12是表示其中可以实现本文中所描述的各种示例的一个或多个方面的示例非限制性机器/计算设备的框图。

具体实施方式

本文中所描述的技术的各个方面通常涉及允许应用跨多个服务器集群，例如在不同数据中心中的服务器集群，例如在云环境中。这样的应用激活(实例化)组件或使用已经激活的组件。组件基于始终可用并且具有单个激活的概念，包括在多集群环境中。注意，虽然集群可以在多个数据中心中，但是该技术适用于布置在单个数据中心中的不同服务器集群，其中一些集群在一个数据中心中并且一些集群在其他数据中心中，或者以任何其他合适的方式布置。

如本文中所使用的，集群是通常在数据中心内运行的服务器的集合。集群相对于其他集群具有唯一的身份。多集群是集群的集合，其可以是地理分布式的，例如(但不限于)驻留在不同数据中心中的集群。整个多集群是所有集群的集合，其对于每个集群是静态地已知的。活动多集群是其成员可以彼此通信的整个多集群的子集；当整个多集群的一些集群不能彼此通信时，集群被称为被分割。仲裁(quorum)多集群是包含整个多集群中的法定数目的集群(例如，整个集群的大部分)或拥有仲裁资源的活动多集群。整个多集群中最多可以有一个仲裁多集群。注意，当没有分割时，每个集群都是仲裁的一部分。

在组件系统中，应用被编程为如同任何给定的单个激活组件始终存在。当组件被调用时，如果组件尚未运行，则运行时系统将激活该组件，或者如果组件已经运行，则运行时系统使用组件的已激活实例。

因此，应用被编程为如同在任何时候都有任何组件的一个实例，其被构建到编程模型和分布式运行时中。如果应用调用组件，则如果组件的激活存在，则运行时系统寻找该激活(可能在另一个服务器集群中)，或者如果组件的激活不存在，则运行时系统创建该激活。

然而，当处理多个计算集群时，不同的集群可能试图在相同时间创建相同组件，即存在竞争状况。此外，诸如通过集群之间的通信链路的故障，集群可能变得彼此分割。在这种情况下，个体可寻址的单个激活虚拟化软件组件的概念变得不确定。

本文中描述了包括处理竞争状况以及分割集群的一个合适的示例协议的技术。例如，服务器集群可能由于它们之间的通信链路的故障而变得彼此分割，这在服务器集群在不同的数据中心中运行的情况下倾向于更加普遍，尤其是在服务器集群以相对大的地理距离分开的情况下倾向于更加普遍。尽管如此，彼此相对靠近的不同服务器集群(包括在相同数据中心中运行的集群)也可以彼此分割。

在集群彼此分割的情况下，分布式系统继续操作，但是在整个分布式系统中仅激活单个组件的概念可能是过度限制的。例如，应用可能要求使用可以在分割集群上运行的组件实例(如果需要，运行时将激活)，并且被要求的集群运行时无法与其他分割集群通信。

本文中描述了各种操作模式，其通常涉及组件的一致性与可用性。例如，在高一致性模式下，系统确保跨集群有组件的至多一个激活。为此，如果任何集群变得分割，则在集群再次通信之前不允许发生组件的新激活。

在另一模式下，例如高可用性模式，如果集群不能访问组件的激活，则该集群可以创建组件的实例，即使组件的另一激活可能在另一个分割集群上已经存在(或之后被创建)。当分割集群再次通信时，执行组件实例(例如它们的状态)的协调。

注意，上述操作模式以及其它操作模式可以基于每个组件、或每个组件类型。例如，组件Y可以被规定(例如，由管理员)为在高一致性模式下运行，而组件Z可以被规定为被允许在高可用性模式下运行。

其他模式是可行的，其中一些在本文中被示例。作为一个示例，如果一个或多个集群变得被分割，则被例如大多数集群(或者被仲裁资源的所有权等或任何其他合适的所有权/预留机制)视为(并且被其他集群已知为)仲裁的一部分的集群之一可以创建组件的新实例。没有仲裁并且从具有仲裁的集群分割的一个或多个其他集群无法创建任何组件的新实例。

又一种模式允许激活仅对于该集群存在的组件。作为一个示例，如果集群知道(或很可能)没有其他集群将需要创建另一实例，则集群可以乐观地(optimistically)创建该组件的实例。作为更具体的示例，如果集群需要激活包括视频游戏的组件，并且游戏玩家也在集群内，则该组件可以独立于任何其他集群而被激活，无论是否被划分。其他集群也可以有自己的独立的组件实例。

此外，模式中的至少一些可以在一定程度上被组合。例如，在视频游戏示例中，如果大多数玩家(但不一定是全部)在集群中，或者可能在不同的集群中但是在相同的数据中心中，则多个集群可以乐观地创建其自己的独立的游戏组件实例。集群即使在从任何或所有其他集群得到回应之前，如果认为可能(例如，来自先前使用模式)没有其他集群可能已经创建了该组件，则集群也可以乐观地创建组件实例。其他乐观情形与悲观(pessimistic)情形是可行的，例如，如果超过一半的其他集群已经响应，或者一些其他可配置的阈值百分比，则乐观地创建组件实例。

应当理解，本文中的任何示例是非限制性的。例如，组件不限于任何特定的分布式系统。作为另一示例，集群通常是指彼此结合操作的两个或更多个服务器，使得在任何服务器和/或集群内通信故障的情况下，存活的服务器或服务器集合接管故障/非通信服务器的应用。因此，如本文中所使用的，“集群”甚至包括单个存活的服务器。集群还包括用作不同服务器的虚拟机的概念，即使在相同物理机上运行。

此外，“组件”是指具有可以受益于本文中所描述的技术的属性的任何软件组件/软件对象/动作方。因此，本发明不限于本文中所描述的任何特定实现、方面、概念、结构、功能或示例。相反，本文中所描述的任何实现、方面、概念、结构、功能或示例是非限制性的，并且本发明通常可以以在编程、计算系统、数据中心和分布式计算系统中提供益处和优点的各种方式来使用。

图1示出了包括集群102(1)-102(n)的多集群配置。如通信链路中的“X”所表示的，集群102(1)-102(3)从集群102(4)-102(n)被分割。注意，为了说明的目的，示出了两个数据中心A和M(由此，分割可以由数据中心之间的广域网连接的故障导致)，然而，应当理解，数据中心不是必需的，但是如果存在，则可以连接任何实际的数目。

如在一个服务器集群102(1)中所示，但是应当理解，也适用于其他集群，一个或多个应用104可以经由运行时106请求组件的使用或激活。该技术可以使用(例如，协商一致的)协议P，用于集群跟踪哪些激活存在以及每个激活驻留在哪个集群处，其中在图1中将跟踪数据表示为组件激活数据108。协议P在运行时106中实现，包括在服务器处理器/存储器上运行的系统，该系统支持如本文中所描述的多集群单个激活组件抽象。

一般来说，如果系统中存在组件，则组件在组件空间中具有始终可寻址的身份，无论是在激活状态还是去激活状态下。因此，应用可以向组件发送操作(任务)，并且组件可以彼此通信，而不管它们的实际当前状态如何。如果组件处于去激活状态并且被发送通信，例如操作请求和/或消息(因为组件的激活或去激活状态对于发送方是未知的)，则运行时可以负责保留任何这样的操作请求和通信，直到组件可以被激活并且被提供有操作请求和/或通信。备选地，调用组件获取对去激活组件的引用的尝试可以引起去激活组件被激活，之后调用组件可以向其他组件发送操作或消息。注意，对于“始终”可寻址和“始终”存在组件的概念可能存在罕见的例外，例如，运行时可以被编程为有意地忽略涉及某一个或多个组件的请求/管理员可以有意地从存储器和持久性存储装置去除某一个或多个组件。因此，如本文中所使用的，“始终”可寻址或“始终”存在表示“始终或基本上始终”以解释任何这样的例外。

在该示例中，考虑到组件激活当前不存在于集群102(1)-102(3)上，如通过在其上被维护或以其它方式可访问的组件激活数据108(例如作为复制数据库)已知的。然而，没有办法与集群102(4)-102(n)通信，其中之一可能尝试在分割修复之前创建其自己的实例。

在这种情况下，运行时可以访问策略/规则110以确定采取什么动作。也就是说，如上所述，可以关于所请求的组件使用各种可能的操作模式之一，例如，如策略/规则110中所规定的。

为了在存在网络分割时提供高可用性，当集群不能通信时，系统允许存在两个或更多个激活的可能性。因此，如果如图1所示，集群102(1)不能与其他集群中的至少一个集群通信以获得高可用性，则运行时106基于策略/规则110可以允许集群102(1)激活它无法访问的组件。运行时注意到，该激活是可能的副本，如下所述，例如通过将激活与“DOUBTFUL”状态相关联。

当恢复通信时，如图2所示，系统通过使得集群交换可能的副本组件激活的列表或其他数据结构来重新建立组件一致性(例如，示出222(1)和222(n)，尽管每个集群发送其自己的列表)。如果激活事实上已经被复制，则通过保留仅一个存活的激活并且通知一个或多个其他激活它们是副本，协议重新建立一致性。任何副本激活都被终止，通常包括第一持久性状态。应用(例如，104)负责将一个或多个其他激活的任何状态合并到存活的激活中。

如本文中所描述的，在一个高一致性模式下，可以通过不允许针对任何给定组件(或者可能针对任何组件)的激活来完全防止一致性问题。在较少限制性但仍然一致性模式下，规则可以规定允许集群的一个集合创建激活(针对规定的组件或类型，或者可能针对任何激活)，但是仅在创建集群是集群的仲裁的一部分的情况下。可用性仍然受损，因为不是仲裁的一部分的集群不允许创建新的激活。

然而，注意，诸如地理分布式的面向用户的应用(例如，用于游戏和社交网络，客户端连接)的一些应用通常被本地化到最靠近它们的数据中心。在很多情况下，与相同地理位置中的用户进行互动。因此，减少了用户/会话组件的多个激活的概率。在这种情况下，非仲裁分割集群可以创建激活，尽管有副本的可能性。

图3是概述一些上述概念的简化的示例流程图。如果在步骤302不存在分割，则系统在正常模式下操作，其中一次仅允许一个激活(尽管可能存在如下所述的临时异常，诸如当运行时以激活是唯一的可能性来乐观地创建激活并且之后检查是否存在另一激活时)。

如果存在分割，例如运行协议的运行时属于作为整个多集群的真子集的活动集群，则步骤302代替地跳转到步骤306，其在响应于应用请求需要创建激活时操作。注意，如果激活已在活动集群中被实例化(被激活)，则运行时仅使用该激活并且向应用返回信息，因此应用将使用现有激活实例。

如上所述，如果在高可用性模式下允许创建(可能作为副本)组件(无论被特定地标识还是通过具有某个类/类型)，则步骤308跳转到步骤314，其中，激活被创建，但是具有指示它是可能的副本的DOUBTFUL(可疑)状态。

相反，如果仅允许在高一致性模式下创建激活，但是存在分割，则步骤308跳转到步骤310，其评估集群是否为仲裁的一部分。如果不是，则在步骤312拒绝激活请求。注意，在备选的最限制性的高一致性场景中，可以绕过步骤310，即，如步骤312所示拒绝请求，而不管集群是否为仲裁的一部分。

可以理解，可以允许在高可用性模式下使用给定组件，在高一致性模式下使用另一组件(而不管仲裁)，而再一组件可以处于高一致性模式(取决于仲裁成员资格)。作为一个示例，如果没有实际的方式来使用副本协调(恢复)一个组件的状态，则这样的组件可能需要仅在高一致性模式下被激活。另一组件可以具有可协调的副本，在该情况下该组件可以是用于高可用性模式的良好候选。

可以容易地理解，协议P需要运行时间开销，通常是通信延迟。对于静态地(例如，在应用编译时)已知为仅在激活它们的集群(或者可能是集群的数据中心)内可访问的组件，则可以避免该开销。例如，表示游戏实例的组件仅可以被与游戏实例驻留在相同的数据中心中的玩家组件访问。在这种情况下，不需要通知其他数据中心中的集群关于游戏实例的激活。为了避免该通知，可以用关键字来注释针对游戏组件的类定义，例如，该关键字告知系统当该类的组件需要被激活时不运行协议。

分布式系统因此提供了将组件视为虚拟实体而不是物理实体的编程模型和支持分布式计算运行时。如将理解的，除了其它益处之外，这从程序员的角度大大简化了组件管理，同时提供了可扩展性和可靠性。注意，如本文中所使用的，“组件”是指在性质上相似的其他分布式组件、对象或动作方。

例如，如本文中所描述的“虚拟化分布式组件”(或更简单地“组件”)具有独立于其任何存储器内实例化的寿命并且因此独立于任何特定服务器的寿命的存在。例如，如果没有组件的存储器内实例，则自动发送给组件的消息可以导致在可用服务器上(例如，由运行时或诸如发送方的另一组件)创建新实例，可用服务器可以是任何可用服务器。运行时因此给予开发者虚拟“组件空间”，其允许调用系统中的任何可能的组件，如同它存在于存储器中一样。因此，即使服务器崩溃，组件也不会故障，并且组件不需要由应用来监督和/或显式地重新创建。

如可以容易理解的，因此应用代码可以以乐观风格编写，假定所有合法请求将由相应组件服务。这去除了编写检查组件的存在并且在未找到该组件的情况下创建该组件的应用代码的需要，这大大简化了应用逻辑并且减少了开发人员需要编写的代码量。

作为示例，图4概括了一个或多个实现中的组件的激活、去激活和持久性状态。类440中的去激活组件由运行时442激活到集群的所选择的服务器的服务器存储器444中，例如，激活组件M可以根据需要从去激活被激活。一旦被激活，激活组件M可以根据需要从持久性存储装置446(如果存在)调用状态/将状态存储到持久性存储装置446中。注意，持久性存储装置446可以是可访问的，而不管组件当前在其上被激活的物理服务器，例如经由例如可以基于每个集群的集中式和/或复制存储装置。然而，备选地，状态可以从很多不同种类的介质读取/存储到很多不同种类的介质，例如移动电话、控制台、云存储服务等。这样的存储装置可能不是始终可访问的，例如，诸如电话/控制台的设备；然而，可能的是，仅当设备可访问时需要依赖于对设备的访问的组件。

另外如图4所示，由运行时442基于一个或多个去激活标准来去激活激活组件X，诸如基于(缺少)使用，例如当针对一段时间没有执行任何工作时。注意，也可以允许组件去激活自身，例如通过调用去激活功能。在任何时间，并且作为去激活完成之前的去激活的一部分，组件X可以根据需要将状态持久化到持久性存储装置446(如果存在)。然后组件X被去激活。

图4还示出了组件的复制激活D，例如，两个分割集群A和B上的服务器每个具有它们自己的组件激活D的实例。每个运行时允许状态被永久化，但是在这种情况下，集群不能通信，并且因此当集群再次通信时将需要执行状态协调，其中仅一个激活实例存活，如本文中所描述的。注意，在该示例中，存储装置在每个集群的基础上被集中化。

如所理解的，当应用或另一组件需要时，运行时激活组件。因此，因为应用能够在任何时间寻址组件并且不具有组件的激活或去激活状态的概念，本文中为了简化和解释的目的，组件即使暂时处于去激活状态，也可以被视为“激活”或“被激活”。

如将理解的，本文中描述了提供针对跨多个集群的应用的支持的技术。具体地，程序员不需要显式地规定其中组件必须被激活的集群。因此，一个或多个实现允许未修改的应用是地理分布式的。

在地理分布式设置中，组件跨多个集群分布。但是，系统中的每个组件不太可能被来自每个集群的请求调用。特定组件的调用可以被限制为两种访问模式之一，包括本地引用的组件或全局引用的组件。

例如，很多组件仅可能从单个集群内被引用。这种访问模式在若干应用场景中自然出现。例如，在多玩家游戏场景的上下文中，游戏通常使其玩家登录到相同数据中心中的相同集群或集群的集合中。

全局引用的组件允许从任何集群引用组件。例如，全局引用的组件可以包含聚合信息，诸如全球排行榜或用户的游戏简档的公开可访问的摘要。

转到一个合适的激活创建协议，为了清楚起见，可以认为每个集群如同它是单个节点；本文中描述了可能需要在集群之间交换的消息。在一个或多个实现中，地理分布式组件目录协议P至少部分地基于上述组件访问模式。

如图5所示，当集群C0需要激活组件V时，C0询问其可以与之通信的每个集群(例如集群C1-Cn)该集群是否已经激活该组件。为此，描述了在每个集群上运行的协议P的请求/响应部分。如果存在已经激活组件的集群，则C0使用该激活。如果没有C0可以与之通信的其它集群C1-Cn已经创建了激活，则集群C0在本地创建激活。

本文中所描述的技术需要处理竞争状况，例如，当C0首次试图调用组件V时，它询问它可以与其通信的每个集群关于V的激活；这防止C0创建V的副本激活。然而，如果另一个集群C1同时首次试图调用V，则C0和C1可以另外各自为V创建不同的激活。协议P避免该竞争状况场景，如下所述。

本文中所描述的技术还需要处理分割，即，当并非所有集群都可以彼此通信时。例如，由于集群C0关于组件V仅可以询问其可以与之通信的集群，如果存在从集群C0分割的任何集群，则它们中的一个或多个可能已经激活V。在分割集群中的这些激活对于集群C0是未知的，因此如本文中所描述的，在某些情况下，尽管存在这些激活，但是集群C0仍然可以激活V。

分割问题的一个解决方案是使用一致的组件创建策略，其不允许在存在分割的情况下创建组件。另一稍微限制较少的解决方案是仅允许可以通信并且具有仲裁的集群在存在分割的情况下创建组件。然而，存在显著的分割机会，特别是在广域网中，因此，这样的策略可以使系统或有可能使系统的大部分不可用于创建新的组件

如图6中示例的，每个集群具有组件目录660，组件目录660通常包括将VirtualComponentId(虚拟组件Id)映射到类型元组<ActivationId,ActivationState>(<激活Id，激活状态>)的字典；其中VirtualComponentId是组件的标识符，ActivationId是组件的激活的标识符，以及ActivationState。如图6一般所示，ActivationState可以取五个值之一：

·OWNED(拥有)：如果在没有分割的情况下创建激活，则激活处于状态OWNED。也就是说，在被创建时，创建集群的活动多集群等于整个多集群。

·DOUBTFUL：如果在创建集群和其他集群之间存在一个或多个分割的情况下创建激活，则激活处于状态DOUBTFUL。也就是说，在被激活时，创建集群的活动多集群是整个多集群的真子集。如果组件V的激活是DOUBTFUL，则它可能已经被创建，尽管在创建集群的活动多集群之外存在另一激活。

·REQUESTED_OWNERSHIP(请求_所有权)：如果组件V的激活存在的集群在向其活动多集群中的其他集群询问其他激活的过程中，则组件V的激活处于状态REQUESTED_OWNERSHIP。

·RACE_LOSER(竞争_失败方)：如果集群C0失去与试图同时激活A1的另一个集群(例如C1)的竞争状况，则集群C0中的组件V的激活A0处于状态RACE_LOSER。

·CACHED(缓存)：如果激活是对远程集群中的激活的引用，则激活处于CACHED。

转到本文中所描述的技术如何处理竞争状况，作为示例，考虑集群C0想要为组件V创建激活A0。如图7的步骤702所示，C0首先在其组件目录V＝><A0,REQUESTED_OWNERSHIP>中插入条目。C0然后向其活动多集群中的集群广播(例如，图5和图7的步骤704)类型ACTIVATION_REQUEST(V,C0)(激活_请求(V,C0))的消息，其中V是C0正在试图激活的组件的VirtualComponentId。

当另一集群(例如集群C1)接收到ACTIVATION_REQUEST(V,C0)消息时，集群C1针对与组件V相对应的映射检查其组件目录。响应集群运行协议P的响应部分，通常如图8所示，其中步骤802表示接收到请求。

如果集群C1的组件目录不包含针对组件V的映射，如在步骤804处所评估的，则集群C1在步骤822处返回ACTIVATION_RESPONSE(PASS,null)(激活_响应(通过，空))。集群C1不对其组件目录进行任何改变。

如果C1的组件目录包含针对组件V的映射，则映射可以处于上述五个ActivationState之一。C1采取的操作基于其组件目录中的激活的ActivationState。

步骤806评估C1是否在其组件目录中包含V＝><A1,OWNED>，其中A1是由C1为组件V创建的激活。在这种情况下，C1已经创建了针对组件V的激活。因此，集群C1通过在步骤810向集群C0发送消息ACTIVATION_RESPONSE(FAILED,A1)(激活_响应(失败，A1))来对集群C0进行响应C1已经拥有组件V的激活，其中A1表示激活ID。

如果不拥有，则步骤808评估集群C1在其组件目录中是否包含V＝><A1,DOUBTFUL>。这种情况类似于C1包含处于状态OWNED的激活的情况。在这种情况下，C1具有针对组件V的激活(A1)，但是当C1创建激活A1时，C1的活动多集群是整个多集群的子集。如果是可疑，则集群C1在步骤810类似地用ACTIVATION_RESPONSE(FAILED,A1)进行响应。

如果状态既不是拥有也不是可疑，则步骤812评估集群C1是否在C1的组件目录中包含V＝><A1,REQUESTED_OWNERSHIP>。在这种情况下，C0和C1都竞争激活组件V；通过图7的步骤702回忆，在发出消息ACTIVATION_REQUEST之前，C0在其组件目录中插入了条目V＝><A0,REQUESTED_OWNERSHIP>。还要注意，因为C1也在请求所有权，所以C0类似地运行如图8所示例的协议的响应部分。

在从集群C0接收到消息ACTIVATION_REQUEST之后，C1的状态对于该组件是REQUESTED_OWNERSHIP，C1需要决定它是赢得还是失去竞争状况。可以使用(步骤814)例如构建在策略/规则110中并且在本文中作为确定性优先级函数prec_func示例的决胜机制T来决定哪个集群赢得竞争状况。注意，集群C0正在或者将类似地运行优先函数。

在一个或多个实现中，函数prec_func取两个参数，第一个是VirtualComponentId V，第二个是ClusterId C。对于给定的组件V，prec_func(V,C)定义所有C上的总顺序；对于给定的一对不同的集群C和C’，prec_func(V,C)小于prec_func(V,C’)或prec_func(V,C)大于prec_func(V,C’)。

如果prec_func(V,C1)大于prec_func(V,C0)，则C1赢得竞争状况(步骤816)，并且在步骤818发送ACTIVATION_RESPONSE(FAILED,null)(激活_响应(失败，空))。相反，如果prec_func(V,C1)小于prec_func(V,C0)，则C1执行两个步骤：在步骤820，集群C1将其对应于V的组件目录条目的状态改为V＝><A1,RACE_LOSER>，并且在步骤822，集群C1向集群C0发送ACTIVATION_RESPONSE(PASS,null)。

如果在步骤812状态不是REQUESTED_OWNERSHIP，则C1可以在其组件目录中包含V＝><A1,RACE_LOSER>或V＝><A’,CACHED>。注意，在该实现中，这些是仅有的两个剩余可能状态(CACHED表示C1包含对由另一集群C’拥有的V的激活A’的引用)。在任一情况下，C1在步骤822用ACTIVATION_RESPONSE(PASS,null)进行响应。

返回图7，在从其活动多集群中的每个集群接收到ACTIVATION_RESPONSE时，针对组件V的集群C0的条目或者处于状态REQUESTED_OWNERSHIP或者处于状态RACE_LOSER(因为集群C0可能已经类似地基于C1针对所有权的请求而执行了步骤814、816和820)。

如果如在步骤706处评估的针对V的C0的条目处于状态RACE_LOSER，则另一集群赢得竞争。C0延迟短的时间(步骤720)，将其状态设置为REQUESTED_OWNERSHIP，并且通过向其活动多集群中的每个集群发送消息ACTIVATION_REQUEST来重新运行协议。注意，集群C0延迟，以便允许赢得竞争状况的集群得到组件的所有权。

如果针对组件V的C0的组件目录处于状态REQUESTED_OWNERSHIP，则C0基于其从其活动多集群中的集群看到的消息ACTIVATION_RESPONSE来采取以下步骤：

如果C0从其活动多集群中的所有其它集群接收到ACTIVATION_RESPONSE(PASS,null)(步骤708)，并且C0的活动多集群也是整个多集群(即，在步骤710不存在分割)，则在步骤712，C0将其组件目录条目从V＝><A0,REQUESTED_OWNERSHIP>改为V＝><A0,OWNED>。如果C0的活动多集群不等于整个多集群，即存在分割，则C0将其组件目录条目改为V＝><A0,DOUBTFUL>。然后发生激活，如步骤716所示。

如果集群C0从其活动多集群中的集群中的至少一个集群接收到ACTIVATION_RESPONSE(FAILED,A’)(激活_响应(失败，A’))，则步骤718跳转到步骤722，在步骤722，集群将其组件目录条目改为V＝><A0,CACHED>，如步骤726所示。注意，无论是处于OWNED状态还是DOUBTFUL状态，经由在激活激活的集群上执行的步骤810返回激活ID A’。如果集群C0接收到多于一个这样的响应(步骤722)，则集群C0使用prec_func(步骤724)来决定在步骤726在其组件目录中缓存哪个激活。然后集群C0使用现有激活，如步骤728所示。

返回步骤718，如果集群C0没有接收到具有非空A’的FAILED(失败)ACTIVATION_RESPONSE消息，但是接收到至少一个ACTIVATION_RESPONSE(FAILED,null)消息，则集群C0通过向其活动多集群中的每个集群发送消息ACTIVATION_REQUEST来重新运行协议。这可以包括延迟，如步骤720所示。

集群可以例如在步骤716之后，向其他集群广播其最近激活的组件的激活通告。在一个实现中，例如，类可以由ClusterLocal(集群本地)或ClusterShared(集群共享)注释，使得仅需要广播ClusterShared类的组件的激活。这些在其他集群的组件目录中可以被设置为状态“CACHED”。

关于检测组件的多个激活，考虑当活动多集群是整个多集群的子集时，集群C0在运行本文中所描述的协议之后创建DOUBTFUL激活。由于分割，C0无法与不属于其活动多集群的集群进行通信。这些分割集群可能已经创建了组件的激活。当在状态DOUBTFUL下创建激活时，当分割之后修复时，执行关于是否存在一个或多个副本激活的检查。图9和10涉及处理任何多个激活。

如果存在一个或多个副本激活，则一个激活被分类为“获胜方”激活，而其余激活被分类为“失败方”激活。每个失败方激活的状态与获胜方激活的状态合并，然后失败方激活被去除。

无论何时集群的活动多集群改变(即，集群加入)，协议的该部分运行，如在图9的步骤902处一般表示的。可以使用一致的协议来决定对活动多集群的改变。因此，新的活动多集群中的每个集群运行协议和/或当一个或多个集群加入活动多集群时。如果一个或多个集群退出并且没有集群加入，则运行协议没有意义。

如步骤904所示，当集群C0的活动多集群改变时，集群C0收集处于状态DOUBTFUL的任何激活，并且向其活动多集群中的其他集群发送RESOLVE_REQUEST(Doubtful_Set,C0)(解析_请求(可疑_集合，C0))。Doubtful_Set(可疑_集合)是由C0创建的DOUBTFUL激活的集合，如图2中一般由可能的副本列表222(1)和222(n)的通信所表示的。在一个或多个实现中，Doubtful_Set中的每个DOUBTFUL激活是一对形式<V,A>，其中A是组件V的激活。

当集群(例如，C1)接收到消息RESOLVE_REQUEST(Doubtful_Set,C0)时，如图10的步骤1002所示，集群C1创建激活的空集合(步骤1004)，例如命名为Loser_Set以返回C0。然后，对于Doubtful_Set中的每个组件<V,A0>，(步骤1006和1020)，如果如步骤1008中针对组件V所评估的C1的组件目录包含DOUBTFUL或OWNED激活A1，则表示C1和C0都创建了组件V的激活。一个是获胜方，另一个是失败方。为了决定哪个集群是哪方，可以使用与上述类似的优先函数，如通过步骤1010和1012所表示的。如果prec_func(V,C1)大于prec_func(V,C0)，则C1获胜并且在步骤1014将<V,A0>添加到Loser_Set(失败方_集合)。如果prec_func(V,C1)小于prec_func(V,C0)，则C1从其组件目录去除A1(步骤1016)，并且在步骤1018终止激活(在合并状态之后或至少将其持久化以用于之后的合并)。一旦C1完成处理Doubtful_Set中的所有<V,A0>对，步骤1020跳转到步骤1022，在步骤1022，集群C1向集群C0发送消息RESOLVE_RESPONSE(Loser_Set)(解析_响应(失败方_集合))。

返回图9，步骤906，当C0从其活动多集群中的每个集群C_i接收到RESOLVE_RESPONSE(Loser_Set_i)时，C0将Loser_Set_i累加到Complete_Loser_Set(完整_失败方_集合)中(步骤908)。C0从其组件目录去除Complete_Loser_Set中的所有激活(步骤910)。步骤912表示合并和终止那些失败的副本。

注意，如果C_i从未为V创建激活，或者如果C_i为V创建激活，但是C0优先于C_i并且因此C_i从其组件目录去除V，则集群C_i不将组件V的DOUBTFUL激活添加到Loser_Set_i。如果新的活动多集群等于整个多集群(在步骤914中不存在分割)，则C0关于其所有DOUBTFUL组件已经联系了系统中的每个集群。如果没有一个集群将组件V的激活添加到Loser_Set_i，则C0的激活状态被转换为状态OWNED；或者没有集群为V创建激活、或者C0优先于为V创建激活的所有其他集群。因此，C0得到Doubtful_Set和Complete_Loser_Set的差异(步骤916)，并且将差异中的每个激活的状态改为OWNED(步骤918)。

转向集群内的个体服务器操作的多个方面，当创建组件的激活时，集群的服务器之间的集群内消息被适配为地理分布式集群环境。考虑在试图为组件V创建激活A0的集群C0中存在服务器S0c。S0c首先计算组件V的一致性散列以找出集群的哪个服务器包含适当的目录分割S0p。如果S0p已经包含针对组件V的激活，则它将激活返回给调用方S0c。然而，如果S0p不包含针对组件V的激活，则其运行激活创建协议，如本文参考图5、7和8一般描述的。

关于运行如参考图9和图10一般描述的副本检测阶段，可以将集群C0中的一个服务器S0g分配为网关服务器。集群的网关服务器从集群的服务器内收集DOUBTFUL激活的集合。S0g向C0中的每个服务器广播消息，以向每个服务器询问在其组件目录分割中的DOUBTFUL激活的集合。一旦网关服务器从每个服务器获得DOUBTFUL激活的集合，S0g然后向每个其他集群的网关服务器S1g广播消息RESOLVE_REQUEST(Doubtful_Set,C0)，如上面参照图7步骤704一般描述的。

在从S0g接收到消息RESOLVE_REQUEST(Doubtful_Set,C0)时，例如在图10的步骤1002，S1g基于每个激活的VirtualComponentId的一致性散列，将一组DOUBTFUL激活的集合分发给负责适当的组件目录分割的服务器。集群C1中的个体服务器如本文中所描述的解析激活。C1中的每个服务器还将失败方激活的集合返回S1g(如果远程失败方激活的集合为空，则返回空集)。

如果S1g从C1中的每个服务器获得失败方激活的集合，则S1g使用消息RESOLVE_RESPONSE(Loser_Set,true)(解析_响应(失败方_集合，真))向S0g发送失败方激活的完整集合。如果S1g没有从每个服务器获得失败方激活的集合，则它向S0g发送RESOLVE_RESPONSE(Loser_Set,false)(解析_响应(失败方_集合，假))。这两种情况是区分的，因为C0不能将DOUBTFUL激活V转换为OWNED，除非确定每个其他集群C1已经确保它不包含针对V的激活，或者它包含针对V的激活，但是根据prec_func，C0优先。

当S0g从其活动多集群中的每个集群接收到消息RESOLVE_RESPONSE时，其去激活失败方激活的集合。然而，如果以下两个状况成立，则S0g仅将Doubtful_Set\Loser_Set中的激活集合转换为状态OWNED：1)其活动多集群等于整个多集群，2)所有消息具有形式RESOLVE_RESPONSE(Loser_Set,true)。如果一个或多个接收到的消息是包含RESOLVE_RESPONSE(Loser_Set,false)的形式，它不会将任何DOUBTFUL激活转换为OWNED。如果S0g从远程集群C1的网关服务器S1g接收到消息RESOLVE_RESPONSE(Loser_Set,false)，则S0g不能确定C0中的所有DOUBTFUL激活已经由集群C1中的适当服务器分析。

注意，以上描述仅是一个示例，其中每个集群使用单个区分的服务器作为网关。然而，在备选实现中，多个服务器可以用于冗余，和/或DOUBTFUL激活的集合可以在若干网关服务器之间被划分。

关于集群成员资格，如果集群C中的服务器S0试图创建针对组件V的激活A，则S0首先将V＝><A,REQUESTED_OWNERSHIP>形式的条目插入到其组件目录中，然后向其活动多集群中的每个集群发送消息ACTIVATION_REQUEST。如果在同时将新服务器添加到集群C或从集群C删除新服务器，则S0负责的VirtualComponentId散列的范围可能改变。因此，S0的组件目录分割中的数据的子集可能需要移动到另一服务器S1。在S0正在运行激活创建协议时，可能发生S0负责的VirtualComponentId散列的范围的改变。

即使当S0正在运行针对组件V的激活创建协议时，也允许针对组件V的组件目录条目从服务器S0移动到服务器S1。当激活创建协议正在进行时，组件目录条目具有形式V＝><A,REQUESTED_OWNERSHIP>或V＝><A,RACE_LOSER>。当所有集群都使用消息ACTIVATION_RESPONSE进行响应时，S0找不到与组件V相对应的组件目录条目(因为组件目录条目可能迁移)。在该点处，S0识别组件目录条目已经移动到另一服务器，并且停止运行激活创建协议。当组件目录条目已经迁移到其的服务器S1接收到V＝><A,REQUESTED_OWNERSHIP>或V＝><A,RACE_LOSER>形式的组件目录条目时，它将重新运行激活创建协议。为了运行激活创建协议，与激活相对应的组件目录条目的ActivationState需要处于状态REQUESTED_OWNERSHIP。因为S1可能已经接收到处于状态RACE_LOSER的组件目录条目，所以S1需要首先将激活的状态改为REQUESTED_OWNERSHIP；S1延迟，以便允许赢得竞争状况的集群得到组件的所有权，然后将组件目录条目的状态转换为REQUESTED_OWNERSHIP。

S1仅需要针对具有ActivationState REQUESTED_OWNERSHIP或RACE_LOSER的组件目录条目运行激活创建协议。激活状态为DOUBTFUL、OWNED或CACHED的组件目录条目不需要任何特殊处理。

转到另一方面，一些(可能大多数)组件仅从单个集群(即，其中组件被激活的集群)内被引用。为了确保全局仅存在特定组件的单个激活，协议使得试图创建组件V的激活的集群检查其活动多集群中的任何其它集群是否已经创建了针对V的激活。如果V是本地引用的组件，则除了创建集群之外的任何集群都将不引用V。对于本地引用的组件，例如V是本地引用的组件，集群C与其集群活动多集群中的所有集群检查V的激活，尽管C是曾经引用V的唯一集群。在C的活动多集群中关于V询问每个集群的成本是单个WAN往返。WAN往返的网络等待时间成本通常比集群内的两个节点之间的往返高若干大小的数量级。

为了避免在每个本地引用的组件V上支付WAN往返的成本，集群C可以在运行激活创建协议之前乐观地创建针对V的激活。C然后异步地运行协议，而本地激活服务请求来自C中的服务器。如果C发现其活动多集群中的所有其他集群用ACTIVATION_RESPONSE(PASS,null)进行响应，则C对V的乐观激活是DOUBTFUL或OWNED，如本文中所描述的。相反，如果C发现其活动多集群中的集群之一已经激活了V，则C终止其对V的本地激活，并且在其组件目录中添加对远程激活的引用。

本公开的各方面与以下各项的任何组合一起可操作。本文中描述了在地理分布式计算环境的多集群分布式系统中提供单实例组件的示例。组件始终由应用程序通过组件的身份可寻址，包括当集群彼此分割时。

当计算环境没有彼此分割的集群时，可以在集群中仅激活多集群分布式系统中的另一单实例组件。当执行激活的集群是集群仲裁的一部分时，可以在集群中仅激活再一单实例组件。

本文中进一步描述了当被分割的集群不再被分割时，消除任何副本组件，以仅提供该组件的一个存活的单实例。消除任何副本组件包括执行选择组件的存活单实例的确定性操作。

另一方面涉及防止竞争状况，其中至少两个未分割的集群同时尝试激活组件，包括检测竞争状况状态并且仅选择一个获胜组件实例用于激活。防止竞争状况包括执行选择用于激活的获胜组件实例的确定性操作。

在一个或多个方面，一种分布式计算系统包括多个集群，每个集群具有在至少一个处理器上的至少一个服务器存储器中执行的运行时。运行时被配置为防止竞争状况，其中两个或更多个集群同时尝试激活组件，并且当集群被分割时允许存在副本组件，包括将状态数据与每个可能的副本相关联以指示可能的副本状态。当集群不再被分割时运行时评估状态数据以去除任何副本组件，以便使得针对存在的任何副本仅一个组件存活。

对于给定的组件(或类型)，运行时可以被配置为防止在分布式计算系统的集群之间存在分割的情况下激活另一组件。

运行时可以被配置为在每个其他集群已经关于组件是否在另一集群上被激活而进行响应之前乐观地激活该组件。

运行时通过向请求集群能够与其通信的每个其他集群传送激活请求来防止竞争状况，激活请求指示请求集群激活组件的意图。当另一集群确定请求集群与该另一集群处于竞争状况时，该另一集群使用决胜机制来确定哪个激活请求要成功。

运行时通过以下方式来去除任何副本组件：将可能的副本的集合交换到集群可以与之通信的每个其他集群，并且使用决胜机制确定针对存在的任何副本哪个复制组件要存活以及哪一个或多个副本将被终止。运行时可以被配置为当没有集群彼此分割时，改变状态数据以指示集群的唯一所有权。

一个或多个方面涉及在尝试集群中尝试确定在尝试集群可以与之通信的任何其他集群中组件是否已经被激活，并且如果是，则使用已经激活的组件。如果尚未激活，则关于在至少两个集群之间是否存在分割进行确定。如果存在分割，则组件被激活并且与指示激活组件是可能的副本的状态数据相关联。

一个或多个方面涉及确定至少一个先前分割的集群不再被分割，并且与至少一个其他集群交换可能的副本集合。如果存在副本组件，则选择要存活的一个组件。当没有集群彼此分割时，状态数据可以从指示可能的副本改为指示集群的唯一所有权。

一个或多个方面涉及检测竞争状况，其中至少两个未分割的集群同时尝试激活组件，并且仅选择一个获胜组件实例用于激活。

还描述了检测分割，并且仅当尝试激活的集群是集群仲裁的一部分时允许激活另一组件。

在地理分布式计算环境中，描述了用于在多集群分布式系统中提供单实例组件的装置，其中该组件始终由应用经由组件的身份可寻址，该组件针对应用可寻址包括当集群彼此分割时。还描述了用于在尝试集群中尝试确定在尝试集群可以与之通信的任何其他集群中组件是否已经被激活的装置，如果是，则用于使用已经激活的组件的装置，如果尚未激活，则描述了用于确定在至少两个集群之间是否存在分割的装置，并且如果存在分割，则用于激活组件并且将组件与指示激活组件是可能的副本的状态数据相关联的装置。

示例网络化和分布式环境

本领域普通技术人员可以理解，本文中所描述的各种实现和方法可以结合任何计算机或其他客户端或服务器设备来实现，这些计算机或其他客户端或服务器设备可以被部署为计算机网络的一部分或者部署在分布式计算环境中，并且可以连接到任何种类的一个或多个数据储存库。在这点上，本文中所描述的各种实现可以在具有任何数目的存储器或存储单元以及跨任何数目的存储单元发生的任何数目的应用和进程的任何计算机系统或环境中实现。这包括但不限于具有部署在网络环境或分布式计算环境中的具有远程或本地存储装置的服务器计算机和客户端计算机的环境。应当理解，系统设置可以是本地模式操作(例如，直接在硬件上)或虚拟化环境、或两者的组合。

分布式计算通过计算设备和系统之间的通信交换提供计算机资源和服务的共享。这些资源和服务包括针对对象(例如文件)的信息交换、高速缓存存储装置和磁盘存储装置。这些资源和服务还包括跨多个处理单元的处理能力的共享，用于负载平衡、资源扩展、处理的专业化等。分布式计算利用网络连接性，以允许客户端利用它们的集体能力来使整个企业受益。在这点上，各种设备可以具有可以参与资源管理机制的应用、对象或资源，如针对本公开的各种实现所描述的。

图11提供示例网络化或分布式计算环境的示意图。分布式计算环境包括计算对象1110、1112等以及计算对象或设备1120、1122、1124、1126、1128等，其可以包括如由示例应用1130、1132、1134、1136、1138表示的程序、方法、数据存储、可编程逻辑等。可以理解，计算对象1110、1112等以及计算对象或设备1120、1122、1124、1126、1128等可以包括不同的设备，例如个人数字助理(PDA)、音频/视频设备、移动电话、MP3播放器、个人计算机、膝上型计算机等。

每个计算对象1110、1112等以及计算对象或设备1120、1122、1124、1126、1128等可以与一个或多个其他计算对象1110、1112等以及计算对象或设备1120、1122、1124、1126、1128等直接或间接地通过通信网络1140来通信。即使在图11中被示为单个元件。但是通信网络1140可以包括向图11的系统提供服务的其他计算对象和计算设备，和/或可以表示未示出的多个互连网络。每个计算对象1110、1112等或者计算对象或设备1120、1122、1124、1126、1128等还可以包含应用，诸如应用1130、1132、1134、1136、1138，其可以利用适于与根据本公开的各种实现提供的应用通信或实现该应用的API或其他对象、软件、固件和/或硬件。

存在支持分布式计算环境的各种系统、组件和网络配置。例如，计算系统可以通过有线或无线系统，通过本地网络或广泛分布式网络连接在一起。当前，很多网络耦合到因特网，其为广泛分布式计算提供基础设施，并且包括很多不同的网络，尽管任何网络基础设施可以用于例如在各种示例中描述的易发生于系统的通信。

因此，可以利用具有诸如客户端/服务器、对等或混合架构的网络拓扑和网络基础设施的主机。“客户端”是使用与其不相关的另一类或组的服务的类或组的成员。客户端可以是请求由另一程序或过程提供的服务的过程，例如大致一组指令或任务。客户端过程利用所请求的服务，而不必“知道”关于其他程序或服务本身的任何工作细节。

在客户端/服务器架构中，特别是网络化的系统中，客户端通常是访问由另一计算机(例如，服务器)提供的共享网络资源的计算机。在图11的图示中，作为非限制性示例，计算对象或设备1120、1122、1124、1126、1128等可以被认为是客户端，并且计算对象1110、1112等可以被认为是服务器，其中充当服务器的计算对象1110、1112等提供数据服务，诸如从客户端计算对象或设备1120、1122、1124、1126、1128等接收数据，存储数据，处理数据，向客户端计算对象或设备1120、1122、1124、1126、1128等传输数据，但是根据情况，任何计算机都可以被认为是客户端、服务器或两者。

服务器通常是通过远程或本地网络(例如因特网或无线网络基础设施)可访问的远程计算机系统。客户端进程可以在第一计算机系统中是活动的，并且服务器进程可以在第二计算机系统中是活动的，通过通信介质彼此通信，从而提供分布式功能并且允许多个客户端利用服务器的信息收集能力。

在其中通信网络1140或总线是因特网的网络环境中，例如，计算对象1110、1112等可以是其他计算对象或设备1120、1122、1124、1126、1128等经由诸如超文本传输协议(HTTP)的多种已知协议中的任何协议与之进行通信的Web服务器。如分布式计算环境可以具有的特征，充当服务器的计算对象1110、1112等还可以用作客户端，例如计算对象或设备1120、1122、1124、1126、1128等。

示例计算设备

如上所述，有利地，本文中所描述的技术可以应用于任何设备。因此，可以理解，所有种类的手持式、便携式和其他计算设备和计算对象被预期用于结合各种实现使用。因此，下面在图12中描述的下面的通用远程计算机仅是计算设备的一个示例。

示例可以部分地经由用于由针对设备或对象的服务的开发者使用的操作系统来实现，和/或被包括在操作以执行本文中所描述的各种实现的一个或多个功能方面的应用软件内。软件可以在由诸如客户端工作站、服务器或其他设备的一个或多个计算机执行的诸如程序模块的计算机可执行指令的一般上下文中描述。本领域技术人员将理解，计算机系统具有可以用于传送数据的各种配置和协议，因此，任何特定的配置或协议都不被认为是限制性的。

图12因此示出了其中可以实现本文中所描述的示例的一个或多个方面的合适的计算系统环境1200的示例，但是如上所述，计算系统环境1200仅是合适的计算环境的一个示例，而非意图建议对用途或功能范围的任何限制。另外，计算系统环境1200并非意图被解释为具有与示例计算系统环境1200中所示的组件中的任一个或组合相关的任何依赖性。

参考图12，用于实现一个或多个实现的示例远程设备包括计算机1210形式的通用计算设备。计算机1210的组件可以包括但不限于处理单元1220、系统存储器1230以及将包括系统存储器的各种系统组件耦合到处理单元1220的系统总线1222。

计算机1210通常包括各种机器/计算机可读介质，并且可以是可以由计算机1210访问的任何可用介质。系统存储器1230可以包括易失性和/或非易失性存储器形式的计算机存储介质，例如只读存储器(ROM)和/或随机存取存储器(RAM)。作为示例而非限制，系统存储器1230还可以包括操作系统、应用程序、其他程序模块和程序数据。

用户可以通过输入设备1240将命令和信息输入到计算机1210中。监视器或其他类型的显示设备也经由诸如输出接口1250的接口连接到系统总线1222。除了监视器之外，计算机还可以包括可以通过输出接口1250连接的其他外围输出设备，诸如扬声器和打印机。

计算机1210可以使用到一个或多个其他远程计算机(诸如远程计算机1270)的逻辑连接在网络化或分布式环境中操作。远程计算机1270可以是个人计算机、服务器、路由器、网络PC、对等设备或其他公共网络节点或任何其他远程介质消费或传输设备，并且可以包括以上关于计算机1210描述的任何或所有元件。图12所示的逻辑连接包括网络1272，例如局域网(LAN)或广域网(WAN)，但是也可以包括其他网络/总线。这样的网络化环境在家庭、办公室、企业范围的计算机网络、内联网和因特网中是常见的。

如上所述，尽管已经结合各种计算设备和网络架构描述了示例实现，但是基础概念可以应用于期望提高资源使用效率的任何网络系统和任何计算设备或系统。

此外，存在多种方式实现相同或类似功能，例如，使得应用和服务能够利用本文中所描述的技术的适当的API、工具箱、驱动程序代码、操作系统、控件、独立或可下载软件对象等。因此，从API(或其他软件对象)的角度以及从实现如本文中所描述的一个或多个示例的软件或硬件对象来考虑本文中的示例。因此，本文中所描述的各种示例可以具有完全为硬件、部分为硬件、部分为软件以及软件的多个方面。

本文中使用的词语“示例性”表示用作示例、实例或说明。为了避免疑问，本文中公开的主题不限于这些示例。另外，本文中描述为“示例性”的任何方面或设计不一定被解释为相对于其它方面或设计是优选的或有利的，也不表示排除本领域普通技术人员已知的等效示例性结构和技术。此外，为了避免疑问，在使用术语“含有”、“具有”、“包含”和其它类似词语的范围内，这些术语旨在以类似于术语“包括”的方式是包含性的，作为开放式转换词，而在权利要求中使用时不排除任何附加或其它元件。

如上所述，本文中所描述的各种技术可以结合硬件或软件或在适当时通过两者的组合来实现。如本文中所使用的，术语“组件”、“模块”、“系统”等同样旨在指代计算机相关实体，其是硬件、硬件和软件的组合、软件或执行中的软件。例如，组件可以是但不限于在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。作为说明，在计算机上运行的应用和计算机都可以是组件。一个或多个组件可以驻留在进程和/或执行线程内，并且组件可以位于一个计算机上和/或分布在两个或更多个计算机之间。

已经关于若干组件之间的交互描述了上述系统。可以理解，这样的系统和组件可以包括这些组件或规定的子组件，规定的组件或子组件中的一些、和/或附加组件，并且基于前述的各种排列和组合。子组件还可以被实现为通信地耦合到其他组件而不是包括在父组件(分层)内的组件。另外，可以注意到，一个或多个组件可以组合成提供聚合功能的单个组件或被划分为若干单独的子组件，并且可以提供任何一个或多个中间层(例如管理层)以通信地耦合到这样的子组件以便提供集成功能。本文中所描述的任何组件还可以与本文中未具体描述但本领域技术人员通常已知的一个或多个其他组件交互。

鉴于本文中所描述的示例系统，还可以参考各个附图的流程图来理解可以根据所描述的主题实现的方法。虽然为了简化说明的目的，将方法示出并且描述为一系列框，但是应当理解和明白的是，各种示例不受框的顺序限制，因为一些框可以以与本文所描绘和描述的不同的顺序发生，和/或与其它框同时发生。在通过流程图示出非顺序或分支流程的情况下，可以理解，实现相同或相似结果的各种其他分支、流程路径和框的顺序可以被实施。此外，一些图示的框在实现下文描述的方法时是可选的。

结论

尽管本发明容许各种修改和备选构造，但是其某些所示实施例在附图中示出并且已经在上面详细描述。然而，应当理解，并非意图将本发明限制为所公开的具体形式，相反，本发明旨在覆盖落入本发明的精神和范围内的所有修改、备选构造和等同物。

除了本文中所描述的各种实施例之外，应当理解，可以使用其他类似的实施例，或者可以对所描述的一个或多个实施例进行修改和添加，以执行对应的一个或多个实施例的相同或等同功能。此外，多个处理芯片或多个设备可以共享本文中所描述的一个或多个功能的性能，并且类似地，可以跨多个设备实现存储。因此，本发明不限于任何单个实施例，而是根据所附权利要求在宽度、精神和范围内进行解释。