CN101465877A - 分布式数据库***中的负载分布 - Google Patents

分布式数据库***中的负载分布 Download PDF

Info

Publication number
CN101465877A
CN101465877A CN200810184171.9A CN200810184171A CN101465877A CN 101465877 A CN101465877 A CN 101465877A CN 200810184171 A CN200810184171 A CN 200810184171A CN 101465877 A CN101465877 A CN 101465877A
Authority
CN
China
Prior art keywords
server
look
subregion
state
active
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN200810184171.9A
Other languages
English (en)
Other versions
CN101465877B (zh
Inventor
F-U·安德森
T·霍斯费尔德
S·厄克斯纳
P·特兰-贾
M·迪尔利
G·内泽尔特
W·沙伊德尔
K·图奇库
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Siemens Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Publication of CN101465877A publication Critical patent/CN101465877A/zh
Application granted granted Critical
Publication of CN101465877B publication Critical patent/CN101465877B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42—Loop networks
    • H04L12/437—Ring fault isolation or reconfiguration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/742—Route cache; Operation thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4523—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using lightweight directory access protocol [LDAP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1031—Controlling of the operation of servers by a load balancer, e.g. adding or removing servers that serve requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了用于分布式数据库***中的负载分布的方法。所述方法包括：确定网络中的状态改变，所述网络包括多个服务器及主服务器；在所述主服务器处计算第一查找表，所述第一查找表表示在所述多个服务器中的活动服务器中，第二查找表的分布情况；将所计算的第一查找表分发至每个活动服务器；以及基于所述第一查找表，在所述主服务器处生成经修改的第二查找表的分区。

Description

分布式数据库***中的负载分布
技术领域
本发明涉及分布式数据库或应用服务器***，特别是这样的***的前端层。
背景技术
在分布式数据库***中，例如，数据被分布在几个数据库服务器上而不是位于一个单独的服务器中，因而需要进行查找，以便将对于特定数据项的请求路由到存储该项的匹配服务器。这通常很大程度以与多层Web服务器应用方式相同的“前端”服务器来实现。“前端”服务器与保存实际数据(或应用)的“后端”服务器是分离的。
针对数据库而言，指向后端数据库服务器的指针被存储在所谓的“查找***”或“前端***”中。这些指针通常具有<关键字，数值>的格式，其中关键字是用于后端数据库的有效搜索关键字，而数值是对应的数据集所处的后端服务器的地址。
当查询请求(例如，LDAP(轻量级目录访问协议)命令)被送达到分布式数据库***的时侯，首先在前端***中对其进行解析，然后将其转发到后端***中相应的地址，在那里将对其进行处理。
在移动运营商环境中，存在若干可以使用这样的多层方法的情况，例如，HLR(归属位置寄存器)、Radius(远程认证拨入用户服务)、计费、网络管理、IMS(因特网协议多媒体子***)和Web服务器。
近来，在移动网络数据库设计中有一种趋势是仅创建一个逻辑上的数据库，而在物理上，则运行在大量的服务器上，并且还统一使用了不同类型的数据库，例如，HLR、Radius、OAM DB(操作和维护数据库)、NM(网络管理)DB、计费DB，等等。
发明内容
本发明的目的在于：例如，当将新的设备添加到***或***的设备发生故障的时候，在不具有完全冗余的分布式存储***中提供一种负载分布机制。
这是通过所附权利要求中所限定的方法和服务器来实现的。本发明也可以作为计算机程序产品来实现。
在不具有完全冗余的分布式存储***(即其中并不是在每台服务器上都存在每个数据集的副本)中，单个或多个服务器故障很可能导致***负载的非均匀分布并且还可能丢失数据。如果存储了特定数据集的所有服务器都发生故障(这些服务器的数量取决于***的存储和冗余策略)，则会发生后者的情况。
然而，即使在这样的分布式数据存储***中没有丢失数据，负载也不再是均匀分布的，这对***来说可能仍然是个问题。根据服务器的规模，必须处理较大负载的那些服务器可能变得过载或者可能仅能够以较差的质量提供其服务。
本发明提供了一种自我重组机制，自动地重组分布在分布式数据库或应用服务器***(特别是分布式查询路由***)中的负载。在现有技术的非完全冗余***中，不均匀负载分布的情况不是通过***自身而是通过人工干预来纠正的。
相比而言，本发明提供了一种自组织体系结构，其有助于减少发生负载不均等的时间。本发明的自组织体系结构需要较少的人工控制和干预。
本发明可用于当负载(例如新的服务器)被添加到前端数据库服务器的网络时的情况，或者当网络中的一个服务器突然发生故障时的情况。根据本发明，并不是在每个前端服务器中都存储完整的查找表(即指针的集合，以指示数据项在后端服务器中所处的位置)，而是每个前端服务器仅需要保存查找表的一部分，并且第一查找表作为一种“分区表(partitioningtable)”，来指示哪个前端服务器负责在后端服务器中存储的哪个数据段，即查找表的哪个部分位于哪个前端服务器。
根据本发明的实施例，每个前端数据库服务器都被分派ID(特征值)，并且前端数据库服务器的网络环中具有最低ID的那个服务器被认为是环主(ring master)。无论何时将服务器添加到网络或者服务器发生故障，环主都会获得其它服务器的通知或自己注意到该情况。环主依据当前可使用的服务器来计算新的“分区表”，来指示哪个服务器负责在后端服务器处存储的哪个数据段，即对于每个服务器来说，在“分区表”中的起点和终点，或者在“分区表”中每段之间的边界。
环主将新的“分区表”分发至每个服务器。每个服务器更新其各自的“分区表”并且在完成更新之后向环主发送确认。这样的更新过程可以由每个服务器在周期性的循环中实现。
环主向每个服务器发送“锁定”指令。此后，每个服务器仍然可以完成正在进行的写过程并且对读请求进行响应，但其不能响应任何新的写请求。然后每个服务器遵循“锁定”指令，完成任何未完成的本地“写”操作(如果有的话)，并且向环主确认其被锁定。
环主指示每个服务器切换到新的分区表。每个服务器在其切换之后向环主发送确认。最后，环主将所有服务器解锁。
在具有大型(即数以百万计的条目)查询表的分布式查询路由***中，其主要问题是这些查询表在参与的服务器之间的同步，特别是当参与的服务器发生故障或当新的服务器加入***时。由此得到，在服务器发生故障之后或者当已经添加了新的服务器时，另一问题出现了，即如何使服务器的负载均等。本发明通过三个阶段的同步机制解决了这些问题，该机制还考虑了多种可能发生的变化。
如上所述，这些问题通过首先选择“环主”服务器来解决，其中，该“环主”服务器负责获取整个环的状态以及将ID范围映射到负有责任的服务器。特别地，考虑了多种变化，例如，服务器故障或添加新的服务器，从而允许仅在特定条件下进行重组。
本发明提供了一种分布式机制，其在***改变之后(例如一个或多个服务器发生故障或者新的服务器被附加到***中)均匀地分布负载。该分布式机制可以基于查找***，其使用基于散列表(又称哈希表)的寻址方案来确保每个服务器以稳定状态来存储相同的数据量，从而均匀分布每个服务器接收到的查询量。在***状态发生改变的情况下，本发明的重组机制将向仍在活动状态或操作中的每个服务器自动地分派新的数据范围。
新的范围同样具有几乎相同的大小并且反映新的情况，即，所剩的或添加后的服务器的数目。在已经计算了哪个服务器将负责整个数据集的哪个部分之后，并且在每个服务器都已经下载了这些范围内的数据之后(考虑了在改变之前其已经具有的本地可用的数据)，***可以切换到负载平衡和稳定的新状态。
根据本发明，在重组阶段期间待传送的数据量保持尽可能的小。
附图说明
图1根据本发明的实施例示出了存储在后端设备和前端设备中的数据段之间的映射；
图2示出了在前端设备移除或故障的情况下图3中的前端设备与数据段之间的映射上的改变；
图3示出了在一个前端设备移除或故障之后前端设备负责的区间(interval)；
图4根据本发明的实施例示出了说明在标识符空间中的前端设备和数据布局的示意图；
图5根据本发明的实施例示出了说明在标识符空间中前端设备的定位的示意图；
图6根据本发明的实施例示出了说明重组阶段的示意图；
图7示出了说明在图6的重组阶段中环状态之间的状态和转移的状态图；
图8示出了在图6的重组阶段中，服务器的状态之间的状态和转移；
图9根据本发明的实施例示出了说明服务器重定位过程的示意图；
图10示出了说明在不同状态下的服务器之间路由的示意图；
图11示出了说明在不同状态下的服务器之间路由的示意图；
图12根据本发明的实施例示出了说明服务器的示意框图；以及
图13根据本发明的实施例示出了一示意图，其说明了当以冗余因子为2或3时，第二查找表的分区及第二查找表的分区与服务器之间的关系。
具体实施方式
根据本发明的实施例，假设存储***的内容是由大量文档或文件组成的，并且仅部分冗余地被存储在多个服务器上，这多个服务器在其自身间转发查询，以便在限定的查询转发次数的上限之内对其进行解析。假设所有文档或文件同等地被查询，例如，这是HLR的典型特征，那么这样的***中的负载分布是通过在一组服务器中均匀地分布存储内容来实现的。
这可以通过根据分布式散列表(DHT)的原理来存储数据而实现，其意味着所有的文档以及服务器的地址都被通过散列变换(hashed)映射到标识符空间，并且文档被存储到具有仍大于其自已的ID的最低ID的服务器上。因此，每个服务器负责标识符空间的一段连续的范围以及落入该范围的文档。服务器形成一种用于确定特定文档的存储位置的逻辑结构(所谓的覆层(overlay))。
查找数据的总量并不是完全冗余地存储在每个前端节点(这样在前端节点中将需要大存储量)，而是被分区并部分冗余地分布在构成查找***的所有前端设备中，从而将每个前端设备上所需要的存储量降低至仅一部分(该部分取决于冗余量)。
要注意，举例来说，术语“设备”包括诸如应用、服务器和节点这样的实体。
可以提供两个数据结构(查找表)和两个(查找)过程，以便路由到达任意前端设备的输入查询，例如，通过自动切换。
第一数据结构是小型路由或“分区”表，其被称为第一查找表。其含有这样的表，即该表的第一列具有分布式数据库***的已知前端节点的ID，并且第二列显示前端节点负责哪些区间。这些区间是通常被称为“散列空间”的一些部分，例如，从0到2n的所有的数。这些区间被均匀地分隔，以便使每个前端设备上的负载都相同。如果一组前端设备在处理负载能力上不同，那么还可以根据设备的处理负载能力来划分这些区间。根据散列函数的结果(即，从数据库查询消息获得的输入数据的变换)，从第一数据结构立即可导出该查询属于哪个区间，并且相应地导出哪个前端设备负责该查询。此后，开始第二查找过程，这涉及第二数据结构。
图1示出了数据段(其存储在后端设备中)与前端设备之间的映射。具有ID(从ID1到ID8)的前端节点负责包括从1到2n-1的所有数的散列变换ID空间中的区间。对于在任意一个前端节点处所接收的查询消息中所含的MSISDN进行散列变换，从而产生散列变换ID空间中的值。例如，前端节点ID4接收具有MSISDN+49(170)123456的查询消息，其查询用户简档。对该MSISDN进行散列变换，从而产生ID空间中的值，其属于前端节点ID1负责的区间(如散列ID空间中图1的左上部分中黑三角形所说明的)。因而，节点ID4从第一查找表(其存储在ID1到ID8的每个节点处)得知：前端节点ID1存储了可用于推导出后端节点(其含有对应于MSISDN+49(170)123456的所查询的用户简档)所需要的第二查找表的部分。
图2示出了在前端设备移除或故障的情况下图1中的查找数据段与前端设备之间的映射上的改变。如图2所示，将前端节点ID6移除。在重组之后，曾由前端节点ID6负责的数据集(即数据段)被部分重排并分布到其它的前端节点。现在仅有七个区间而不是图1中的八个区间。然而，散列变换ID空间再次在前端节点之间均匀分布。
要注意，由于为了保持说明和描述的简化，图1和图2并未示出查找表和/或责任的冗余。
图3示出了在移除前端节点ID6之前(图3a)和之后(图3b)前端节点的职责区间。
第二数据结构(即第二查找表)通常是具有数以百万条目的大型查找表，然而，路由或分区表(即在第一过程中使用的第一查找表)仅含有与前端节点一样多的条目。第二数据结构由含有关键字的列和含有数值的一列构成。如上所述，例如，关键字可以是MSISDN的散列变换，并且数值可以是HLR后端服务器的节点ID。(散列变换意味着将散列变换函数应用于诸如MSISDN的输入值。)当在本地搜索时，前端节点对MSISDN进行散列变换，并依据变换结果，找到对应的后端服务器节点ID。这是可能的，因为所描述的第二查找表结构被存储在标准“散列表”存储器数据结构中。而后，前端服务器将从所确认的后端服务器中检索数据，并且将其返回给接收该查询的前端服务器。
图3示出了来自图1和图2的职责区间，以及在移除前端节点ID6之前和之后设备的职责重叠处的箭头标记。其中，在(a)旧的区间与(b)新的区间之间存在重叠，显然，没有数据从其它设备传送到本地设备。
假设我们有8台前端服务器(图1，3a)。一台故障或者添加了一台，这使得活动服务器的总数变成7(图2，3b)或9(并未示出该例；然而，假设图3b示出了向7台服务器添加第八服务器的情况，那么这种情况便在图3b、3a中反映出来)。在这样的情况下，主服务器(MS)在每台活动服务器中重新分配指针(第二查找表)。举例来说，该机制像这样：MS从其(当前)路由表(第一查找表)而获知整个(散列变换的)地址空间。因此，通过重新划分地址空间(例如地址空间/7或9)，生成新的第一查找表，换句话说，每台活动的前端服务器都具有新的对应的责任范围。主服务器向所有的活动服务器分发新的路由表。基于旧的和新的路由表，每台活动的前端服务器应知道可以从哪里获取一些指针，以便依照新的路由表来更新其当前的第二查找表。换句话说，主服务器在其计算之后为活动的前端服务器(置于(仅作为建模方法)散列ID空间的环上)的“环”分发新的环状态。该新的状态以从(旧的服务器地址&ID)映射到由每台服务器的相应ID(起始ID和结束ID)所限定的新的地址空间的形式而出现。完成的映射被传输到每台前端服务器。因此，新添加的前端服务器可以从该映射提取旧的路由表并且确定其可以从哪些服务器检索其在新的状态下所需要的指针。
因而，除了路由信息本身之外，所计算的第一查找表还包括所检测到的状态改变前后的第一查找表之间的映射信息。
图3主要涉及路由表，即两种数据结构中的第一种以及过程的阶段。
如上所述，基于散列变换的寻址方案可以用于确保：由查找查询(例如LDAP请求)生成的负载被均匀地分布，并且可以找到存储在前端设备上的每个查找条目。
通过对原始数据库查询(例如，用户数据库中的MSISDN)的搜索关键字进行散列变换，将每个数据项置于覆层中。该散列变换值同时是查找表中对应的查找条目的<关键字，数值>对中的关键字。另外，每个设备具有其自己的覆层地址，该地址是其在ID空间中的位置。所有设备的地址确定每个设备必须存储的查找数据的总量。图4示出了在ID(标识符)空间中的设备和数据布局。每个对象被存储在对象散列变换值随后的第一对等体(peer)。
图4中所示的是散列函数的基本工作机制，如在例如当前情况下结合DHT(分布式散列表)所使用的。该机制将输入值(在该例中是服务器的IP地址或文档名称)映射到一共同域或上域(co-domain)，这在DHT上下文中被用作标识符空间。在该图中，散列函数的上域是线性空间，范围从1到2m。原则上这是与用作图1和图2中本发明的例子的[1；2^n-1]区间同样可行的值。其它变通情况，诸如两个坐标，也是可能的。
要注意的是，在该图中，与本发明相比，通过相同的函数将服务器映射到标识符空间。然而，在很多DHT中这是已知且用过的实践，其中使用了大得多数目的服务器，并且因此需要快速、无冲突和便宜的ID生成。由于很多散列函数的随机性，因此当使用该方法的时候，对服务器的定位也是随机的，部分程度上，这同样需要更多数目的服务器来补救。然而，根据本发明，这并不成立，这就是为什么在本发明中服务器并不被随机放置，而是遵循所描述的算法。在本发明中，查找条目的布局也是基于将散列函数应用于所查询的数据库关键字来实现的，因为条目的真正数目足以导致服务器中条目的均匀分布。
然而，该图中所示出的另一原则是服务器上文档(该图的例子中是xml文件，来自本发明的第二表的查找条目)的布局。通常，诸如DHT的结构化覆层从以下事实获取相对而言比较好的搜索性能：文档/数据对象具有对其负责的一个特定的服务器/节点。该责任关系通常可以易于从对象和服务器的散列变换值(ID)导出。因此，如果要搜索对象，仅仅必须定位和查询应当负责该对象(如果其存在的话)的服务器。在该图的例子中，用于将服务器分派给数据对象的规则是：将对象存储到具有比该对象的散列变换值高的最低散列变换值(ID)的服务器。这在本发明中是相同的(如图5所示)。例如，具有散列变换值23的文档(对象z)被存储在具有继该散列变换值之后的ID的服务器上，在这种情况下，服务器x具有散列变换值/ID42。这是应当通过该图直观得出的基本原理。
关于节点ID的生成和分派有不同的选项。一种方法是对设备的IP地址进行“散列变换”。结果将是比特串，例如128或256比特。即使两个IP(因特网协议)地址非常类似(例如，10.10.10.1和10.10.10.2)，散列输出也完全不同并且分布在包括所有可能的数字的散列变换空间中大的距离上。
为了将负载平衡引入到该***，每个设备应当存储近似相同数量的查找数据，或者依照设备自身条件来平衡查找数据的数量。这确保在每个节点上的存储使用是相等的，从而允许在所有的节点上安装较少的存储器，并且每个节点解析相同的查询量。为了达到这个目的，前端设备被等距离地放置在标识符环上。图5中示出了这样的覆层。前端设备901-904被放置在标识符圆905上，其在设备901-904之间等分。查找表条目被存储在具有比其自己的ID高的最小ID的设备上。对n个设备来说，相邻设备的ID应当具有1/n的ID范围的距离。利用等分的标识符圆905，标识符空间在设备901-904之间被等分，如图5中所示。
然而，由于该***对查询该数据库的外部应用来说应当是透明的，因此每个前端服务器设备必须能够接收对后端***中任何数据集的查询，并且相应地必须能够解析这些查询。由于一个前端设备并不保存完整的查找数据，因此为了到达给定查询的查找条目被定位的远程设备，引入了一种内部路由机制。该路由机制并不是本发明的说明书的一部分。
根据上述寻址方案，每个前端设备存储了较小的第一查找表作为路由表，包括***中所有的前端设备，以及作为地址的其覆层ID。对于给定的数据库查询来说，通过对数据库搜索关键字进行散列变换并且检索具有高于关键字散列变换结果的最低ID的前端设备，前端设备可以判定哪个其它的前端设备负责对应的查找条目。
如果一个或几个前端设备发生故障，则破坏了在标识符环中，通过等距分布(如图5所示)前端设备地址而引入的负载平衡。在这种情况下，为了利用如图2所示的剩余节点实现均匀的负载分布，***起动如下所述的重组过程。
如上所述，假设大量的文档，这些文档基本上均匀分布在标识符空间中。这意味着服务器ID(即其在标识符空间中的“位置”)与其前任者和后继者的ID直接影响一个服务器必须存储的数据量。因此，为了保证较小型***的负载分布，这些服务器并不随机地而是例如通过散列变换而被等距放置在标识符空间中。
然而，由于服务器故障或者添加了新的服务器，标识符空间的合理分区首先被破坏了，从而导致负载不均等。尽管服务器的数目改变了，然而为了重新建立具有均等负载分布的状态，其在标识符空间中的位置及其负责的数据必须被修改。下面将描述实现该任务的本发明的实施例。
根据本发明，为了起动用于分布式查询路由***的重组机制，以及使新的节点能够成为该***的一部分，并且对于环主来说，为了创建第一环状态将包括的初始节点集，需要某种自举过程。
例如，一旦人工创建了初始节点表，并且此后，***将自动工作。另外，可以使用IP广播机制来向所有的本地节点发送IP分组，并且让它们相应地应答，以便环主获知其它节点的可用性。可以为***使用专用的、已知的小范围的IP地址而不是进行广播。可以通过向每个地址发送单独的分组来检查该范围。
新的节点必须知道至少一个其它节点的IP地址。这可以人工配置，或者，再次使用IP广播来找出有关的其它节点。
关于对改变的状态的检测，存在两种不同情况的环状态：
1)正常状态：环主最初分布了起始状态，状态并未发生变化。在该状态期间环主不做任何事情。
2)改变的状态：每当节点检测到其不再能与另一节点联系时，其仅向环主发信号通知故障。两个子情况是重要的：
2a)环主自己不再工作：在这种情况下，选择新的环主，例如具有最低ID的前端节点。然后接下来是2b)。
2b)环主仍然有效。其计算新的状态并且向***的所有节点发送内容ID区间的对应责任表。此后，该***再次处于正常状态。
如上所述，如果由***中任何一个活动服务器通知网络状态的改变，则发生重组。该改变可以是一个或几个新服务器进入***，或者一个或多个服务器发生故障，或者二者兼有。对于负载平衡，服务器故障是更为关键的情况，因为在这里由标识符空间所创建的覆层中的负载平衡被破坏了，并且一些仍然活动的服务器比其它的服务器被更频繁地使用。相比之下，服务器的加入并不直接危及查找***的功能。接下来，将描述网络状态改变的一般情况，并且仅当需要不同处理时的情况被分辨出来。
根据本发明的实施例，完整的重组过程被划分成如图6所示的三个基本阶段，这三个基本阶段在状态改变的每种情况中实施。阶段I涉及从网络状态改变到存储在网络的每个服务器上的数据的重新分布的过程。阶段II确保完成所有的写动作，而阶段III负责所有服务器切换到新的且稳定的网络状态。
下面描述的阶段导致在重组期间可能的不同的服务器和环状态。图7说明了环状态图，并且图8说明了服务器状态图。
阶段I：在覆层中的数据位移(data shift)
第一阶段开始于在覆层处的一个或几个活动的服务器注意到网络状态已经发生改变(S1)。如图7中所示，环状态从状态“平衡”S20改变到状态“注意到改变”S22，其是在事件“状态改变”S21的情况下环状态“不平衡”S40的一部分。
在服务器加入(即新服务器)的情况下，这是通过由新服务器通知任何一个活动服务器来实现的。新服务器被认为是活动的，即工作的，但只要尚未完成整个重组过程，它们就不会成为网络中的一员。从这一点上讲，它们也未参与数据查询的解析过程。
如图8中所示，通过网络中任意节点处的报告S52，处于状态“活动，没有被集成”S50的服务器从状态“被初始化”S51变到状态“被报告”S53。在服务器超时的情况下，其再次从S53变到S51。通过接收S55新的环状态，服务器从S53变到状态“具有未来的ID”S56。服务器然后请求数据，并且当所请求的数据完整S57时，从S56变到状态“具有未来的ID+数据”S58。当服务器从环主接收到锁定命令S59(将在阶段II描述)时，其变到状态“锁定”S60。当从主机接收到切换命令S61(将在阶段III描述)之后，服务器变到状态“活动，集成/解析”S80中的状态“最新的”S62。在该状态中，当状态发生改变并且新的环状态被接收S63时，服务器进入到状态“具有未来的ID”S64。在状态S64中，如果状态再次发生改变并且再次接收新的环状态S65，则服务器重新进入到状态S64。服务器请求数据，并且如果所请求的数据完整S66，则服务器进入到状态“具有未来的ID+数据”S67。当服务器从环主接收到锁定命令S68(将在阶段II中描述)时，其进入到状态“锁定”S69。在该状态中，当服务器从环主接收到切换命令S70(将在阶段III中描述)时，其再次进入到状态S62。
可以通过来自网络中正常查询通信量的超时或通过连接丢失来检测服务器故障。诸如附加保持有效这样的消息的其它机制是有可能的，但并不认为是必须的。
网络或环中注意到这种改变的每个服务器向环主(其被定义为整个覆层环中具有最低ID的活动服务器)报告该改变(S2)。每个报告均含有改变的种类(加入/离开)、已经改变的服务器的IP地址及其覆层ID。所观察到的改变也被存储在观察该改变的服务器上。每当该服务器检测到另一改变时，其便会报告其观察的全部集合(旧的和新的)。这确保了如果在报告最后一次的观察结果之前主服务器或环主本身出现故障，那么新的环主会获得有关网络状态的完整信息。否则，发送到旧的环主的观察结果将丢失。可以通过环主来对来自相同或来自不同服务器的冗余报告进行关联。
除了报告和存储状态改变之外，一般的服务器并不采取任何进一步的措施。其继续其正常的查找和转发操作，直到其从主服务器接收到其它命令。
如图7中所示，假使将所有的改变都报告S23给环主，那么环状态便从状态S22变到状态“主机被完全通知”S24。假使注意到新的改变S25，那么环状态便切换回状态S22。当环主被完全通知的时候，其计算新的环状态并且将新的环状态分布到所有的活动节点。
当主服务器(即环主)接收到第一改变报告的时候，其起动本地定时器，并且每当其接收到新的变化通知时就重置该定时器。该定时器被称为重组滞后定时器(RHT)。一旦RHT达到预置值(其可以由操作者设置)，环主便基于与仍然活动的服务器有关的信息开始计算新的环状态(S3)。该RHT确保在较短时间内的多个改变在计算中被视为整体的一部分。否则，每个有关新的变化的通知都将触发新的计算以及后续消息。另外，如果服务器仅出现瞬时的问题(例如，负载尖峰)并且仅产生少量超时，则该RHT可以用于防止重组过程的发生。然而，这里假设已经失去网络连接的服务器已发生了永久故障。如图8中所示，当服务器发生故障的时候，其从状态S50或状态S80进入到状态“出故障”S71。
稍后将描述在RHT已经完成其倒计时之后发生的改变。
下面将详细描述新的环状态的计算过程。其返回映射，为每个服务器分派新的覆层ID。该ID是在重组之后服务器将具有的ID。然后将该完全映射广播(S4)到参与重组的每个服务器，即环主已知的处于活动状态S50或S80的每个服务器。对该映射的接收必须被每个服务器确认，因为对含有未来环状态的该消息的接收触发覆层中每个服务器的下一步骤。直到此时，除了环主之外的每个服务器都仅报告所观察的网络改变，否则就仅进行其常规转发和查找操作。
伴随该消息而接收的信息允许每个服务器计算其将在未来的环中涵盖的数据集的基本范围(primary range)以及总范围(total range)。基本范围是从该服务器的新前任者到其自己的新ID的范围，而总范围是被冗余因素指定的更大的范围。
基于此，每个服务器都可以根据新的***状态来确定，依据该总范围中所应有的数据，其第二查找表中缺少哪些数据，以及服务器已有哪些数据。如图8中所示，在状态S64中，服务器请求缺少的数据(图6中的S5)。该缺少的数据通常也是一组(更小的)范围，其反过来又可以与负责的服务器相关联，其中该数据当前被存储在这些负责的服务器上(倘若尚未发生数据丢失)。因此，每个服务器都可以从这些(先前)负责的服务器请求该数据，指定其需要被传输的ID范围。也就是，基于第一查找表(其也含有在所检测到的状态改变之前和之后的第一查找表之间的映射信息)，每个服务器都被通知在状态改变之后其可以从哪些服务器获得用于其(新的)第二查找表的数据。
以下步骤在整个重组阶段期间将是最耗时的：将状态改变之后所计算和“更新的”第一查找表数据(还包括映射信息)传输/复制到服务器。传输该数据所需要的时间取决于若干因素，包括网络速度、已经发生故障的服务器的数目和位置、存储在环中的数据总量，以及与外部搜索请求相关的当前***负载。
作为参考点，在最坏情况下，必须通过100MBit/s的LAN(局域网)传输几个GB的数据，从而导致总传输时间在几分钟范围内。此外，由于该传输过程比正常查找的优先级低，因此，可能因服务器处理资源稀少以及网络中可使用的带宽较窄而进一步被延迟，甚至有可能将该阶段展长到几小时。
另一要点在于，必须度量每个服务器上的存储量(RAM或硬盘)，以便可以容纳在该时期内存储的附加数据。作为最坏情况的第一粗略估计，存储器消耗会是正常操作所需量的两倍。与其中每个服务器都持有整个数据空间的完全冗余***相比，这仍然明显要少。
当服务器已经接收到其从其它服务器所请求的所有数据的时候(图8中的S66)，其将向环主报告该事实。环主通过监控已经完成接收数据的服务器的数目来监控操作的进展(S6)。当所有的服务器都已经传达其准备就绪时，环主便触发重组的阶段II。
如图7中所示，在状态S24中，环主计算新的环状态，并且该新的状态被分发到所有的活动节点。此后，该环进入到状态“分发了未来的状态”S26，在其中传输所需要的数据。如果所有的活动节点都已经接收到了所需要的数据(S28)，则该环进入到状态“接收到未来的数据”S29。
阶段II：用于数据一致性的写锁定(locking write)
在该阶段以及下面的阶段III中的基本前提是：由于成功完成阶段I，因此每个服务器都具有其进行状态切换所需要的所有数据，以及其原来的数据。在阶段II，涉及了该***中写操作的问题。在这里写操作意味着创建、删除或更新存储在该***中的数据集。下面描述了处理这些操作的一些基本机制，以便显示所描述的方法的可行性。然而，由于数据完整性和同步性的要求非常依赖于为其存储数据的应用，因此仅给出了一般说明。
在正常操作期间，写不仅必须被传播到一个服务器，而且也要被传播到冗余存储位置。这包括在写操作期间锁定对这些数据集的读访问的某种机制。
在重组期间，根据已经请求数据集的服务器的数目而增加了存储该数据集的服务器的数目，以便涵盖这些服务器未来的范围。这意味着在该阶段中写操作也必须被传播到该数据集的未来的存储位置，这可以根据每个服务器已经接收到的未来环的状态计算出来。
剩下的问题在于有可能对写请求的转发形成了阻止状态改变的永不终止的链。对于将要改变的数据集来说，如果写请求已经到达原来的(旧的)服务器，则不能够实施环状态切换，因为该数据集的新的存储位置并不具有正确的信息/状态。然而，在其转发该改变所花费的时间中，新的写操作可以进入该***。
为了避免这种情况，并且为了达到存储在环中的数据稳定的状态，重组的阶段II引入了写锁定状态，其中不准新的写操作进入该***。
实现该目的的第一步骤是向所有服务器广播写锁定消息(图6中的S7；图7中的S30；图8中的S59、S68)，通知它们不应当再接受来自外部***的任何写操作。该消息必须被所有服务器确认，从而确保在某个时间点，没有任何新的写操作进入该***。在该步骤期间及之后，已经接受的写操作仍被正常转发到所有相关的服务器(S8)。正常的读操作并不受此影响。
每个服务器监控其仍然必须转发到其它服务器的写操作的数目。一旦其已经处理了所有的这些转发，其便向主机报告该事实，而主机又再次等待直到每个服务器都已经发信号通知其准备就绪(S9)。在处理了所有的读之后，其通过广播切换消息(图6中的S10；图7中的S32；图8中的S61、S70)来发信号通知转移到阶段III。如图7中所示，在环主已经发送了锁定命令之后，该环进入到状态“锁定”S31，即已经接收到锁定命令的环中的每个服务器都进入到状态“锁定”S60或S69，如图8中所示。
重要的是要注意，虽然在阶段I，数据的接受者负责声明其操作部分已完成(已经接收到所有请求的数据)，但是在阶段II，源必须接管该责任。这是必需的，因为每个服务器都知道哪些写操作仍在排队，但却并不知道其将接收多少这样的操作。
阶段III：切换到新的***状态
进入该阶段意味着所有的服务器都已经存储了其新状态所需要的数据，并且该数据是最新的，即，对于该数据集没有任何未完成的写操作。该阶段中的第一步骤是由环主广播切换命令(图6中的S10；图7中的S32；图8中的S61、S70)，其同样必须被所有服务器确认。在S11由环主收集这些切换确认。一旦接收到切换命令，每个服务器将启用第一和第二查找表，(即，根据在阶段I中，由来自主服务器的新的环状态消息而获得的信息所生成的新表)。此时，主服务器本身也启用其新的(所计算和生成的)第一和第二查找表。
从该时间点起，服务器根据该新的路由表来转发消息。如图7中所示，依照来自环主的切换命令，由新的查找表“替换”活动路由表之后，该环再次进入到平衡状态S20，即每个服务器都(重新)进入到图8中的“最新的”状态S62。
因为所有的服务器同时切换状态是不可能的(这可能是由于广播消息传输上的时间差、服务器中的处理器时序以及理论上不存在的并发性造成的)，所以会存在(尽管仅仅是短时间的)这样的状态，即在该状态下，环中的一些服务器根据旧的环状态/路由表来路由，并且其余的服务器根据新的状态来路由。稍后将描述该转移状态。
一旦所有的服务器都已经进入新的状态，并且已经将该情况报告给(旧的)环主，则该服务器(其在新的环中不一定是主机，但却仍然负责完成重组)可以发送解锁广播消息(S12)，以便再次允许写。该环现在已经完全切换到新的状态，现在可以丢弃旧的存储数据和路由表。
新的环状态的计算
在主服务器(即环主)上实现状态改变之后计算新的环布局的过程。旧的环状态以及改变是该过程的输入。在服务器故障的情况下，这些都已经被包括在当前的环状态中，因为在发现故障之后，必须立即从转发过程中排除故障服务器以防止丢失查询。每个活动服务器及其在未来的环状态中新的ID之间的映射是该过程的输出。
原则上，新的环状态计算过程是重组过程的模块化部分。下面将描述新的环状态计算过程的实施例。应当注意，新的环状态的计算并不限于下面所描述的实施例。
新的环状态计算过程是为了消除由服务器故障在覆层环中造成的间隙，以及用于将新的服务器***到该环，以便在所产生的环中，服务器再次均匀分布在覆层中，或者根据它们自身的情况进行分布，从而导致负载重新分布。同时，其还尝试将每个活动服务器从其当前位置仅移动小的距离，因为在覆层中不同的位置对该服务器意味着不同的基本范围和总范围，以及因此必须被传输的缺失数据。旧范围和新范围之间的差别越大，必须被传输的数据越多，从而导致a)更长的重组时间，以及b)服务器和网络上更多的负载。例外情况是加入网络的新服务器，其在任何情况下都必须请求完整范围的数据(倘若不能利用必须是最新的查找数据库的外部副本来对这些新服务器进行初始化的话)。
图9示出了其中服务器501、502、503、504和505位于标识符空间0到2m中的覆层环，其中m是该环中活动服务器的数目。首先，在服务器尽可能均匀分布的环状态中计算每个服务器必须与其前任和后继服务器具有的距离d。这是由活动服务器的数目所划分的ID空间的大小，活动服务器包括旧的“继续存在的”服务器加上新加入的服务器。
然后，选择锚服务器(anchor server)505作为用于重新定位其它服务器501-504的基础。每个服务器501-505都可以完成该角色。在当前情况下，选择主服务器或环主501的前任服务器作为基础。从锚服务器505开始，重新定位其后继服务器501(即，具有比锚服务器505的ID更大的最低ID的仍然活动的服务器)，从而使得在覆层/ID空间中的距离等于d。通过根据活动服务器的数目来划分ID空间的大小，导出距离d。现在已经被重新定位到位置501a的服务器501充当新的基本服务器，并且其后继服务器502被重新定位到位置502a，即离位置501a的距离d处。对每个接着的服务器503和504(其分别被重新定位到位置503a和504a)重复该过程，从而使得服务器501-505再次均匀分布在ID空间中。
如上所述，重复重新定位过程，直到每个服务器(包括作为最后步骤的锚服务器)都已经被重新定位。在该方案中，加入的服务器均匀地分散开来，从而使得对于O个旧的服务器和N个新的服务器来说，在***一个新的服务器之前，
Figure A200810184171D00261
个旧的服务器被放置在新环中。在比已经活动的更多的服务器加入网络的情况下，在一行中ID空间的末端***剩余的新服务器。
下面给出了计算新的环状态的过程的伪代码：
newRing computeNewRing(currentRing，newServers)
distance＝round(/DSpace.size/(currentRing.size+newServers.size))；
if(no new servers)
spacing＝currentRing.size；
insertNewServerCounter＝spacing+1；
else
       spacing＝round(currentRing.size/newServers.size)；
       insertNewServerCounter＝spacing；
recalc＝first server in currentRing；
anchor＝predecessor(recalc)；
for currentRing.size+newServers.size steps do
put recalc in newRing in new position anchor.position+distance
anchor＝recalc；
if(insertNewServerCounter＝＝spacing)
          recalc＝new server not yet inserted；
         insertNewServerCounter＝0；
else
         if(insertNewServerCounter！＝0)
                recalc＝successor(recalc)；
         else//a new server has just been inserted
                recalc＝successor(predecessor(recalc)incurrentRing)；
         insertNewServerCounfer++；
if(recalc＝＝first Server in currentRing)
          break；
//in case more new se rvers have joined than were already active
insert last new servers one after another into newRing，spaced by distance
重组期间的状态改变
尽管不太可能，然而在重组阶段期间仍有可能发生附加的状态改变，而连续的故障/加入已经由环主处的重组定时器所涵盖。取决于重组阶段，以不同的方式处理这些改变：
如果在阶段I期间发生状态改变，则重新起动完整的重组过程，且考虑新的信息。将新的改变报告给环主，其起动对未来的环状态的新的计算，并且再次向所有其它的服务器广播该新的环状态。普通服务器对这样的消息的新的接收将触发对该服务器的新范围的新的计算、“删除”或者至少解除激活先前所接收到的不再需要的新数据，以及触发对现在缺少的数据集的请求。当前不再感兴趣的所有的数据传输将被取消。该策略的原因在于以下实事：难以估计剩余重组将花费的时间，以及网络因此必须容忍因服务器故障所造成的负载不稳定的时间。
在到达阶段II之后，该过程的最后的步骤应在短时间内完成。由观察服务器记录在阶段II或III中的状态改变。在新的步骤进行之前完成旧的重组过程是重组的起点。这是为了通过扔掉已经完全传输的数据来使损失最小。
状态切换
如上所述，在阶段III期间，环将处于混合状态，其中一些服务器已经切换到新的状态，而其余的服务器仍然在等待切换命令。这意味着可能将查询转发给处于与转发服务器不同状态的服务器。
这两种情况的区别在于：从处于旧状态的服务器将查询转发到处于新状态的服务器，并且反之亦然。图10示出了从处于旧状态的服务器路由到处于新状态的服务器，并且图11示出了从处于新状态的服务器路由到处于旧状态的服务器。
在第一种情况下，如图10中所示，处于旧状态的服务器(节点A)假设其路由表中的服务器还处于旧状态，并且因此负责该路由表所指示的范围。因而，对于给定的搜索关键字x，根据节点A的旧路由表，其向负责x的服务器(节点B)转发查询。然而，如果节点B已经切换到新状态，则其基本(或者甚至是总的)范围可能并不含该条目。然而，由于对整个环来说尚未完成切换，因此节点B除了其新的基本和总范围之外仍然另外具有其旧的数据。该旧的范围必须含有用于x的条目，因为在旧状态中，节点B负责由发送服务器(节点A)的旧路由表所指示的范围。否则，R个连续的服务器已发生故障，并且已发生数据丢失，其中R是所选择的冗余因子。
这反过来又意味着接收服务器(节点B)可以根据其尚未改变的旧的数据集来应答内部查询，因为在该阶段不允许任何的写操作。
在第二种情况下，如图11中所示，已经切换状态的服务器(节点B)根据其新的路由表转发查询。如果接收内部查询的节点A尚未切换其状态，则其因此可能接收到并不在其(旧的)基本或总范围内的条目的查询。然而，由于节点A已经接收到其需要用来切换到其新的状态的数据，因此其也具有由其在节点B的路由表中的条目所指示的基本和总范围。因此能够根据其存储的附加数据集(其也是最新的)来应答该查询，因为所有的写操作在阶段II都已经被转发和终结了。
环主故障
在重组期间环主故障的特殊情况需要特别考虑。原则上，有可能(即使不见得会发生)在任何重组阶段期间，主服务器(即，环主)本身发生故障。下面将描述***如何对这样的环主故障作出反应。
在任何情况下，环主的故障将被至少一个其它的服务器注意到，由于网络的全网状结构，很可能被几个并且甚至可能被所有其它的服务器注意到。如果在重组的任何阶段期间环主发生故障，则该故障连同所有先前所报告的改变都被报告给具有路由表中目前最低ID的新的主服务器或者被报告给报告这些改变的服务器。该报告还包括发送这些改变的服务器本身的状态(即，服务器实际上处于的重组阶段的哪一步)。可以仅从以下事实来推断该服务器就是新环主，即：报告被发送到该服务器。与服务器状态有关的信息有助于新的主服务器计算关于总的环状态的概况，尤其是重组过程中滞后一步的服务器的概况以及必须被满足什么条件才可以进行下一步。
在一些服务器尚未注意到环主故障的情况下，新的主服务器仍然可以轮询其它服务器的状态以及它们所观察到的状态改变，并且通知这些服务器新的主服务器的新状态。因而，即使主服务器出现故障，主服务器所持有的任何信息也不会丢失。***任何时候都不会由于丢失环主而处于其不能进行重组的状态。
本发明可应用于诸如HLR、Radius、OAM DB、NM DB、计费DB等环境。
图12根据本发明的实施例示出了说明服务器10、201、...、20i、...、20n的示意框图。服务器10、201、...、20i、...、20n可以是分布式数据库***的前端设备。
服务器10、201、...、20i、...、20n各自包括指示第二查找表(查找表，第二数据结构)的分布的第一查找表(分区表，第一数据结构)11、21、...、21n，第二查找表的分区12、22、...、22n，将服务器10、201、...、20i、...、20n相互连接的接口单元13、23、...、23n，以及处理器14、24、...、24n。
假设服务器10被选为主服务器，例如因为如上所述其ID是网络中最低的ID，处理器14确定网络中的状态改变，该网络包括在多个服务器10、201、...、20i、...、20n中作为主服务器的服务器10。
处理器14计算第一查找表11，其表示分布在多个服务器10、201、...、20i、...、20n中的活动服务器中，第二查找表的分布情况，并且该处理器14通过接口单元13将所计算的第一查找表11发送至每个活动服务器。基于第一查找表11，处理器14生成经修改的第二查找表的分区。
为了计算第一查找表11，处理器14可以将第二查找表分区并分配给每个活动服务器，其中，分配给每个活动服务器的第二查找表的分区在大小上彼此相等，其中分区大小是通过起始地址值和结束地址值之间的差来限定的。可选地，各个分区在大小上彼此不同，而与每个活动服务器的各自的处理能力成比例，或者使得每个活动服务器的负载彼此相同。
处理器14可以进一步通过接口单元13从每个活动服务器收集第一确认，其指示在每个活动服务器处生成的经修改的第二查找表的分区已完成，收到第一确认后，该处理器14通过接口单元13向网络中的每个活动服务器发送锁定命令，并且通过接口单元13从每个活动服务器收集指示其已被锁定的第二确认，其中当服务器被锁定后写操作被禁止。
收到第二确认后，处理器14可以进一步通过接口单元13向网络中的每个活动服务器发送切换命令，并且通过接口单元13从每个活动服务器收集第三确认，其指示该服务器已切换到第一查找表以及经修改的第二查找表的分区。
收到第三确认后，处理器14可以进一步通过接口单元13向网络中的每个活动服务器发送解锁命令。
网络中的状态改变可以是指以下情况中的至少一种：
-至少一个服务器的状态上的改变，其包括服务器的活动性上的改变、服务器的处理能力上的改变以及服务器的负载上的改变中的至少一个；
-从构成网络的多个服务器中移除服务器，以及
-向由多个服务器所构成的网络添加服务器。
为了确定网络中的状态改变，在确定了状态改变后，处理器14可以起动定时器(未示出)，并且在定时器期满时再次检查状态，其中如果定时器起动时的状态与定时器期满之后的状态相同，则处理器14可以确认状态改变。
第一查找表11、21、......、21n可以包括至少一对数据，其中每对数据包括活动服务器的地址以及数值范围(其表示第二查找表的一个分区，并且由起始地址值和结束地址值限定)，并且进一步可以包括在所检测的状态改变之前和之后第一查找表之间的映射信息。
为了将第二查找表的分区分配给活动服务器，处理器14可以在所述状态改变被检测到之后的多个活动服务器中，重新划分地址空间(其是由多个活动服务器所管理的各自的第二查找表的分区所形成的)，从而使每个活动服务器获得各自的经修改的第二查找表的分区。
第一查找表中所含的数据对的数目可以取决于活动服务器的数目。
为了重新划分地址空间，处理器14可以针对至少一个活动服务器，在地址空间中，将其起始地址和结束地址中的至少一个移动相应的地址偏移量。
在重新划分之后，处理器14可以进一步确定地址偏移量。可以在已经发送解锁命令之后进行确定。
基于所计算的第一查找表，以及所述网络的状态改变被检测到之前所述多个服务器中的至少一个服务器的第二查找表的分区，处理器14可以生成经修改的第二查找表的分区。处理器14可以与至少一个其它的服务器交换数据，以便导出生成其经修改的分区所需的数据。在服务器故障的情况下，为了能够从故障服务器中恢复数据，引入冗余，从而使得可从至少一个其它的服务器获得来自故障服务器的数据。
如上所述，假设服务器201是活动服务器之一，接口单元23接收对应于充当主服务器的服务器10所计算的第一查找表11的第一查找表21，并且处理器24基于该第一查找表21生成经修改的第二查找表的分区。
在完成生成经修改的第二查找表的分区后，处理器24可以使接口单元23向主服务器发送第一确认。
接口单元23可以接收锁定命令，并且收到锁定命令后，处理器24可以锁定活动服务器201，以及完成正在进行的写操作，并且在完成了正在进行的写操作后，使接口单元23向主服务器发送第二确认，其指示活动服务器201被锁定，其中当活动服务器201被锁定后写操作被禁止。
接口单元23可以接收切换命令，并且收到切换命令后，处理器24可以切换到所接收的第一查找表21以及所生成的经修改的第二查找表22的分区，并且在完成切换后，使接口单元23向主服务器发送第三确认。
类似于处理器14，基于所接收的第一查找表，以及状态改变之前所述多个服务器中的至少一个服务器的第二查找表的分区，处理器24可以生成经修改的第二查找表的分区，如下面参照图13所描述的。
图13根据本发明的实施例示出了一示意图，其说明了当以冗余因子2或3存储第二查找表的分区的时候，第二查找表的分区与服务器之间的关系的例子。
在图13中，假设完整的第二查找表是由数据A+B+C+D+E+F+G+H所组成，并且查找***由8台服务器组成。如果这些服务器不会出现故障，那么将足以在服务器ID1上存储查找数据A、在服务器ID2上存储查找数据B、在服务器ID3上存储查找数据C、在服务器ID4上存储查找数据D、在服务器ID5上存储查找数据E、在服务器ID6上存储查找数据F、在服务器ID7上存储查找数据G，以及在服务器ID8上存储查找数据H。
然而，假设服务器发生故障，通过在每台服务器中存储并不由该服务器负主要责任的数据来增加冗余。考虑如图13中所示的冗余因子2，服务器ID1存储其自己的数据A以及应由另一服务器ID2负责的数据，即数据B。这也同样应用于服务器ID2-ID8，这些服务器分别存储其自己的数据以及应由后继服务器负责的数据(假设有一环，ID1是ID8的后继者)
因而，如果服务器ID2发生故障，则其数据可以从服务器ID1恢复。如果冗余因子是如图13中所示的3，那么每个服务器ID1到ID8都存储其自己的数据以及紧接着的两台服务器应负责的数据。也就是说，如上所述用于生成经修改的第二查找表的分区的数据可以从冗余存储该数据的仍然活动的服务器中获得。
出于上述本发明的目的，应当注意：
-所述方法及步骤可以作为软件代码实现并在以服务器为实体之一的处理器处运行，且不依赖于软件代码，而且可以使用任何已知的或将来开发的编程语言来编写；
-所述方法，步骤和/或装置可以以作为以服务器为实体之一的硬件组件来实现，且不依赖于硬件，而且可以使用任何已知的或将来开发的硬件技术或诸如MOS、CMOS、BiCMOS、ECL、TTL等技术的任何混合(举例来说，使用例如ASIC组件或DSP组件)来实现；
-通常，在不改变本发明的思想的情况下，任何方法步骤都适于作为软件或通过硬件来实现；
-所述设备可以被实现为单独的装置，但这并不排除它们在整个***以分布式方式实现的情况(只要保留设备的功能)。
应当理解以上描述是对本发明的说明性描述，并且不应被解释为对本发明的限制。在不背离如所附权利要求所限定的本发明的实质和范围的情况下，本领域的技术人员可以想到各种修改，变通和应用。

Claims (38)

1.一种方法，其包括：
确定网络中的状态改变，所述网络包括多个服务器及主服务器；
在所述主服务器处计算第一查找表，所述第一查找表表示在所述多个服务器中的活动服务器中，第二查找表的分布情况；
将所计算的第一查找表分发至每个活动服务器；以及
基于所述第一查找表，在所述主服务器处生成经修改的第二查找表的分区。
2.根据权利要求1所述的方法，其中计算所述第一查找表包括：
将所述第二查找表分区并分配给所述每个活动服务器，其中
分配给每个活动服务器的第二查找表的分区在大小上彼此相等，其中所述分区大小是由起始地址值和结束地址值之间的差限定的；或者，在分区大小上彼此不同，
而与每个所述活动服务器的相应的处理能力成比例，或
使得每个所述活动服务器的负载彼此相等。
3.根据权利要求1所述的方法，其进一步包括：
在所述主服务器处，从每个活动服务器收集第一确认，其指示在每个活动服务器处生成的经修改的第二查找表的分区已完成；
收到所述第一确认后，向所述网络中的每个活动服务器发送锁定命令；以及
从每个活动服务器收集指示其已被锁定的第二确认，其中当服务器被锁定后写操作被禁止。
4.根据权利要求3所述的方法，其进一步包括：
收到所述第二确认后，向所述网络中的每个活动服务器发送切换命令，以及从每个活动服务器收集第三确认，其指示该服务器已切换到其各自的第一查找表以及经修改的第二查找表的分区。
5.根据权利要求4所述的方法，其进一步包括：
收到所述第三确认后，向所述网络中的每个活动服务器发送解锁命令。
6.根据权利要求1所述的方法，其中所述网络的状态改变是指以下情况中的至少一种：
至少一个服务器状态上的改变，从构成所述网络的多个服务器中移除服务器，以及将服务器添加到由多个服务器所构成的所述网络中。
7.根据权利要求1所述的方法，其中确定网络的状态改变包括：
在确定所述状态改变时起动定时器；以及
在所述定时器期满时再次检查所述状态，其中
如果当所述定时器起动时的状态与所述定时器期满之后的状态相同，则确认所述状态改变。
8.根据权利要求2所述的方法，其中所述第一查找表包括至少一对数据，其中每对数据包括：
活动服务器的地址；
数值范围，其表示第二查找表的一个分区，并且由起始地址值和结束地址值限定；
以及进一步包括在所检测到的状态改变之前和之后所述第一查找表之间的映射信息。
9.根据权利要求2所述的方法，其中所述分区并分配包括：
在所述状态改变被检测到之后的多个活动服务器中，重新划分由多个活动服务器所管理的各自的第二查找表的分区所形成的地址空间，从而使每个活动服务器获得各自的经修改的第二查找表的分区。
10.根据权利要求8所述的方法，其中所述第一查找表中所含的数据对的数目取决于活动服务器的数目。
11.根据权利要求9所述的方法，其中所述重新划分包括：
针对至少一个活动服务器，在地址空间中，将其起始地址和结束地址中的至少一个移动相应的地址偏移量。
12.根据权利要求11所述的方法，其进一步包括：在重新划分之后确定所述地址偏移量。
13.根据权利要求1所述的方法，其中所述生成是基于所计算的第一查找表，以及所述网络的状态改变被检测到之前所述多个服务器中的至少一个服务器的第二查找表的分区。
14.一种方法，其包括：
在多个服务器中的活动服务器处接收第一查找表，其表示在所述多个服务器中第二查找表的分布情况；
基于所述第一查找表，在所述活动服务器处生成经修改的第二查找表的分区。
15.根据权利要求14所述的方法，还包括：
在生成所述经修改的第二查找表的分区后，向主服务器发送第一确认。
16.根据权利要求15所述的方法，还包括：
收到锁定命令后，锁定该服务器；
收到所述锁定命令后，完成正在进行的写操作；以及
完成了正在进行的写操作后，向所述主服务器发送第二确认，其指示所述活动服务器被锁定，其中当所述活动服务器被锁定后写操作被禁止。
17.根据权利要求16所述的方法，其进一步包括：
接收切换命令；收到所述切换命令后，切换到所接收的第一查找表以及所生成的经修改的第二查找表的分区，并且在完成所述切换后，向所述主服务器发送第三确认。
18.根据权利要求14所述的方法，其中所述生成是基于所接收的第一查找表，以及状态改变之前所述多个服务器中的至少一个服务器的第二查找表的分区。
19.一种服务器，其包括：
接口单元；以及
处理器，其被配置以便：
确定网络中的状态改变，所述网络包括多个服务器以及作为主服务器的所述服务器；
计算第一查找表，所述第一查找表表示在所述多个服务器中的活动服务器中，第二查找表的分布情况；
通过所述接口单元将所计算的第一查找表发送至每个活动服务器；以及
基于所述第一查找表，生成经修改的第二查找表的分区。
20.根据权利要求19所述的服务器，其中用于计算所述第一查找表的所述处理器被配置以便：
将所述第二查找表分区并分配给所述每个活动服务器，其中
分配给每个活动服务器的第二查找表的分区在大小上彼此相等，其中所述分区大小是由起始地址值和结束地址值之间的差限定的；或者，分区大小彼此不同：
而与每个所述活动服务器的各自的处理能力成比例，或
使得每个活动服务器的负载彼此相等。
21.根据权利要求19所述的服务器，其中所述处理器进一步被配置以便：
通过所述接口单元从每个活动服务器收集第一确认，其指示在每个活动服务器处生成的经修改的第二查找表的分区已完成；
收到所述第一确认后，通过所述接口单元向所述网络中的每个活动服务器发送锁定命令；以及
通过所述接口单元从每个活动服务器收集指示其已被锁定的第二确认，其中当服务器被锁定后写操作被禁止。
22.根据权利要求21所述的服务器，其中所述处理器进一步被配置以便：
收到所述第二确认后，通过所述接口单元向所述网络中的每个活动服务器发送切换命令，以及
通过所述接口单元从每个活动服务器收集第三确认，其指示该服务器已切换到所述第一查找表以及所述经修改的第二查找表的分区。
23.根据权利要求22所述的服务器，其中所述处理器进一步被配置以便：
收到所述第三确认后，通过所述接口单元向所述网络中的每个活动服务器发送解锁命令。
24.根据权利要求19所述的服务器，其中所述网络中的状态改变是指以下情况中的至少一种：
至少一个服务器状态上的改变，从构成所述网络的多个服务器中移除服务器，以及将服务器添加到由多个服务器所构成的所述网络。
25.根据权利要求19所述的服务器，其中用于确定所述网络的状态改变的所述处理器被配置以便：
在确定所述状态改变时起动定时器；以及
在所述定时器期满时再次检查所述状态，
其中所述处理器被配置以便：在当所述定时器起动时的状态与所述定时器期满之后的状态相同的情况下，确认所述状态改变。
26.根据权利要求20所述的服务器，其中所述第一查找表包括至少一对数据，其中每对数据包括：
活动服务器的地址；
数值范围，其表示第二查找表的一个分区，并且由起始地址值和结束地址值限定；
以及进一步包括在所检测到的状态改变之前和之后所述第一查找表之间的映射信息。
27.根据权利要求20所述的服务器，其中用于将所述第二查找表分区并分配给活动服务器的所述处理器被配置以便：
在所述状态改变被检测到之后的多个活动服务器中，重新划分由多个活动服务器所管理的各自的第二查找表的分区所形成的地址空间，从而使每个活动服务器获得各自的经修改的第二查找表的分区。
28.根据权利要求26所述的服务器，其中所述第一查找表中所含的数据对的数目取决于活动服务器的数目。
29.根据权利要求27所述的服务器，其中用于重新划分所述地址空间的所述处理器被配置以便：
针对至少一个活动服务器，在地址空间中，将其起始地址和结束地址中的至少一个移动相应的地址偏移量。
30.根据权利要求29所述的服务器，其中所述处理器进一步被配置以便：在重新划分之后确定所述地址偏移量。
31.根据权利要求19所述的服务器，其中所述处理器被配置以便：基于所计算的第一查找表，以及所述网络的状态改变被检测到之前所述多个服务器中的至少一个服务器的第二查找表的分区，生成所述经修改的第二查找表的分区。
32.一种服务器，其包括：
接口单元，其被配置以便接收第一查找表，其表示在多个服务器中的第二查找表的分布情况，所述多个服务器包括作为活动服务器的所述服务器；以及
处理器，其被配置以便基于所述第一查找表，生成经修改的所述第二查找表的分区。
33.根据权利要求32所述的服务器，其中所述处理器被配置以便：完成生成所述经修改的第二查找表的分区后，使所述接口单元向主服务器发送第一确认。
34.根据权利要求33所述的服务器，其中
所述接口单元被配置以便接收锁定命令；
收到所述锁定命令后，所述处理器被配置以便：锁定该服务器，以及完成正在进行的写操作，并且在完成了正在进行的写操作后，使所述接口单元向所述主服务器发送第二确认，其指示所述活动服务器被锁定，其中当所述活动服务器被锁定后写操作被禁止。
35.根据权利要求34所述的服务器，其中
所述接口单元被配置以便接收切换命令，
收到所述切换命令后，所述处理器被配置以便：切换到所接收到的第一查找表以及所生成的经修改的第二查找表的分区，并且在完成所述切换后，使所述接口单元向所述主服务器发送第三确认。
36.根据权利要求32所述的服务器，其中所述处理器被配置以便：基于所接收到的第一查找表，以及状态改变之前所述多个服务器中的至少一个服务器的第二查找表的分区，生成所述经修改的第二查找表的分区。
37.一种***，其包括根据权利要求19至31中任何一项所述的服务器以及至少一个根据权利要求32至36中任何一项所述的服务器。
38.一种计算机程序，其包括用于执行根据权利要求1至18中任何一项所述的方法的处理器可实现指令。
CN200810184171.9A 2007-12-17 2008-12-16 分布式数据库***中的负载分布方法及其服务器和数据库*** Active CN101465877B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP07150065.6 2007-12-17
EP07150065A EP2073118A1 (en) 2007-12-17 2007-12-17 Load distribution in distributed database system

Publications (2)

Publication Number Publication Date
CN101465877A true CN101465877A (zh) 2009-06-24
CN101465877B CN101465877B (zh) 2013-02-13

Family

ID=39272270

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200810184171.9A Active CN101465877B (zh) 2007-12-17 2008-12-16 分布式数据库***中的负载分布方法及其服务器和数据库***

Country Status (3)

Country Link
US (1) US7984183B2 (zh)
EP (1) EP2073118A1 (zh)
CN (1) CN101465877B (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102474714A (zh) * 2009-07-21 2012-05-23 德国电信股份公司 分布式网络寄存器
CN103761260A (zh) * 2013-12-31 2014-04-30 北京京东尚科信息技术有限公司 处理数据库互斥锁的方法和装置以及分布式***
CN103902585A (zh) * 2012-12-27 2014-07-02 ***通信集团公司 一种数据加载方法和***
CN104253731A (zh) * 2013-06-25 2014-12-31 罗伯特·博世有限公司 用于运行通信装置的方法
CN104811505A (zh) * 2015-05-21 2015-07-29 上海礼源网络科技有限公司 基于云计算环境的客户端网络控制的方法及***
CN107656980A (zh) * 2017-09-07 2018-02-02 北京神州绿盟信息安全科技股份有限公司 应用于分布式数据库***中的方法及分布式数据库***
CN107682406A (zh) * 2017-09-08 2018-02-09 北京三快在线科技有限公司 一种业务处理的方法、装置以及***
CN108228473A (zh) * 2016-12-22 2018-06-29 西部数据技术公司 通过动态地传送存储器范围分配的负载平衡

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
WO2005091136A1 (en) 2004-03-13 2005-09-29 Cluster Resources, Inc. System and method for a self-optimizing reservation in time of compute resources
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
CA2586763C (en) 2004-11-08 2013-12-17 Cluster Resources, Inc. System and method of providing system jobs within a compute environment
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
WO2006108187A2 (en) 2005-04-07 2006-10-12 Cluster Resources, Inc. On-demand access to compute resources
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
US9183260B2 (en) * 2008-10-09 2015-11-10 International Business Machines Corporation Node-level sub-queries in distributed databases
US8285710B2 (en) * 2008-10-09 2012-10-09 International Business Machines Corporation Automated query path reporting in distributed databases
US8145652B2 (en) 2008-10-09 2012-03-27 International Business Machines Corporation Automated propagation of non-conflicting queries in distributed databases
US8301583B2 (en) 2008-10-09 2012-10-30 International Business Machines Corporation Automated data conversion and route tracking in distributed databases
US9264491B2 (en) * 2008-12-22 2016-02-16 Telefonaktiebolaget L M Ericsson (Publ) Direct addressing of content on an edge network node
US10929401B2 (en) 2009-04-16 2021-02-23 Tibco Software Inc. Policy-based storage structure distribution
US8565239B2 (en) * 2009-07-14 2013-10-22 Broadcom Corporation Node based path selection randomization
US8503456B2 (en) * 2009-07-14 2013-08-06 Broadcom Corporation Flow based path selection randomization
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US8539135B2 (en) * 2011-05-12 2013-09-17 Lsi Corporation Route lookup method for reducing overall connection latencies in SAS expanders
CN102546652B (zh) * 2012-01-29 2015-05-13 沈文策 一种服务器负载平衡***及方法
US9299111B2 (en) * 2012-09-04 2016-03-29 Futurewei Technologies, Inc. Efficient presence distribution mechanism for a large enterprise
US9537793B2 (en) * 2012-10-10 2017-01-03 Cisco Technology, Inc. Ensuring any-to-any reachability with opportunistic layer 3 forwarding in massive scale data center environments
GB2510429A (en) 2013-02-05 2014-08-06 Ibm Assessing response routes in a network
US9733664B1 (en) * 2013-03-14 2017-08-15 Gamesys Ltd. Method for expiring fault-tolerant timers using distributed locks
WO2015069480A1 (en) * 2013-11-07 2015-05-14 Formation Data Systems, Inc. Multi-layer data storage virtualization using a consistent data reference model
US11095715B2 (en) 2014-09-24 2021-08-17 Ebay Inc. Assigning storage responsibility in a distributed data storage system with replication
US9800575B1 (en) * 2014-09-24 2017-10-24 Ebay Inc. Assigning storage responsibility in a distributed data storage system with replication
US10652322B2 (en) * 2015-03-09 2020-05-12 International Business Machines Corporation Scalable parallel messaging process
JP6387333B2 (ja) * 2015-09-07 2018-09-05 日本電信電話株式会社 ノードおよびスロット最適化方法
US10599676B2 (en) * 2015-12-15 2020-03-24 Microsoft Technology Licensing, Llc Replication control among redundant data centers
US10248709B2 (en) 2015-12-15 2019-04-02 Microsoft Technology Licensing, Llc Promoted properties in relational structured data
US11226985B2 (en) 2015-12-15 2022-01-18 Microsoft Technology Licensing, Llc Replication of structured data records among partitioned data storage spaces
US10235406B2 (en) 2015-12-15 2019-03-19 Microsoft Technology Licensing, Llc Reminder processing of structured data records among partitioned data storage spaces
US10445372B2 (en) * 2016-02-01 2019-10-15 Sandisk Technologies Llc. Method and device to access auxiliary mapping data for a data structure
US10241875B2 (en) 2016-09-15 2019-03-26 International Business Machines Corporation Switching initial program load responsibility when components fail
US10462059B2 (en) 2016-10-19 2019-10-29 Intel Corporation Hash table entries insertion method and apparatus using virtual buckets
US10394784B2 (en) 2016-12-22 2019-08-27 Intel Corporation Technologies for management of lookup tables
US11249973B2 (en) * 2018-05-03 2022-02-15 Sap Se Querying partitioned tables in a distributed database
US10691658B2 (en) 2018-05-09 2020-06-23 International Business Machines Corporation Automatically optimizing resource usage on a target database management system to increase workload performance
CN110753133B (zh) * 2018-07-23 2022-03-29 华为技术有限公司 处理地址的方法和网络设备

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6298381B1 (en) * 1998-10-20 2001-10-02 Cisco Technology, Inc. System and method for information retrieval regarding services
US6950848B1 (en) * 2000-05-05 2005-09-27 Yousefi Zadeh Homayoun Database load balancing for multi-tier computer systems
JP2002190825A (ja) * 2000-12-21 2002-07-05 Fujitsu Ltd トラフィックエンジニアリング方法及びそれを用いたノード装置
US6990102B1 (en) * 2001-05-10 2006-01-24 Advanced Micro Devices, Inc. Parallel lookup tables for locating information in a packet switched network
US7072960B2 (en) * 2002-06-10 2006-07-04 Hewlett-Packard Development Company, L.P. Generating automated mappings of service demands to server capacities in a distributed computer system
US7701858B2 (en) * 2003-07-17 2010-04-20 Sensicast Systems Method and apparatus for wireless communication in a mesh network
WO2005022824A1 (fr) * 2003-09-02 2005-03-10 Huawei Technologies Co., Ltd. Procede permettant de choisir une voie de transmission de donnees de trafic en temps reel
US7779415B2 (en) * 2003-11-21 2010-08-17 International Business Machines Corporation Adaptive load distribution in managing dynamic and transient data for distributed applications
US20060168107A1 (en) * 2004-03-16 2006-07-27 Balan Rajesh K Generalized on-demand service architecture for interactive applications

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102474714A (zh) * 2009-07-21 2012-05-23 德国电信股份公司 分布式网络寄存器
CN102474714B (zh) * 2009-07-21 2014-11-26 德国电信股份公司 分布式网络寄存器
CN103902585A (zh) * 2012-12-27 2014-07-02 ***通信集团公司 一种数据加载方法和***
CN104253731A (zh) * 2013-06-25 2014-12-31 罗伯特·博世有限公司 用于运行通信装置的方法
CN103761260A (zh) * 2013-12-31 2014-04-30 北京京东尚科信息技术有限公司 处理数据库互斥锁的方法和装置以及分布式***
CN104811505A (zh) * 2015-05-21 2015-07-29 上海礼源网络科技有限公司 基于云计算环境的客户端网络控制的方法及***
CN108228473A (zh) * 2016-12-22 2018-06-29 西部数据技术公司 通过动态地传送存储器范围分配的负载平衡
CN107656980A (zh) * 2017-09-07 2018-02-02 北京神州绿盟信息安全科技股份有限公司 应用于分布式数据库***中的方法及分布式数据库***
CN107656980B (zh) * 2017-09-07 2020-09-22 北京神州绿盟信息安全科技股份有限公司 应用于分布式数据库***中的方法及分布式数据库***
CN107682406A (zh) * 2017-09-08 2018-02-09 北京三快在线科技有限公司 一种业务处理的方法、装置以及***
CN107682406B (zh) * 2017-09-08 2020-08-25 北京三快在线科技有限公司 一种业务处理的方法、装置以及***

Also Published As

Publication number Publication date
US7984183B2 (en) 2011-07-19
US20090157684A1 (en) 2009-06-18
EP2073118A1 (en) 2009-06-24
CN101465877B (zh) 2013-02-13

Similar Documents

Publication Publication Date Title
CN101465877B (zh) 分布式数据库***中的负载分布方法及其服务器和数据库***
US8166063B2 (en) Query routing in distributed database system
CN101102250B (zh) 用于自组织网络的分布式散列机制
US6411967B1 (en) Distributed processing system with replicated management information base
US8255736B2 (en) Consistent and fault tolerant distributed hash table (DHT) overlay network
US8521884B2 (en) Network system and method of address resolution
CN101510897B (zh) 针对层次化主机标识、基于叠加式dht的寻址***和方法
US20140185446A1 (en) Synchronizing state among load balancer components
US20110047272A1 (en) Dissemination of Network Management Tasks in a Distributed Communication Network
US7773609B2 (en) Overlay network system which constructs and maintains an overlay network
JP4459999B2 (ja) 投票を活用した無停止サービスシステム及びそのシステムにおける情報更新及び提供方法
Wehrle et al. 7. distributed hash tables
CN104380289A (zh) 服务感知分布式散列表路由
CN110990448B (zh) 一种支持容错的分布式查询方法及装置
KR20090094313A (ko) 콘텐츠를 배포하는 방법 및 시스템과, 콘텐츠를 검색하는 방법 및 시스템
CN101026537A (zh) 对等网络及其网络资源查询方法
EP3570169B1 (en) Method and system for processing device failure
CN101296108B (zh) 一种在结构化p2p中备份资源的方法和***
JP2007156700A (ja) 情報検索方法、情報登録方法およびネットワークサービス情報検索システム
Harvey et al. Efficient recovery from organizational disconnects in SkipNet
US20090028070A1 (en) Node device, information process method, and recording medium recording node device program
JP2007112618A (ja) 無線タグｉｄ情報転送先アドレス解決システムおよび方法
Harrell et al. Survey of locating & routing in peer-to-peer systems
Götz et al. 8. Selected DHT Algorithms
JP5895564B2 (ja) ネットワーク運用管理システムおよびネットワーク運用管理方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
C56 Change in the name or address of the patentee
CP01 Change in the name or title of a patent holder

Address after: Espoo, Finland

Patentee after: Nokia Siemens Networks OY

Address before: Espoo, Finland

Patentee before: Nokia Siemens Networks OY