对复制型数据库的访问进行负载平衡.pdf

提供了允许用户定义全局服务的技术，其中全局服务跨多个复制型数据库提供。数据库客户端连接到全局服务并使用该全局服务，就像它们当前在单个数据库上使用一般服务一样。在接收到连接请求时，被统称为全局数据服务框架(GDS框架)的一组组件自动地选择连接客户端的最佳数据库服务器实例。一旦那些连接被建立，客户端就至少部分地基于由GDS框架发送给客户端的建议消息确定向它们连接到的那些数据库服务器实例中的哪个数据库服务器实例发送请求。

1.  一种方法包括：
从要求访问在分布式复制环境中存储的数据集的客户端接收连接请求；
其中所述分布式复制环境包括多个数据库系统，其中每个数据库系统维护所述客户端要求访问的数据集的单独拷贝；
其中所述多个数据库系统中的每个数据库系统包括一个或多个数据库服务器实例；
响应于所述连接请求，执行以下步骤：
基于一个或多个选择标准，从属于所述多个数据库系统的数据库服务器实例中选择至少一个数据库服务器实例；及
促进在所述客户端和所述至少一个数据库服务器实例之间建立一个或多个连接；
其中所述方法由一个或多个计算设备执行。

2.  如权利要求1所述的方法，其中属于所述多个数据库系统的每个数据库系统的数据库服务器实例不能直接访问所述数据集的位于所述多个数据库系统中其它数据库系统处的拷贝。

3.  如权利要求1所述的方法，其中所述多个数据库系统被组织成区域，并且所述一个或多个选择标准包括所述区域之间的通信延时。

4.  如权利要求3所述的方法，其中所述至少一个数据库服务器实例包括在不同于所述客户端本地区域的区域中的特定数据库服务器实例。

5.  如权利要求1所述的方法，其中所述一个或多个选择标准包括所述至少一个数据库服务器实例被指定为用于所述客户端要求的服 务的优选数据库服务器。

6.  如权利要求1所述的方法，其中所述一个或多个选择标准包括由属于所述多个数据库系统的数据库服务器实例报告的性能度量。

7.  如权利要求1所述的方法，其中所述一个或多个选择标准包括所述至少一个数据库服务器属于与所述客户端相关联的同一数据库系统。

8.  如权利要求8所述的方法，其中所述至少一个数据库服务器实例至少部分地基于所述多个数据库系统中至少一个数据库系统的性能或可用性的预期变化来选择。

9.  一种方法，包括：
从能够访问由特定服务要求的数据集的多个数据库服务器实例中选择至少一个数据库服务器实例，来推荐给所述特定服务的特定客户端；
向所述特定客户端传递建议消息，所述建议消息为与所述特定服务相关联的工作请求推荐所述至少一个数据库服务器实例；
其中所述多个数据库系统中的每个数据库系统维护所述数据集的单独拷贝；
其中所述多个数据库服务器实例中的每个数据库服务器实例都属于所述多个数据库系统中的一个数据库系统；
其中所述方法由一个或多个计算设备执行。

10.  如权利要求9所述的方法，其中属于所述多个数据库系统的每个数据库系统的数据库服务器实例不能直接访问所述数据集的位于所述多个数据库系统中其它数据库系统处的拷贝。

11.  如权利要求9所述的方法，其中所述建议消息是响应于所述多个数据库系统中的一个或多个数据库系统的改变而发送的。

12.  如权利要求9所述的方法，其中所述建议消息是响应于从发送之前建议消息起经过了特定时间间隔而发送的。

13.  如权利要求9所述的方法，其中所述建议消息为与所述特定服务相关联的工作请求推荐两个或更多个数据库服务器实例。

14.  如权利要求9所述的方法，其中：
所述特定客户端与所述多个数据库系统中的第一数据库系统相关联；及
选择至少一个数据库服务器实例包括选择属于所述多个数据库系统中与所述第一数据库系统不同的第二数据库系统的第二数据库服务器实例。

15.  如权利要求14所述的方法，其中所述至少一个数据库服务器实例还包括属于所述第一数据库系统的第一数据库服务器实例。

16.  如权利要求9所述的方法，其中所述至少一个数据库服务器实例至少部分地基于所述多个数据库系统之间的通信延时来选择。

17.  如权利要求9所述的方法，其中所述至少一个数据库服务器实例至少部分地基于所述至少一个数据库服务器实例是否被指定为用于所述特定服务的优选数据库服务器实例来选择。

18.  如权利要求9所述的方法，其中所述至少一个数据库服务器实例至少部分地基于由属于所述多个数据库系统的数据库服务器实例报告的性能度量来选择。

19.  权利要求9所述的方法，其中所述至少一个数据库服务器实例至少部分地基于所述至少一个数据库服务器是否属于与所述特定客户端相关联的同一数据库系统来选择。

20.  权利要求9所述的方法，还包括：
检测到所述特定服务不再从之前提供所述特定服务的数据库服务器实例中可用；
响应于检测到所述特定服务不再从之前提供所述特定服务的数据库服务器实例中可用，执行以下步骤：
选择所述多个数据库服务器实例中的第二数据库服务器实例来提供所述特定服务；
其中所述第二数据库服务器实例至少部分地基于所述第二数据库服务器实例被标识为可用于提供所述特定服务的数据库服务器实例来选择。

21.  如权利要求9所述的方法，其中所述至少一个数据库服务器实例至少部分地基于对由所述至少一个数据库服务器实例访问的数据集的拷贝所做的改变是否比对所述数据集的另一个拷贝所做的改变滞后超过指定的时间阈值量来选择。

22.  如权利要求9所述的方法，其中所述至少一个数据库服务器实例至少部分地基于所述多个数据库系统中至少一个数据库系统的性能或可用性的预期变化来选择。

23.  一种或多种存储指令的非暂时性存储介质，其中当指令被一个或多个计算设备执行时，使得执行如权利要求1-22中任何一项所述的方法。

24.   25.一种系统，包括：
多个数据库系统，所述多个数据库系统包括第一数据库系统和第二数据库系统；
其中所述多个数据库系统中的每个数据库系统维护由服务所使用的数据集的单独拷贝；
多个数据库服务器实例，其中每个数据库服务器实例与所述多个数据库系统中的一个数据库系统相关联；
配置为在属于所述多个数据库系统的客户端和所述多个数据库服务器实例之间建立连接的全局数据服务框架，其中所述全局数据服务框架配置为当满足特定标准时，在属于所述第一数据库系统的客户端和属于所述第二数据库系统的数据库服务器实例之间建立连接；
其中所述全局数据服务框架配置为向所述多个数据库系统的客户端发送建议消息，所述建议消息指示所述客户端应所述从多个数据库服务器实例中的哪个数据库服务器实例请求特定服务。

对复制型数据库的访问进行负载平衡
技术领域
本发明设计跨管理分布式副本的系统提供服务，并且更具体地，涉及用于管理到这些系统的连接和这些系统中的负载平衡的全局数据服务框架，以及涉及跨这些副本管理服务的故障转移。
背景技术
由于各种原因，许多商业维护相同数据的多个拷贝。例如，国际化公司可能跨位于世界各地的许多数据库复制关键数据。维护相同数据的多个副本的原因包括，但不限于：
商业连续性和灾难恢复；
为本地客户的性能优化；
内容本地化和高速缓存；
遵守当地法律；及
集成通过并购获得的数据中心。
虽然维护相同数据的若干个副本可以提供多种好处，但是如果不能有效地管理，这也会成为麻烦。因此，已经开发了提供“数据库服务”并允许跨属于同一集群网格的数据库服务器实例进行服务级别工作负载管理的数据库系统。
遗憾的是，跨属于集群网格的数据库服务器实例管理工作负载没有考虑在那个网格之外维护的潜在的大量副本。分布式环境通常比集群支持更高程度的异质性。例如，在分布式环境中，跨其维护副本的各种系统可以具有不同的硬件系统架构、不同的操作系统、甚至不同类型的数据库系统。与集群不同，分布式环境中的数据库不能访问用于保持状态的共享存储。因此，通过其可以高效地管理相同数据的多个分布式副本的机制将是所期望的。
在本节中描述的方法是可以实行的方法，但不一定是先前已被构想或实行的方法。因此，除非另外指出，否则不应当假设本节中描述的任何方法仅仅因为它们被包括在本节中就有资格作为现有技术。
附图说明
附图中：
图1是根据本发明实施例的由全局数据服务框架管理的分布式复制系统的框图；
图2是根据本发明实施例的其中各种数据库系统被分成区域的图1的分布式复制系统的框图；
图3是根据本发明实施例的说明如何响应连接请求的流程图；以及
图4是其上可以实现本发明实施例的计算机系统的框图。
具体实施方式
在以下描述中，为了解释的目的，阐述了众多具体的细节，以便提供对本发明的透彻理解。但是，很显然，也可以在没有这些具体细节的情况下实践本发明。在其它情况下，众所周知的结构和设备以框图形式示出，以避免不必要地混淆本发明。
总体概述
本文描述的技术允许用户定义跨多个复制型数据库提供的全局服务。数据库客户端连接到全局服务并使用该全局服务，就像它们当前在单个数据库上使用一般服务那样。在接收到连接请求时，在本文被统称为全局数据服务框架(GDS框架)的一组组件自动地选择连接客户端的最佳数据库服务器实例。一旦那些连接被建立，客户端就至少部分地基于由GDS框架发送给客户端的建议消息确定向它们连接到的那些数据库服务器实例中的哪个数据库服务器实例发送请求。
根据一种实施例，GDS框架基于从数据库自身推送的信息生成 负载/性能信息。这与必须查看外部可测量行为的外部箱不同。因此，不是客户端通过查看数据库的外部行为试图推断它们应该做什么，而是数据库通过GDS框架告诉客户端它们应该做什么。因此，GDS可以是更主动和预测性的。例如，如果数据库将要达到过载、将要启动大的批处理作业、或者如果数据库将要经历计划中的关闭，则GSM可以建议客户端将工作从数据库中移出。
在一种实现中，GDS框架提供了单一、中央的工具来添加、去除、修改和重新定位全局服务并且查看它们在特定实例上的状态。该工具也可以用于配置GDS框架和管理其组件。
很明显，GDS框架可以利用异构数据库环境来实现。例如，由GDS框架使用的数据库集合(本文统称为“数据库云”)可以包括通过任何类型的复制技术链接在一起的来自任何数量的供应商的集群数据库和来自任何数量的供应商的单个实例数据库。此外，可以跨在不同硬件/软件平台上运行的数据库建立GDS框架。
根据一种实施例，虽然GSM提供了负载平衡/故障转移功能，但是该GSM只在连接建立期间和在告诉客户端连接池具有的连接的相对“适合度”时才参与其中。在这种实施例中，GSM不在请求路径中，因此每次客户端-服务器的往返(SQL调用)并不具有额外的一跳(hop)。
示例性分布式复制系统
参考图1，它是分布式复制系统的框图。具体而言，图1说明了包括四个数据库系统130、131、132和134的数据库云。数据库系统130是集群的数据库系统，其中多个数据库实例102、104和106访问同一共享的存储122。另一方面，数据库系统131、133和134是分别包括数据库服务器实例107、108和110的单实例数据库系统。数据库服务器实例107管理存储123上的数据。数据库服务器实例108管理存储124上的数据。数据库服务器实例110管理存储126上的数据。
在示出的实施例中，各种数据集在数据库系统130中被复制。具体而言，数据集A的副本由所有四个系统130、131、132和134进行管理。数据集B的副本由系统130、131和132进行管理。数据集C的副本由系统132和134进行管理。最后，数据集D由系统130唯一地进行管理。
因为数据库服务器实例102、104和106属于同一集群，因此所有的数据库服务实例102、104和106都能够直接访问在存储122上存储的数据集A、B和D的副本。但是，数据库服务器实例102、104和106不能直接访问由数据库服务器实例107、108和110管理的数据，因为数据库服务器实例107、108和110不属于系统130的集群。类似地，数据库服务器实例107只能直接访问系统131中的副本。数据库服务器实例108只能直接访问系统132中的副本。数据库服务器实例110只能直接访问系统134中的副本。
在示出的实施例中，五个客户端152、154、156、158和160都与系统130相关联。客户端160还与系统131相关联，其说明客户端和系统之间不必是一对一的关系。系统132与一个客户端162相关联，并且系统134与两个客户端164和166相关联。如将在以下更详细描述的，不是向与它们相关联的系统内的数据库服务器实例直接发连接请求，而是客户端配置为向全局数据服务框架100发连接请求。GDS框架100又确定与哪个系统中的哪个数据库服务器实例连接每个客户端。
此外，GDS框架100向客户端发送建议消息，以向客户端指示客户端应该将用于任何给定全局服务的请求提交给哪个数据库服务器实例。例如，在一种实施例中，GDS框架100发送建议消息，该建议消息包含指定用于特定全局服务的要发送到特定数据库服务器实例的请求比例的百分比集合。这种建议消息可以以规则的时间间隔和/或响应于要求客户端请求要被适当地重新分布的实例负载变化而产生。随着时间的推移，用于给定服务的那些百分比会基于各种因素改变，诸如每个系统当前正经受的工作负载。响应于这种改变，GDS框架 100将改变在发送给客户端的建议消息中的为该服务推荐的那个或那些数据库服务器实例和/或百分比。
很明显，系统130、131、132和134可以在相同的位置、在靠近彼此的不同位置、跨国家分布或跨世界分布。本文描述的技术可以与其中数据集的副本分布在不同数据库系统中的任何系统工作，而与那些数据库系统彼此间的地理接近程度无关。但是，如将在以下更详细描述的，每个数据库系统的位置可能是全局数据服务框架100确定哪个数据库服务器实例应该服务于任何给定请求的因素。
全局服务管理器和区域
在一种实施例中，全局服务框架100利用一组全局服务管理器(GSMS)来实现，如在图2中所示出的。全局服务管理器中的一个或多个管理器对于由全局服务框架100管理的每个数据库系统是可用的。逻辑上，全局服务管理器与它们所交互的数据库服务器系统相分离。因此，全局服务管理器可以与数据库服务器实例在同一机器上执行，或者可以在与执行同全局服务管理器交互的数据库服务器实例的机器不同的机器上执行。
根据一种实施例，全局服务管理器被分组成区域。每个区域可以包括一个或多个全局服务管理器，并且与和全局服务框架100交互的数据库系统中的一个或多个数据库系统相关联。为了说明的目的，将假设全局服务管理器202和204属于区域X，其包括数据库系统130和131。全局服务管理器206和208属于区域Y，其包括数据库系统132，并且全局服务管理器210属于区域Z，其包括系统134。
在这个例子中，区域X与两个数据库系统相关联，并且区域Y和Z各自与单个的数据库系统相关联。但是，如上面提到的，每个区域可以与任何数量的数据库系统相关联。在一种实施例中，当数据库服务器彼此具有某种形式的密切关系(affinity)时，这些数据库系统与同一区域相关联。例如，当数据库系统地理上彼此靠近，或者当它们经高速互连彼此连接时，它们可以与同一区域相关联。优选地， 在每个区域中被分组在一起的数据库系统是那些从数据库系统分配到的区域中的客户端的角度看具有相似延时的系统。因此，系统130和131从客户端152至160的角度看具有相似的延时。
驻留在与给定客户端在同一区域中的全局服务管理器被称为相对于那个客户端的“本地全局服务管理器”。例如，参考图2，全局服务管理器202和204驻留在区域X中，并因此对于客户端152、154、156、158和160以及数据库服务器实例102、104、106和107是本地的。全局服务管理器206和208驻留在区域Y中，并对客户端162和数据库服务器实例108是本地的。全局服务管理器210驻留在区域Z中，并对客户端164和166及数据库服务器实例110是本地的。
每个全局服务管理器充当由客户端使用以连接到全局服务的区域监听者。根据一种实施例，客户端连接请求在所有的区域GSM中是随机分布的。每个GMS还测量其自己的区域和所有其它区域之间的网络延时和带宽，并且与其它区域中的GSM交换这个信息。
如将在下文更详细描述的，每个GSM通过将客户端连接导向到最合适的数据库实例来执行连接负载平衡。实例是基于GSM从所有实例接收到的度量、估计的网络延时/带宽以及服务的区域密切关系确定的。
根据另一个方面，每个GSM通过启动、停止以及在实例和数据库之间移动全局服务来管理全局服务的基数(cardinality)和故障转移。GSM也可以向客户端发送建议消息，来推荐客户端应该使用连接池中每个连接的程度以获得特定服务。
根据一种实施例，每个GSM还监视数据库实例，当实例、数据库或网络不能用时生成并发布事件。GSM还根据它从云中所有实例接收到的性能度量为本地区域中的客户端生成和发布事件，并将它们与估计的网络延时集成。当区域中所有的GSM都停用时，来自伙伴(buddy)区域的GSM接管该区域的事件生成。好友区域将在以下进行更详细的描述。
数据库池
在一种实现中，在数据库云中包括的数据库可以被分组为数据库池。数据库池是数据库云中的数据库集合，其提供了唯一的全局服务集合并且属于特定管理域，例如HR池、销售池。数据库只能属于单个的数据库池。没有必要池中所有的数据库都提供相同的全局服务集合；个体数据库可以只支持由该池提供的服务的子集。但是，提供相同全局服务的所有数据库必须属于同一个池。数据库池可以具有只能管理该池的专门的管理员集合。因此，数据库池简化了管理，并且提高了大型数据库云中的安全性。
全局数据服务目录
根据一种实施例，全局数据服务目录(GDS目录)是全局数据服务框架100的另一个组件。GDS目录是由GDS框架100维护的信息的存储库(repository)。在GDS目录中存储的信息可以包括，例如，数据库云的配置和运行时状态。更具体而言，在GDS目录中维护的信息可以包括全局服务上的数据、每个全局服务的属性、及云的所有逻辑和物理组件：数据库池、区域、全局服务管理器和数据库实例。目录也可以包含有关云的复制和网络拓扑的数据。
可以在GDS目录中维护的信息项的例子包括，但不限于：
数据库云中哪里的数据库被组织成“数据库池”，每个数据
库池的成员
对于每个全局服务哪些数据库时启用的
对于每个全局服务哪些数据库是优选的
为每个全局服务规定的“基数”
下文将更详细地描述在GDS目录中存储的各个信息如何被服务框架100使用。
在一种实施例中，每个数据库云有单个的GDS目录。但是，为了高可用性的目的，可以维护目录的多个副本。在图2中，GDS目录示为存储在GDS目录数据库270中。但是，GDS目录可以存储在 任何类型的存储库中，包括平面文件。而且，虽然GDS目录数据库270被描绘为单个存储设备，但是GDS目录数据库270可以存储在若干个存储设备上，其中每个设备都可以存储GDS目录的所有或分布的部分。
处理连接请求
如上所述，当全局服务框架100从客户端接收到连接请求时，全局服务框架100选择客户端应该被连接到哪个数据库服务器实例，并且促进客户端到所选数据库服务器实例的连接。
根据一种实施例，客户端通过将它们的连接请求发送到其中一个它们的全局服务管理器来将它们的连接请求传递到全局服务框架100。例如，来自客户端152的建立连接的请求可以发送到全局服务管理器202或204，这两者对于客户端152都是本地的。来自客户端162的连接请求可以发送到全局服务管理器206或208。类似地，来自客户端164的连接请求可以发送到全局服务管理器210。
在某些情况下，客户端可以将连接请求发送到没有与该客户端关联的区域的全局服务管理器。例如，如果由于某种原因本地全局服务管理器都不可用，诸如本地区域中的所有数据库都停用，则这种情况会发生。例如，如果区域X的全局服务管理器202和204两者都停用，则客户端152可以将其连接请求发送到区域Y的全局服务管理器206，即使全局服务管理器206对客户端152不是本地的。注意，这种重新连接可以通过客户端中间件自动地完成；因此每个应用不需要实现这个逻辑。
接收到连接请求的全局服务管理器然后选择要与发送该请求的客户端连接的数据库服务器实例。为了说明起见，假设客户端154将连接请求发送到全局服务管理器202。作为响应，全局服务管理器202可以使得在客户端154和数据库服务器实例102之间形成连接。根据一种实施例，全局服务管理器只在建立连接时参与其中。在这种实施例中，一旦连接被建立，客户端就直接与它们已连接到的数据库系统 对话。
在以上给出的例子中，响应于客户端154的连接请求，建立了单个连接。但是，在许多系统中，客户端建立客户端侧的连接池，其可以包括到许多数据库服务器实例的连接。此外，客户端的连接池也可以包括到同一数据库服务器实例的多个连接。因此，来自客户端154的连接请求可以请求建立五个连接，并且响应于该请求，全局服务管理器202可以在客户端154和数据库服务器实例102之间建立两个连接、在客户端154和数据库服务器实例104之间建立一个连接、在客户端154和数据库服务器实例108之间建立一个连接、以及在客户端154和数据库服务器实例110之间建立一个连接。
伙伴区域
根据一种实施例，每个区域具有指定的“伙伴区域”。一般而言，特定区域的伙伴区域是如果该特定区域的GSM被阻止处理职责则伙伴区域的GSM将接管该特定区域的职责的区域。
例如，当区域中所有的GSM都停用时，伙伴区域中的一个或多个GSM开始充当具有失效GSM的区域的监听者。因此，如果区域X中的GSM 202和204停用，并且区域Y是区域X的伙伴区域，则来自区域Y的GSM 206和208中的一个可以开始充当区域X的监听者，同时它继续充当区域Y的监听者。在这些情况下，如果来自区域X的客户端156发出连接请求，则连接请求将由来自区域Y的GSM 206和208中的一个处理。
很明显，利用某个区域中的GSM建立数据库连接并不意味着GSM选择建立连接的数据库将与GSM在同一区域。任何GSM都可以将连接请求转发到提供适当服务的任何数据库。因此，即使GSM202和204停用，GSM 206(其驻留在区域Y中)也可以使客户端156连接到数据库服务器实例107(其驻留在区域X中)。
伙伴区域Y的GSM可以承担通常由区域X的GSM处理的所有职责，不仅仅是用于连接请求监听的职责。例如，伙伴区域Y的一 个或多个GSM也可以接管为区域X生成事件的职责。作为另一个例子，除了为本地客户端生成度量之外，GSM也可能需要为其指定作为伙伴的区域计算度量，并且为驻留在那个区域的客户端发布这些度量。例如，当那个区域中的所有GSM都停用时，这可能是需要的。
注册
根据一种实施例，全局服务和可用于运行全局服务的数据库实例两者都向GDS框架注册。具体而言，对于全局服务，注册信息指定与每个全局服务相关联的一组属性。属性控制何时及何地启动服务、到它们的连接如何以及是否负载平衡、连接如何以及是否进行故障转移，等等。根据一种实施例，为服务注册的属性除其它事项之外还指定：
运行时负载平衡目标
连接时负载平衡目标
基于角色的服务
连接故障转移特性
优选/可用数据库
复制延迟
区域密切关系
对于数据库实例注册，当数据库加入数据库云时，或者在停机后重启时，数据库向云中的所有GSM注册。接收注册的GSM通过查询GDS目录确定哪些服务可以在被注册的数据库上启动来响应。那些服务然后在数据库服务器实例上启动，并且数据库服务器实例因此成为与要求那些全局服务的客户端的连接的候选者。
选择在哪建立连接的因素
如上所述，全局服务管理器负责响应来自客户端的连接请求选择建立哪些连接。根据一种实施例，全局服务管理器基于多种因素做出这种选择，以便在可用于全局数据服务框架100的数据库服务器实例 中高效地平衡连接负载。这些因素可以包括，例如：
哪些数据库服务器实例能够提供请求者要求的服务
哪些数据库服务器实例已被指定为用于请求者要求的服务的
“优选”实例
数据库服务器实例的性能度量
请求客户端所属的区域
数据库服务器实例所属的区域
区域之间的延时
所请求全局服务的区域密切关系
下文将更详细地描述每个这些因素。但是，这些因素仅仅是全局数据服务框架100在选择与哪些数据库服务器实例连接给定客户端时可以考虑的因素的例子。具体的因素以及赋予每个因素的权重可以随着实现的不同而变化。
区域密切关系
根据一种实施例，每个全局服务可以对一些区域具有比其它区域更强的“密切关系”。具体而言，在一种实施例中，每个全局服务有两个参数：“locality(本地性)”和“region_failover(区域故障转移)”，其允许用户指定服务与区域密切关系的程度。取决于这些参数的值，可以支持各种策略。例如，当locality参数设置为“anywhere(任何地方)”(缺省值)时，缺省的区域密切关系策略可以生效。在这种情况下，客户端连接请求被路由到能够为所请求服务满足负载平衡目标的最佳数据库。数据库的选择是基于其性能和其中客户端和数据库驻留的区域之间的网络延时。目标数据库可以从任何区域中选择。如果在不同区域中的数据库被平等地加载，则这个策略将优先级给予本地区域，即，客户端被连接到属于同一区域的数据库。只有区域间数据库性能的差异超过(overweight)网络延时时，才进行区域间的连接。
如果存在为其中locality参数设置为“anywhere”的服务指定的 优选/可用数据库，则在数据库池的级别维护服务基数。这意味着，如果服务在优选数据库上停用，则它将在可用数据库上启动并且池中服务提供者的数量将保持不变。当在可用数据库上启动服务时，优先级给予其中服务停止的区域中的数据库。如果在本地区域中没有这个服务的可用数据库，则从邻近区域中随机选择可用数据库。
当locality参数设置为“local_only(仅本地)”时，客户端连接请求被路由到能为所请求服务满足负载平衡目标的客户端区域中的最佳数据库。数据库的选择仅基于其性能。“local region only(仅本地区域)”服务可以同时在多个区域中提供，但是来自一个区域的客户端永远不会被连接到另一个区域中的数据库。
如果存在为其中locality参数设置为“local_only”的服务指定的优选/可用数据库，则在区域级别维护服务基数。这意味着，如果服务在优选数据库上停用，则它将在同一区域中可用数据库上启动，因此该区域中服务提供者的数量将保持不变。如果在本地区域中没有这个服务的可用数据库，则不采取任何行动并且降低服务基数。如果在本地区域中没有数据库提供该服务，则客户端连接请求被拒绝。这基本上意味着，如果服务与本地区域具有密切关系，则数据库的服务基数在每个区域中独立地进行维护。
当本地性参数设置为“local_only”并且指定了“region_failover”选项时，“affinity to local region with inter-region failover(具有区域间故障转移的与本地区域的密切关系)”的策略有效。该策略与“local_only”相同，唯一不同之处是，如果本地区域中没有数据库提供服务，则不是拒绝客户端的请求，而是将它转发到另一个区域中具有启动的所请求服务的最佳数据库(就负载和网络延时而言)。这种服务故障转移不会使得该服务在另一个区域中的可用数据库上被启动。不启动该服务的原因是，具有与本地区域的密切关系，数据库基数按每个区域进行维护并且不应该由于另一个区域中的服务故障而改变。如果区域的数据库由于区域间的故障转移而变得过载，则数据库管理员(DBA)可以手动地为该服务添加优选数据库。
数据库服务器实例性能度量
关于性能度量，在一种实施例中，每个数据库服务器实例定期地向全局数据服务框架100报告其性能度量。在一种实施例中，每个数据库服务器定期地向GDS框架100中的每个全局服务管理器发送其性能度量。在可替代的实施例中，每个数据库服务器实例初始向本地全局服务管理器报告其性能度量，并且每个全局服务管理器可以将其本地获得的性能信息传递到其它系统中的全局服务管理器。在后者的实施例中，数据库服务器实例110可以定期地向全局服务管理器210报告其性能信息，其中全局服务管理器210对于数据库服务器实例110是本地的。反过来，全局服务管理器210可以将来自数据库服务器实例110的性能信息传递到系统130和132的每个系统中的全局服务管理器。
从数据库服务器实例接收到的性能信息是全局数据服务框架100可以在GDS目录数据库270中维护的一种类型信息的例子。在一种实施例中，每个全局服务管理器接收、存储并且维护由GDS框架100管理的所有数据库服务器实例的性能度量的其自己的单独拷贝。
因为性能度量是由数据库服务器实例报告的，因此度量可能比如果简单地从外部源监视的数据库服务器实例的性能更精确。此外，利用数据库服务器实例报告其度量，GDS框架100不需要引发与这种外部执行的监视操作相关联的额外开销。虽然如此，但是本文描述的技术也适用于其中性能信息通过执行属于数据库云的数据库服务器实例的外部监视获取的系统。
由每个数据库服务器实例报告的具体性能度量可以根据实现而不同，并且本文描述的技术不限于任何特定的性能度量集合。作为例子，性能度量可以包括，但不限于：
CPU的数量和类型
当前CPU的利用率
存储器大小和当前的消耗
到存储系统的I/O带宽和当前的I/O负载
根据一种实施例，以上列出的度量按每个数据库实例进行收集。下面的度量按每个数据库实例以及在实例上运行的每个服务进行收集：
对数据库请求的平均响应时间
每秒执行的数据库请求的平均数量
并行数据库会话的平均数量
数据库请求等待繁忙资源所花费的平均时间
数据库请求等待锁(lock)、栓锁(latch)所花费的平均时间
区域间延时
如以上提到的，区域间延时可以是用来确定客户端应该与哪个数据库连接的因素之一。在一种实施例中，该确定所基于的延时值是两个区域中全局服务管理器之间的网络往返时间的估计。这些估计又可以基于在某个时间段上从多个消息中收集到的往返数据。
例如，每个全局服务管理器可以监视由与其它区域中的全局服务管理器通信引起的延时。因此，由全局服务管理器210发送到全局服务管理器202的消息引发的延时可以用作对应于系统130和134的区域(X和Z)之间的延时的指示。类似地，由从全局服务管理器206到全局服务管理器204和210的消息引发的延时分别指示系统132的区域Y和系统130及134的区域(X和Z)之间的延时。
要求的数据集
在其中不是所有的数据集都在所有的系统复制的情况下，客户端要求访问的数据集在确定哪个数据库服务器实例与客户端连接时是重要的因素。全局数据服务框架100可以以任何各种方式获得关于客户端要求访问的数据集的信息。例如，客户端的配置数据可以指示客户端要求访问的数据集。作为另一个例子，由客户端发送的连接请求可以包括指示客户端要求访问的数据集的元数据。根据一种实施例，客户端使用不同的服务名称来标识不同的数据集。
为了说明的目的，假设每个数据集A、B、C和D对应于分布式数据库中的数据项的不同范围。在这些情况下，由客户端154发出的请求可以指示客户端154要求访问的数据项的范围。基于在请求中指定的范围信息、与数据集相关联的范围、及数据集和系统之间的映射，全局数据服务框架100就能够确定哪些数据库服务器实例可以访问由客户端154要求的数据。如将在下文详细解释的，不能访问由客户端154要求的数据的任何数据库服务器实例会被取消作为客户端154的连接候选者的资格。
连接候选者选择
参考图3，它根据一种实施例说明了全局数据服务框架100如何响应来自客户端的请求以建立连接池。在步骤300，所有的数据库服务器实例都初始地被建立为连接候选者。在步骤302，全局数据服务框架100从连接候选者集合中去除那些不能访问由提交请求的客户端使用的数据集的数据库服务器实例。
为了说明的目的，将假设客户端154发出请求，并且客户端154只要求访问数据集A。由于所有的系统130、132和134都具有数据集A的副本，因此在步骤302没有数据库服务器实例从连接候选者集合中去除。但是，如果客户端154要求访问数据集B，则数据库服务器实例110将从连接候选者集合中去除，因为数据库服务器实例110属于不具有数据集B的副本的系统134。
在步骤304，能访问要求的数据集，但没有在运行要求的服务的实例从连接候选者集合中去除。实例可以使服务停止，例如，由于实例不是“优选的”并且已达到所期望的服务基数、由于复制滞后超过可接受的最大值、或者由于故障或计划中的维护。
在步骤306，基于区域密切关系选择候选者的子集。例如，如果所请求服务的locality参数被设置为“local_only”，则步骤306包括只选择那些与请求服务的客户端在同一区域的剩余候选者。另一方面，如果服务的locality参数被设置为“anywhere”，则步骤36可以选 择所有剩余的候选者，而不管它们所属的区域。
在步骤308，基于网络延时和数据库响应时间，从子集中选择一个或多个实例。例如，在一种实施例中，如果用于远程区域中的数据库的(网络延时+响应时间)小于本地区域中的数据库响应时间，则远程区域中的数据库实例被选择。
在步骤310，在客户端和剩余候选者之间建立连接。
在图3中示出的选择逻辑仅仅是在响应于连接请求而确定客户端连接到数据库云中可用的所有实例中哪些数据库服务器实例时，如何可以考虑各种因素的例子。实际使用的逻辑和考虑的因素可以根据实现而变化。例如，在可替换的实施例中，步骤308被省略并且在步骤306中选择的子集中对每个数据库实例建立了相同数量的连接。
运行时负载平衡
利用以上描述的技术，全球数据服务框架100可以智能地在分布式复制系统中可用的各个数据库服务器实例中平衡连接负载。但是，即使最优的连接分配也不能保证在运行时期间有一些数据库服务器实例将过载而其它的没有得到充分利用(underutilized)。
例如，假设已经建立最优的连接分配之后，所有的客户端152-156在其各自的连接池中包括到数据库服务器实例102的连接。如果所有的客户端为大多数或所有它们的数据库请求使用它们各自到数据库服务器实例102的连接，则数据库服务器实例102将变得过载，而剩余的数据库服务器实例104、106、108和110则没有被充分利用。
因此，根据一种实施例，除了连接负载平衡之外，GDS框架在其中连接池将客户端连接到提供同一全局服务的多个数据库服务器实例的情况下还支持运行时的工作请求平衡。在一种实施例中，对工作单元的连接选择由客户端侧的连接池做出，并且基于为服务示出数据库实例的相对性能的服务度量。GDS框架为客户端提供了对跨多个数据库的所有实例的这种度量。在一种实施例中，当计算度量时，GDS框架考虑实例负载、运行时平衡目标(服务时间，吞吐量)、 网络延时、及连接时负载平衡所基于的上述所有其它因素。
运行时负载平衡通过跨可用于提供服务的本地和远程数据库实例按需散布服务工作负载而为给定服务最小化响应时间或最大化吞吐量来提高性能。智能负载平衡算法保证了该框架优雅地对工作负载和资源的可用性变化做出反应。
在一种实施例中，为了促进运行时的负载平衡，全局数据服务框架100向客户端发送建议消息。例如，在一种实施例中，全局服务管理器202定期性向客户端152传送其中客户端152连接池中数据库服务器实例中的哪个数据库服务器实例是客户端152当前应当向其发送工作请求的数据库服务器实例。
用于任何给定客户端的适当的数据库服务器实例可以随时间基于各种因素而变化。例如，假设客户端152的连接池包括数据库服务器实例102、108和110。在时间T1，如果没有数据库服务器实例特别忙，则全局服务管理器202可以向客户端152指示应该使用数据库服务器实例102，因为数据库服务器实例102对于客户端152是本地的。但是，在时间T2，全局服务管理器202可以向客户端152指示应该使用数据库服务器实例108。例如，如果数据库服务器实例102在时间T2过载，则会发生推荐的这种变化。
全局服务管理器可以配置为以固定时间间隔或者响应于系统中的变化向客户端发送数据库服务实例建议消息。在其中建议消息是响应于变化而发送的实施例中，触发建议消息发送的变化可以包括，例如，在任何给定数据库服务器实例上的负载的显著变化、数据库服务器实例的去除或添加、由一个或多个数据库服务器实例产生的错误、区域之间延时的增加或减少，等等。
建议消息不必仅仅标识用于给定服务的单个数据库服务器实例。例如，对客户端的建议消息可以指示应该发送给多个数据库服务器实例中的每一个的客户端工作的百分比。因此，从全局服务管理器202发送到客户端152的建议消息可以指示客户端152应该将其工作的50％发送到数据库服务器实例102，其工作的35％发送到数据库服务 器实例108，及其工作的15％发送到数据库服务器实例110。在这种建议消息中给出的推荐在客户端保持有效，直到客户端接收到新的建议消息。新的建议消息可以指定不同的百分比集合和/或数据库服务器实例的不同集合。例如，对于客户端152的下一个建议消息可以指示客户端152应当发送其工作的10％到数据库服务器实例102、其工作的85％到数据库服务器实例108，及其工作的5％到数据库服务器实例110。
为了实现负载平衡目标，本文描述的运行时负载平衡技术可以与称为“连接引力(connection gravitation)”的另一种机制结合使用。连接引力在运行时将连接从对当前工作负载具有太多连接的实例转移到没有足够连接的实例。连接引力也可以在客户端代码中实现，并且在于2010年11月2日提交的美国专利申请No.12/938,545中进行了描述，其全部内容被结合于此。
“优选的”实例和“可用的”实例
根据一种实施例，用户可以为全局服务指定“优选的”数据库和“可用的”数据库。通常，全局服务由已为该全局服务指定为“优选的”数据库服务器实例提供。如果优选数据库之一不能提供服务，则服务被自动地重新定位到对那个全局服务标识为“可用的”数据库服务器实例之一。
因此，GDS框架根据指定的优选数据库的数量维护服务基数(提供服务的数据库数量)。当在任何时间都只有一个用于该服务的优选数据库时，单例(singleton)全局服务是全局服务基数的特例。在活动/活动数据库的情况下，对单例服务的支持对于保证只有当前数据的“主”拷贝可以被修改是尤其重要的。
当已为全局服务指定了优选数据库实例时，GDS框架100试图确保服务始终运行在已为该全局服务指定的所有优选数据库上。因此，优选数据库的数量被称为服务的数据库基数。必须为服务指定至少一个优选数据库。
当添加或修改服务时，用户也可以为该服务指定可用数据库列表。如果优选数据库之一不能提供全局服务，则GDS框架100将服务重新定位到可用数据库之一，以为该服务维持期望的数据库基数。如果失效的服务运行在单个数据库上，并且没有对该服务可用数据库，则GDS框架100向管理员发出不能提供该服务的警告。
具体而言，如果在优选数据库失效后，可用数据库的数量不足以为服务维持数据库基数，则实际的服务基数将降低到优选数据库的数量之下。此外，当例如由于网络中断不能通知GDS框架100关于全局服务在一个或多个数据库上的故障时，假定该服务仍然在那些数据库上运行。因此，为服务指定N个优选数据库只保证该服务将永远不会运行在多于N个的数据库上，但是它可以有时运行在少于N个的数据库上。
在一种实施例中，当用于特定全局服务的“可用的”数据库失效时，全局服务被重新定位到用于那个全局服务的另一个“可用的”数据库。在可替代的实施例中，服务可以从可用数据库重新定位回优选数据库。
在使用基于角色的服务的系统中，只有当数据库被列为对该服务优选或可用并且数据库的角色(无论它是首要的或备用的)对应于为该服务指定的角色时，才能在数据库上启动基于角色的服务。例如，在配置中可以在任何数据库上运行的服务，只要它是首要的，应该用角色“primary(首要的)”来指定，并且使配置中所有的数据库作为优选的。当在这些情况下指定优选/可用数据库时，应当考虑角色转换对服务基数的潜在负面影响。
全局单例服务
全局单例服务是在某一时间只在数据库池的一个数据库上提供的服务，即，其中数据库基数等于1的全局服务。单例服务保证只有主(首要的)数据副本能被更新，并且通过这样做，防止由于同时更新多个副本导致的数据损坏。
在使用基于角色的服务的配置中，只有首要数据库可以被更新，并且在任何时间最多只有一个首要数据库。因此，无论为服务指定了多少优选或可用数据库，都为具有角色属性设置为“primary”的任何服务隐含地提供了单例属性。
在多个主的环境中，用户可以跨多个数据库对其数据的主关系进行分区。在这种情况下，更新必须去其数据块的主站点。为了支持这个功能，应当为每个数据块建立单独的更新服务，并且为每个服务只指定一个优选数据库。
用于选择在运行时期间推荐的实例的策略
为了执行运行时负载平衡，连接请求被指向到分布式数据库系统中当前正在提供由请求客户端要求的服务的最优实例。在一种实施例中，实例基于其负载、负载平衡目标及客户端与服务器之间的网络延时进行选择。与本地服务器的密切关系程度应当受到重视。
如以上提到的，除非所有的本地服务器都过载并且远程服务器可以提供明显更好的服务质量，否则对全局服务的客户端请求被指向到与客户端在地理上靠近的数据库服务器。但是，在某些情况下，例如，为了利用本地服务器上的数据高速缓存，用户可能想始终将请求指向到本地服务器。根据一种实施例，GDS框架支持可以被指定为服务属性的各种类型的客户端-服务器密切关系。
处理复制滞后
由于性能原因，分布式数据库系统通常在数据库之间使用数据的异步复制。这意味着，在更新提交到首要数据库上的数据的时间和该更新在副本上出现的时间之间存在延迟的可能性。换句话说，副本会具有过时(stale)的数据，因为提交给副本的更新会滞后于提交给主数据库的更新。
根据一种实施例，GDS框架100允许应用区分提供实时数据的全局服务与由于复制滞后会返回过时数据的服务。对于可以容忍一定 程度滞后的应用，GDS框架100允许用户以秒为单位设置最大可接受的滞后值。在一种实施例中，用于复制滞后的容忍度利用全局服务参数lag来指定。
如果滞后是不可接受的，则对这种服务的请求将只转发到首要数据库或其与首要数据库同步的副本。如果滞后是可接受的并且指定了最大值，则服务请求被转发到滞后于首要数据库不超过指定值时间的数据库。如果数据库落后首要数据库长于设置允许的时间间隔，则该服务被禁用，并且通知连接到该数据库的客户端。在这种情况下，新的客户端连接被路由到满足该服务的滞后要求的数据库。
对于不能容忍任何复制滞后的应用，应该将全局服务配置为“lag”参数设置为0。对这种服务的请求将只转发到首要(主)数据库，或转发到其与主数据库同步的副本。
对于许多应用，只要过时数据是一致的，读取过时数据就是可以接受的。这种应用可以使用在任何数据库副本上运行的全局服务，无论复制滞后有多大。会返回具有无限制过时的数据的全局服务应该配置为具有“lag”参数设置为“ANY”。在数据库失效的情况下，这种服务可以被移动到启动该服务的任何其它数据库。“ANY”是用于该参数的缺省值。
如果服务的lag参数被设置为任意数值，则客户端请求可以只转发到滞后于首要副本不超过参数值时间的数据库。如果不存在这样的数据库，则连接请求将失败。
根据一种实施例，为了支持具有lag参数的全局服务，每个GSM定期地从数据库接收滞后值，并且如果在特定数据库上的滞后超过为服务指定的值，则产生“服务成员停用”事件。该事件将迫使该服务的客户端从数据库断开连接。对该服务的新请求将被路由到满足指定滞后值的数据库。
在可替代的实施例中，滞后值不发送到GSM。相反，每个数据库服务器为其服务监视滞后值，并且当超过用于服务的最大滞后值时，关闭它正在运行的任何服务。当用于该服务的滞后值在可接受的范围 内时，该服务可以被数据库服务器恢复。
在数据库失效的情况下，客户端连接可能被路由到满足为该服务指定的最大滞后值，但滞后于第一数据库的另一个数据库。这种“回到过去(going back in time)”对一些应用会产生数据一致性问题。这个问题可以以多种方式进行处理，诸如将情况通知给客户端。
根据一种实施例，通过使请求客户端告诉GSM其当前时间，就避免了“回到过去”的问题。基于这个信息，GSM可以确保为故障转移选择的数据库提供了足够当前以满足应用需求的数据。
处理故障
根据一种实施例，如果数据库不能提供服务，则客户端请求被转发到提供这个服务的另一个数据库。取决于服务基数和故障转移策略，数据库故障也会使得在另一个数据库上启动服务。
由于GDS框架提供了在发生故障时的灾难恢复和业务的连续性，因此该框架本身具有高可用性。因此，提供了在任何框架组件的单次故障、网络分区以及甚至整个站点故障的情况下允许GDS框架继续工作的机制(尽管可能在降级模式下)。由于高可用性和性能原因，关于参数和全局服务及GDS框架组件的状态的数据在多个存储库中被复制。当网络分区和/或数据库或GDSF组件的故障导致数据跨存储库的差异(discrepancy)时，触发自动的交叉检查，其检验并潜在地恢复在系统的不同组件中存储的数据的相互一致性。
根据一种实施例，在服务或数据库故障的情况下，在数据库上运行的服务故障转移到其中已启用但还没有运行的另一个数据库(假设数据库角色与服务角色匹配)。考虑故障转移目标时，“优选”数据库先于“可用”数据库考虑。在服务已从一个数据库实例转移到另一个之后，GDS框架100可以将建议消息发送给所有客户端，以指示对那个服务的将来请求应该到新指定的服务器。这些建议消息可以响应于服务的故障转移被立即发送，或者在故障转移后发送的下一个定期发送的建议消息中发送。
根据一种实施例，当服务移动到可用数据库时，在优选数据库重启时，GDS框架100不将该服务移回。如果需要，用户始终可以在重启后手动地将服务重新定位回优选数据库。这可以在无需终止活动会话的情况下优雅地完成。
如以上提到的，当locality参数被设置为LOCAL_ONLY，并且区域间的故障转移未被启用时，服务不能从一个区域中的数据库故障转移到另一个区域中的数据库。
根据一种实施例，所有的全局服务管理器监视数据库云中所有数据库上的服务可用性。当由于故障不能再提供服务时，注意到它并且连接到目录数据库的第一个GSM将尝试在可用数据库上启动该服务。如果服务故障转移由于没有提供这种服务的可用数据库而无法完成，则GSM在目录数据库中创建关于不能维持指定的服务基数的警告。警告可以触发发送到池管理员的自动通知。
如果GSM不能连接到云目录，则GSM不能执行自动的服务故障转移。在这种情况下，GSM可以在它能够连接到的云数据库上创建警告。
硬件概述
根据一种实施例，本文所描述的技术由一个或多个专用计算设备实现。专用计算设备可以是硬连线的以执行所述技术，或者可以包括诸如被永久性地编程以执行所述技术的一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)的数字电子设备，或者可以包括编程为按照固件、存储器、其它储存器或者其组合中的程序指令执行所述技术的一个或多个通用硬件处理器。这种专用计算设备还可以合并定制的硬连线逻辑、ASIC或FPGA与定制的编程来实现所述技术。专用计算设备可以是台式计算机系统、便携式计算机系统、手持式设备、联网设备或者结合硬连线和/或程序逻辑来实现所述技术的任何其它设备。
例如，图4是说明本发明的实施例可以在其上实现的计算机系统 400的框图。计算机系统400包括总线402或者用于传送信息的其它通信机制，以及与总线402耦合用于处理信息的硬件处理器404。硬件处理器404可以是例如通用微处理器。
计算机系统400还包括耦合到总线402用于存储信息和要由处理器404执行的指令的主存储器406，诸如随机存取存储器(RAM)或其它动态存储设备。主存储器406还可以用于在要由处理器404执行的指令执行期间存储临时变量或其它中间信息。当存储在处理器404可访问的非暂时性存储介质中时，这种指令使计算机系统400变成为执行指令中所规定的操作而定制的专用机器。
计算机系统400还包括只读存储器(ROM)408或者耦合到总线402的其它静态存储设备，用于为处理器404存储静态信息和指令。提供了存储设备410，诸如磁盘、光盘或固态驱动器，并且耦合到总线402，用于存储信息和指令。
计算机系统400可以经总线402耦合到显示器412，诸如阴极射线管(CRT)，用于向计算机用户显示信息。输入设备414，包括字母数字和其它键，耦合到总线402，用于向处理器404传送信息和命令选择。另一种类型的用户输入设备是光标控制416，诸如鼠标、轨迹球或者光标方向键，用于向处理器404传送方向信息和命令选择并且用于控制显示器412上的光标运动。这种输入设备通常具有在两个轴，第一个轴(例如，x)和第二个轴(例如，y)，中的两个自由度，以允许设备在平面内规定位置。
计算机系统400可以利用定制的硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实现本文所述的技术，这些与计算机系统相结合，使计算机系统400或者把计算机系统400编程为专用机器。根据一种实施例，本文的技术由计算机系统400响应于处理器404执行包含在主存储器406中的一条或多条指令的一个或多个序列而执行。这种指令可以从另一存储介质，诸如存储设备410，读到主存储器406中。包含在主存储器406中的指令序列的执行使处理器404执行本文所述的过程步骤。在备选实施例中，硬连线的电路系统 可以代替软件指令或者与其结合使用。
如在本文所使用的，术语“存储介质”指存储使机器以特定方式操作的数据和/或指令的任何非暂时性介质。这种存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如光盘、磁盘，或固态驱动器，诸如存储设备410。易失性介质包括动态存储器，诸如主存储器406。存储介质的常见形式包括，例如，软盘、柔性盘、硬盘、固态驱动器、磁带，或者任何其它磁性数据存储介质，CD-ROM，任何其它光学数据存储介质，任何具有孔模式的物理介质，RAM、PROM和EPROM、FLASH-EPROM、NVRAM，任何其它存储器芯片或盒式磁带。
存储介质与传输介质截然不同但是可以与其结合使用。传输介质参与在存储介质之间传送信息。例如，传输介质包括同轴电缆、铜线和光纤，包括包含总线402的配线。传输介质还可以采取声或光波的形式，诸如在无线电波和红外线数据通信中产生的那些。
各种形式的介质可以参与把一条或多条指令的一个或多个序列携带到处理器404供执行。例如，指令最初可以在远端计算机的磁盘或固态驱动器上携带。远端计算机可以把指令加载到其动态存储器中并且利用调制解调器经电话线发送指令。位于计算机系统400本地的调制解调器可以在电话线上接收数据，并且使用红外线发送器把数据转换成红外线信号。红外线检测器可以接收在红外线信号中携带的数据，并且适当的电路系统可以把数据放在总线402上。总线402把数据携带到主存储器406，处理器404从该主存储器406检索并执行指令。由主存储器406接收的指令可以可选地在被处理器404执行之前或之后存储在存储设备410上。
计算机系统400还包括耦合到总线402的通信接口418。通信接口418提供耦合到网络链路420的双向数据通信，其中网络链路420连接到本地网络422。例如，通信接口418可以是综合业务数字网络(ISDN)卡、电缆调制解调器、卫星调制解调器，或者提供到对应类型的电话线的数据通信连接的调制解调器。作为另一个例子，通信 接口418可以是提供到兼容的局域网(LAN)的数据通信连接的LAN卡。无线链路也可以实现。在任何此类实现中，通信接口418都发送和接收携带表示各种类型信息的数字信号流的电、电磁或光信号。
网络链路420通常通过一个或多个网络向其它数据设备提供数据通信。例如。网络链路420可以通过本地网络422提供到主计算机424或者到由因特网服务提供商(ISP)426操作的数据设备的连接。ISP 426又通过现在通常称为“因特网”428的全局分组数据通信网络提供数据通信服务。本地网络422和因特网428都使用携带数字数据流的电、电磁或光信号。通过各种网络的信号以及在网络链路420上并通过通信接口418的信号是传输介质的示例形式，其中信号把数字数据带到计算机系统400或者携带来自计算机系统400的数字数据。
计算机系统400可以通过网络、网络链路420和通信接口418发送消息和接收数据，包括程序代码。在因特网例子中，服务器430可以通过因特网428、ISP 426、本地网络422和通信接口418发送对应于程序的所请求代码。
所接收的代码可以在其被接收时由处理器404执行，和/或存储在存储设备410或其它非易失性储存器中，供随后执行。
在前面的说明书中，本发明的实施例已经参考众多的具体细节进行了描述，这些细节可以从一种实现到另一种实现变化。因此，说明书和附图应当在说明性而不是限制性的意义上考虑。本发明范围的唯一且排他指示，以及申请人预期作为本发明范围的内容，是由本申请产生的权利要求集合的字面和等效范围，以这种权利要求产生的具体形式，包括任何后续的校正。