CN102591886A - 在分布式数据库架构中维护会话-主机关系的容错方法 - Google Patents

Abstract

为了解决现有的分布式数据库中在服务器加入和服务器离开时需对会话进行重新归属，带来了较大的风险并产生了大量开销的问题，本发明提供了在分布式数据库架构中维护会话-主机关系的容错方法。在一个实施方式中，有新加入的CCF节点时，维持预先决定的、各个关联对象与它的关联主机之间的映射不变，而之后新到来的关联对象和会话考虑该新加入的CCF节点。在另一个实施方式中，有CCF节点无法提供服务时，对于关联主机是该无法提供服务的CCF节点的各个关联对象，将提供服务的CCF节点中的一个作为该关联对象的关联主机。本发明的实施方式不需要对会话进行重新归属，减少了开销，并避免了重新归属过程中的出错风险。

Description

在分布式数据库架构中维护会话-主机关系的容错方法

技术领域

本发明涉及数据库技术，特别涉及分布式的数据库技术。

背景技术

在使用计费收集功能(Charging Collection Function，简称CCF)的IP多媒体系统网络中，计费数据记录(CDR)的互相关联是这样一种功能：它接合了来自各个网元(NE)的要素CDR，这些网元实现了计费触发功能。在一个分布式数据库架构(DDB)中，关联的主机典型地是一个CCF节点，它会被选中从而将负载均衡地分散到CCF节点中。DDB方式具有这样的优点：与传统的、受读写TPS一般处于1000读/写每秒的数量级的商用服务器的读写TPS限制的集中式数据库方式相比，系统地吞吐随着CCF的加入线性地变化。

尽管DDB方式在CCF节点中提供了公平的负载分布，并且增加了系统吞吐，但是下面这些相关的问题使得DDB方式还不够优化：

-关联主机可能无法提供服务(out of service，简称OOS)，并继而阻止了关联的完成；

-当一个或多个CCF节点被加入时，正在进行的会话已经要求重新归属以分散处理负载，由于这一阶段的特征是大量的数据从一个数据库到另一个数据库的转移，该转移牵涉到多个源以及目的，这些源和目的最终消耗了很大百分比的CPU周期进行转移，因此在这一阶段中系统的吞吐会降低。而如果不进行重新归属，CCF节点会不正确地计算关联主机，并且不同的CCF节点会将属于相同会话的记录导向至不同的关联主机，这意味着关联功能：

(a)对于相同的会话被执行超过一次，以及

(b)所有的服务器都使用不完整的会话信息进行工作，这带有很大几率使所有相关联的纪录都是不完整的并且在计费协调系统处不被接受。

因此，这种用于处于服务器停运和服务器加入的下雨天场景需要手工来正确地重新计算关联主机以及调整负载分布。

在现有技术中，已经提出了一种解决方案克服以上问题，下面将结合图1至3给予说明

·现有技术：当关联主机无法提供服务

一个关联主机根据f(Key)被选中，其中，该key典型的是被分配给被记账的会话的IMS计费标识(ICID)，并且该key被多个作为计费触发功能(CTF)的网元所报告，其中该ICID被保证为在网络中对于一段时间内，例如一个月内唯一。被使用在ICID上的函数是一个哈希函数，并且该结果确定关联主机。该方法确保：属于同一关联对象的记账记录被发送给单个关联主机，并且平均来说每个CCF节点接纳了大致相同数量的处理负载。在实践中，一个关联对象可以具有多于一个正在进行的、由CTF所报告的记账会话。

作为一个例子，考虑具有3个CCF节点：CCF节点1至CCF节点3(下面简称为CCF1至CCF3)的网络。假定目前CCF2无法提供服务。对于一些正在进行会话，CCF1和CCF3能够通过对该些会话相应的ICID施加f(Key)来了解到关联主机是CCF2。由于CCF1和CCF3无法与CCF2通信，例如计费相关信息等新的会话记录会被插入到这各个服务器的本地缓存中。当CCF2恢复后，CCF1和CCF3检测到其可用性，继而将这些被缓存的会话记录发送给由CCF2拥有并且作为主机的数据库中。

这一方式的问题在于：没有办法预先得知CCF2的停运将会持续多久。因此，本地缓存的解决方案只能在一定程度上起作用。在一段时间后，本地缓存将变得无法存储记账信息，继而该解决方案失败。当缓存充满时，在这一时刻可以使用回滚机制产生不关联的CDR，从而来清空缓存并且避免丢失记录。这一方式相关的问题在于：很多用户拒绝支付不关联的CDR，这意味着这些呼叫或会话将无法被记账，使用者也不会对它们被开具帐单。这产生了收入泄漏问题

·现有技术：当将一个或多个CCF节点加入到可用的服务器簇中

对于现有的网络，当增加服务器时，复杂的一系列处理将被运行：这些处理首先设立该被加入的一个或多个服务器，暂停目前已有的服务器上的处理，更新各服务器的内部表格以添加被加入的一个或多个服务器的标记，在所更新的服务器数中重新归属正在进行的会话，之后继续处理并恢复正常状态。该处理的每个阶段都具有精心设计的差错处理进程，并且它还需要人工介入以解决下雨天场景。

作为这一方式的两个主要缺点，以下这些点值得注意：

-与精心设计的差错处理进程相关的复杂的一系列步骤需要操作员参照差错日志并且基于失效点使用恢复机制；

-正常的处理被暂停，会话被重新归属以及耦合，这样带来的事实是：该过程的运行可能出现问题，处理暂停的时间对于网络运营商来说可能无法接受；

下面结合图1至4简要地说明根据现有技术增加一个CCF节点的过程。

图1示出了一个正常状态，这时有两个工作的CCF节点，它们被通过即时增强CCF(IeCCF)而实现，记作CCF1和CCF2。每个CCF节点都具有位于存储器内的数据库，即DB11和DB21，并具有eCCF应用模块，即eCCF App12和eCCF App22。在两个CCF节点之间存在用于交换数据的接口，记为ODBC。假定一关联对象X带有4个会话：会话a，会话b，会话c和会话d。并且该关联对象X的关联主机是CCF1，这意味着这一对象的所有计费数据都会被定向于CCF1，并且CCF1负责对象X的这些计费数据的关联。其中，会话2由CCF2处理，并且CCF2将处理到来的计费会话直至完成，该完成由接收到ACR[Stop]来指示。接着，CCF2将生成一个保存了该会话a的CDR。该CDR被通过ODBC导向至对于关联对象X的关联主机CCF1

现在参照图2，其中根据现有技术，一个中央节点控制所有的CCF节点暂停它们之间的计费数据交换，该中央节点是一个集中控制CCF节点的专用设备。例如，所有新来的数据将被放置在各个CCF节点的本地缓存中，例如CCF1的本地缓存13和CCF2的本地缓存23中。由于相同的原因，新加入的CCF节点CCF3也被提供给一本地缓存33。值得注意的是，在此时没有数据流入CCF3

参照图3，为了将关联负载分散在3个CCF节点中，对于某些关联对象的关联主机从CCF1或CCF2改变到CCF3。因此，一个“重新归属”过程被执行，其中存储于CCF1和CCF2的这些关联对象的计费数据被转移给新的关联主机CCF3。在这一过程中，新的去到CCF1和CCF2的数据仍然被存储在它们各自的缓存中。

最后，在重新归属之后，中央节点通知3个CCF节点重新建立它们之间的ODBC连接，继续数据交换和关联。

很明显，复杂的加入过程和不足的无法提供服务的服务器处理进程这两者都为这一解决方案的采纳带来了风险。

发明内容

本发明采用一些方式来解决与(a)一个CCF节点被加入以及(b)一个CCF节点不可用相关的问题。

对于(a)，本发明提供了一种在管理元之中的、用于控制CCF节点在分布式数据库架构下实现无缝操作的方法，包括如下步骤：

判断是否有新加入的CCF节点；

如果有新加入的CCF节点，维持预先决定的、各个关联对象与它的关联主机之间的映射不变，向其他CCF节点通知该新加入的CCF的相关信息，并且向新加入的CCF节点通知所述其他CCF节点的相关信息，其中，对于每个相关对象，存在一个CCF节点作为其相关主机。

除此之外，在有新加入的CCF节点的情况下，该方法进一步包括步骤：在包括该新加入的CCF节点在内的所有CCF节点之中为新的关联对象确定关联主机。

除此之外，在有新加入的CCF节点的情况下，该方法进一步包括步骤：如果有新的会话，在包括该新加入的CCF节点在内的所有CCF节点之中确定一个来处理该新的会话。

除此之外，不进行重新归属。

进一步地，对于(a)，提供了一种在管理元之中的用于控制CCF节点在分布式数据库架构下实现无缝操作的第一装置，包括：

第一单元，用于判断是否有新加入的CCF节点；

第二单元，用于如果有新加入的CCF节点，维持预先决定的、各个关联对象与它的关联主机之间的映射不变，向其他CCF节点通知该新加入的CCF的相关信息，并且向新加入的CCF节点通知所述其他CCF节点的相关信息。

除此之外，该第一装置进一步包括第三单元，用于在有新加入的CCF节点的情况下，在包括该新加入的CCF节点在内的所有CCF节点之中为新的关联对象确定关联主机。

除此之外，该第一装置进一步包括第四单元，用于在有新加入的CCF节点的情况下，如果有新的会话，在包括该新加入的CCF节点在内的所有CCF节点之中确定一个来处理该新的会话。

换句话说，对于(a)，该被采纳的方式包括“延迟部署”，以主要用于避免由重新归属处理导致的处理暂停以及延误。

对于(b)，提供了一种在CCF节点中的、用于在分布式数据库架构下实现无缝操作的方法，包括：

判断是否其他CCF节点无法提供服务；

如果一个其他CCF节点无法提供服务，对于关联主机是该无法提供服务的CCF节点的各个关联对象，将所有提供服务的CCF节点中的一个作为该关联对象的关联主机，并且将与该关联对象相关的数据发送给它的新的关联主机以存储，其中，该新的关联主机被通过由所有CCF节点共享的方法来选出。

除此之外，对于各个关联对象，在每个CCF节点处一个主关联主机和一个从关联主机被通过该共享的方法预先确定，当主关联主机变得无法提供服务时，该从关联主机将被作为新的关联主机。

进一步，对于(b)，提供了一种在CCF节点中的、用于在分布式数据库架构下实现无缝操作的第二装置，包括：

第五单元，用于判断是否其他CCF节点无法提供服务；

第六单元，用于如果一个其他CCF节点无法提供服务，对于关联主机是该无法提供服务的CCF节点的各个关联对象，将所有提供服务的CCF节点中的一个作为该关联对象的关联主机，并且将与该关联对象相关的数据发送给它的新的关联主机以存储，其中，该新的关联主机被通过由所有CCF节点共享的方法来选出。

除此之外，对于各个关联对象，在每个CCF节点处一个主关联主机和一个从关联主机被通过该共享的方法预先确定，当主关联主机变得无法提供服务时，该从关联主机将被作为新的关联主机。

换句话说，对于(b)，该被采用的方法包含一个先验的、对于选择主和从关联主机的“早先决定”，以及一个对于每个会话为基础的限定：从关联主机永远不能与主关联主机相同。

通过本发明的至少一个实施方式所获得的优点包括：

-以每个会话基础确定主和从关联主机，使得主机们不会对于任何会话发生冲突，因此增强了可用性/可靠性，超过在通信网络中典型地所期望的59s(99.999％可用性)；

-将容错引入到用于处理关联的DDB架构中；

-通过为正在进行的会话采用延迟部署的策略，消除了重新归属现有会话的需要；

-无缝地引入新的服务器加入，并且将包括关联等处理分布在服务器之间。

附图说明

通过以下的详细描述以及所附的附图，本发明的以上和其他目的、特性和优点将变得更加明显，在附图中：

图1-4示出了根据现有技术的，将一个新的CCF加入到已有的CCF簇的过程；

图5示出了包括4个CCF节点的网络；

图6示出了图5中的网络，其中CCF4无法提供服务；

图7示出了一种在CCF节点之中的、用于控制CCF节点在分布式数据库架构下实现无缝操作的方法的流程图；

图8示出了基于图5的网络，其中一个新的CCF节点被加入到其中；

图9是一种在管理元之中的、用于控制CCF节点在分布式数据库架构下实现无缝操作的方法的流程图；

图10示出了一种在管理元之中的、用于控制CCF节点在分布式数据库架构下实现无缝操作的第一装置的框图；

图11示出了一种在CCF节点中的、用于在分布式数据库架构下实现无缝操作的第二装置的框图。

其中，相同或相似的附图标记用于在这些附图中代表相同或相似的步骤特征/设备(模块)图1是根据本发明的实施方式，用于确定参考信号图样的方法的流程图。

附图中，相同或者相似的附图标识代表相同或者相似的部件。

具体实施方式

例如CCF节点等商用级别的呼叫处理服务器典型地被宣传具有99.9％的可用性/可靠性。这相当于每年大致525分钟的无计划的停运。这是本技术方案所面临的停运级别。这一问题的原因是只决定了单个关联主机的f(ICID)函数。

根据本发明的至少一个实施方式，一个从关联主机被预先确定，以候补主关联主机，这将系统可靠性增加到99.9999％，这相当于每年大致32秒的无计划的停运。在本发明的精神之内，一个第三关联主机可以被预先确定，这可以进一步将可靠性增加到99.9999999％，相当于每年大致0.03秒的无计划的停运。值得注意的是，选取第三关联主机并不是严格要求的。

第一实施方式

下面将考虑1个CTF节点和4个CCF节点对本发明的第一实施方式进行描述。

参见图5，其中，每一个弧线都代表了一个ODBC访问能力，CCF之间的通信通过该ODBC访问能力而被进行。在一个时间点T，4个CCF节点都提供服务。其中，每一个CCF节点都基于一个共享的f(Key)为各个关联对象选择正确的关联主机，并通过ODBC的Write操作将计费相关数据发送给被选中的主机。因此，关联处理负载被均衡地分布在各CCF节点之间。

现在，假设CCF4变得节点无法提供服务，因此在CCF4节点和CCF1-CCF3中的每一个节点之间的接入能力丢失。这影响了以下方面：

(A)正在被CCF4所处理的、关联主机是CCF1-CCF3中的一个的会话；

(B)正在被CCF1-CCF3所处理的、关联主机是CCF4的会话。

(A)无法得到解决，除非CCF4上的数据库对于剩余的CCF节点可接入。例如，如果DDB的架构使用存储局域网络或附加网络的存储，其中可以设计一个变量“数据归属”。一般来说，处理(A)需要存储分离的处理，这由现有的方法所针对。根据本发明的至少一个方式，旨在解决(B)，这将在下文中进行描述。

考虑到这种类型的CCF停运，提供了在CCF节点中的、用于在分布式数据库架构下实现无缝操作的方法。其中，该分布式数据库架构存在于：CCF节点具有各自的、用于存储计费相关数据的数据库，并且关联处理和存储负载都分布在多个CCF节点之间。参见图7，这一方法包括如下步骤：

步骤S51：判断是否任何其它CCF节点无法提供服务；

步骤S52：对于关联主机是该无法提供服务的CCF节点的各个关联对象，将提供服务的CCF节点中的一个作为该关联对象的新的关联主机。

步骤S53：将与该关联对象相关的数据发送给它的新的关联主机以存储。

对于步骤S51，一个CTF节点或CCF节点直接地识别出任意CCF节点的停运。特别地：

一个CTF节点发送一个会话的ACR至CCF1-CCF4中的一个，如果该接收CCF提供服务，它会向该CTF节点发送确认消息。这样，如果一个CTF节点在预设的时间间隔之内无法接收到该确认，那么这可能是由于该CCF节点出了某些问题。在识别一个CCF节点无法提供服务后，该CTF节点将通过IETF RFC 3588切换到一替代的CCF节点，并且将该停运通知给所有其它CCF节点，从而提供服务的CCF节点能够及时采取必要的措施，这将在下文中简述。

如上所述的，当一个CCF节点接收到来源于CTF节点的ACR时，它会处理该ACR向上并包括一个聚合(aggregation)，并将该聚合通过ODBC的Write操作发送给该ACR所属的关联对象的关联主机。因此，由于CCF4停运，如果例如CCF1向CCF4写入，那么它的第一次尝试将会失败。因此，CCF1能够获知CCF4的停运，并可选地通知CCF2和CCF3。替代地，提供服务的CCF节点不必向其它节点通知CCF4的停运，这是因为其它节点迟早会通过一个不成功的向CCF4的Write操作获知这一停运。相应于CCF4的停运，CCF1-CCF3需要为以CCF4作为关联主机的所有关联对象选择替代的关联主机。

在步骤S72中，对于关联主机是该无法提供服务的CCF节点CCF4的各个关联对象，一个提供服务的CCF节点会将提供服务的节点中的一个作为该关联对象的新的关联主机。

特别的，根据本发明的至少一个实施方式，需要一个机制来选择新的主机，同时该新的主机不能与该无法提供服务的主机相同。这样，一个被称作对ICID“模N”的简单方法被设计出来用于确定关联主机。根据一个例子，一旦主关联主机无法提供服务，从关联主机就被决定。替代地，该从关联主机可以随主关联主机一同被预先确定。对于一个关联对象的这两个关联主机可以通过使用公式(1)和(2)来确定：

主关联主机＝ICID 的最后两字节对N取模；     (1)

从关联主机＝(主关联主机索引+1)对N取模；    (2)

使用该公式，主关联主机和从关联主机的索引可以为ICID的最后两字节的所有可能值(00～FFx)而计算出来，表1提供了对于前16个值的结果

表1

在表1中，不同的关联主机索引指示了不同的CCF节点。很明显，通过公式(1)和(2)提供的逻辑的帮助，不但关联处理和存储负载被分散在CCF节点之间，而且对于相同关联对象的主关联主机和从关联主机总是不相重叠。

在实践中，对于每个关联对象的关联主机可以有一个中央元确定，该中央元典型地是CCF节点中的一个，它继而会将确定结果通知给其他CCF节点。替代地，通过共享该相同的方法，即公式(1)、(2)等，该确定可以在各CCF节点上各自进行，同时该结果能够保证是相同的。

为了实现步骤S72，表格2和表格3可以被增加到每个CCF节点中

表2：每个CCF的关联主机选择

序列号	ICID	主关联主机的索引	从关联主机的索引
				1	0ffde..00x	1	2
2	0fedf..01x	2	3
				3	0feef..02x	3	0
4	0ded..03x	0	1

表3：每个CCF的CCF索引和可用性

通过表格2，一个CCF能够获知每个关联对象的主关联主机和从关联主机，其中该关联对象由它们的ICID来指示，关联主机由索引指示，其中索引0指示CCF1，索引1指示CCF2，索引3指示CCF3以及索引4指示CCF4。在表格3中，关联主机的索引进一步与IP地址绑定，并且每个CCF的可用性也被纪录。表格3中的以上该提供服务/无法提供服务指示是很有帮助的，这是因为处理节点能够简单地标示目标关联主机的状态并在主关联主机无法提供服务时决定去从关联主机，而不导致对一个ODBC的Write等待报回的主主机失效的额外的开销。

在步骤S73中，注意到作为CCF4的候补的从关联主机CCF1后，CCF1-CCF3继而将与关联对象相关的数据发送给新的关联主机进行关联处理和存储。

第二实施方式

对于一个新的CCF节点被加入这种情况，延迟部署被采纳，它允许正在进行的会话执行到结束，而不要求重新归属，同时对于新的关联对象的关联主机的确定认识到该新的CCF节点的加入。因此，关联主机的决定以及后继的处理被均衡地分布于CCF节点中。这允许处理的继续进行，避免了在将新委任的CCF节点加入到网络中的同时进行记录移动的CPU开销。

将参照图5，8和9说明第二实施方式，其中沿用了图1中的附图标记以避免困惑。比较图8和图5，有一个新加入的CCF节点，记作CCF5。

如上所描述的，CCF1到CCF4各自维护了如表格2-3所提及的信息。在本实施方式中，假定所有4个CCF节点都提供服务。除了对到/来自CCF5的ODBC访问能力进行激活之外，表格2-3需要被调整以保证：

-现有的会话不需要重新归属，这意味着现有的关联主机和关联对象之间的映射不改变；

-新的会话将被平均地分布于存在的服务器之间；

-在为新的会话计算关联主机时考虑计算新加入的、索引为4的CCF5；

参考图9，示出了根据本发明的一个实施方式的、一种管理元之中的、用于控制CCF节点在分布式数据库架构下实现无缝操作的方法的流程图。在实践中，管理元可以由CCF节点中的一个来实现。

基本地，如图9中所示，该方法包括以下步骤：

步骤S91：判断是否有新加入的CCF节点；

步骤S92：如果有新加入的CCF节点，维持预先决定的、各个关联对象与它的关联主机之间的映射不变；并且

步骤S93，向其他CCF节点通知该新加入的CCF的相关信息；

步骤S94，向新加入的CCF节点通知所述其他CCF节点的相关信息。

除此之外，如果有新加入的CCF节点，管理元将为新的关联对象在包括新加入的CCF节点在内的所有CCF节点之中确定一个关联主机。该关联主机选择可以由一个中央元来进行，该中央元典型地是4个CCF节点中的一个。然后，该中央元将结果通知给所有的CCF节点。替代地，该关联主机选择可以由所有CCF节点各自进行，其中它们共享相同的方法以确保统一的结果。

除此之外，如果有新加入的CCF节点，并且新的会话到来，管理元在包括新加入的CCF节点在内的所有CCF节点之中确定一个主机来处理该新的会话，例如处理与该会话对应的ACR和汇聚。

值得注意的是，图9中的步骤可以被重新排序以形成一个替代的实施方式。例如，步骤94可以放在步骤93之前，或者步骤93和94可以被并行地执行。

在CCF5加入之后，在所有CCF节点处的每个CCF的表格可以包括表格4-5中包含的信息。

表格4：每个CCF的关联主机选择

序号	ICID	主关联主机索引	从关联主机索引
				1	0ffde..00x	1	2
2	0fedf..01x	2	3
				3	0feef..02x	3	0
4	0ded..03x	0	1
				4	0ded..yyx	4	0

表格5：每个CCF的CCF索引和可用性

参见表格4，由于对于前四个关联对象的关联主机在加入CCF5之前已经被计算，这些维持不变。通过比较表格4和表格2可以更加明显地看出来。

参见表格4，对于一个新的关联对象，CCF5可以被自由地选为关联主机，如表格4中最后一项所示。

假定一个呼叫持续M分钟，并且每分钟呼叫到来率为R，那么最多有MxR呼叫在第一表格中被分布于前4个服务器所处理。在第五个服务器加入后，这些呼叫的持续平均结束于M分钟。

平均来说，在加入一个或多个服务器后的M分钟，所有正在进行的会话会均衡地分布于提供服务的服务器之间。

下面将参考图10-11对根据本发明的至少一个实施方式的第一装置和第二装置进行说明。

参见图10，一种在管理元之中的、用于控制CCF节点在分布式数据库架构下实现无缝操作的第一装置100。该第一装置100包括：

第一单元1001，用于判断是否有新加入的CCF节点，该功能对应于图9中的步骤91；

第二单元1002，用于如果有新加入的CCF节点，维持预先决定的、各个关联对象与它的关联主机之间的映射不变，向其他CCF节点通知该新加入的CCF的相关信息，并且向新加入的CCF节点通知所述其他CCF节点的相关信息，该功能对应于图9中的步骤92至94。

除此之外，第一装置100还包括第三单元1003，用于在有新加入的CCF节点的情况下，在包括该新加入的CCF节点在内的所有CCF节点之中为新的关联对象确定关联主机。

除此之外，该第一装置100进一步包括第四单元1004，用于在有新加入的CCF节点的情况下，如果有新的会话，在包括该新加入的CCF节点在内的所有CCF节点之中确定一个节点来处理该新的会话。

参见图11，一种在CCF节点中的、用于在分布式数据库架构下实现无缝操作的第二装置110，包括：

第五单元1101，用于判断是否其他CCF节点无法提供服务，该功能对应于图7中的步骤71；

第六单元1102，用于如果一个其他CCF节点无法提供服务，对于关联主机是该无法提供服务的CCF节点的各个关联对象，将所有提供服务的CCF节点中的一个作为该关联对象的关联主机，并且将与该关联对象相关的数据发送给它的新的关联主机以存储，其中，该新的关联主机被通过由所有CCF节点共享的方法来选出，该功能对应于图7中的步骤72-73。

尽管本发明的优选实施方式已经在上面进行了描述，但是本发明的保护范围并不被它们所限。本领域的技术人员可以在不脱离本发明的范围和精神的条件下进行简易的修改，所有这些修改都应被视为处于本发明的保护范围之内。因此，本发明的保护范围应由权利要求的保护范围所决定。

Claims (13)

1.一种在管理元之中的、用于在分布式数据库架构下实现无缝操作的方法，包括如下步骤：

判断是否有新加入的CCF节点；

如果有新加入的CCF节点，维持预先决定的、各个关联对象与它的关联主机之间的映射不变，从而该关联对象维持在它们目前的CCF节点上，并且，向其他CCF节点通知该新加入的CCF的相关信息，以及向新加入的CCF节点通知所述其他CCF节点的相关信息，其中，对于每个相关对象，存在一个CCF节点作为其相关主机。

2.根据权利要求1所述的方法，其中，在有新加入的CCF节点的情况下，该方法进一步包括步骤：

在包括该新加入的CCF节点在内的所有CCF节点之中为新的关联对象确定关联主机。

3.根据权利要求1所述的方法，其中，在有新加入的CCF节点的情况下，该方法进一步包括步骤：

如果有新的会话，在包括该新加入的CCF节点在内的所有CCF节点之中确定一个来处理该新的会话。

4.根据权利要求1-3中任一项所述的方法，其中，不进行数据的重新归属。

5.一种在CCF节点中的、用于在分布式数据库架构下实现无缝操作的方法，包括如下步骤：

判断是否其他CCF节点无法提供服务；

如果其他CCF节点无法提供服务，对于关联主机是该无法提供服务的CCF节点的各个关联对象，将提供服务的CCF节点中的一个作为该关联对象的关联主机，并且将与该关联对象相关的数据发送给它的新的关联主机以存储，其中，该新的关联主机被通过由所有CCF节点共享的方法来选出。

6.根据权利要求5所述的方法，其中，对于各个关联对象，在每个CCF节点处一个主关联主机和一个从关联主机被通过该共享的方法预先确定，当主关联主机变得无法提供服务时，该从关联主机将被作为新的关联主机。

7.一种在管理元之中的、用于控制CCF节点在分布式数据库架构下实现无缝操作的第一装置，包括：

第一单元，用于判断是否有新加入的CCF节点；

第二单元，用于如果有新加入的CCF节点，维持预先决定的、各个关联对象与它的关联主机之间的映射不变，从而该关联对象维持在它们目前的CCF节点上，并且，向其他CCF节点通知该新加入的CCF的相关信息，以及向新加入的CCF节点通知所述其他CCF节点的相关信息。

8.根据权利要求7所述的第一装置，进一步包括：

第三单元，用于在有新加入的CCF节点的情况下，在包括该新加入的CCF节点在内的所有CCF节点之中为新的关联对象确定关联主机。

9.根据权利要求7所述的第一装置，进一步包括：

第四单元，用于在有新加入的CCF节点的情况下，如果有新的会话，在包括该新加入的CCF节点在内的所有CCF节点之中确定一个来处理该新的会话。

10.一种在CCF节点中的、用于在分布式数据库架构下实现无缝操作的第二装置，包括：

第五单元，用于判断是否其他CCF节点无法提供服务；

第六单元，用于如果其他CCF节点无法提供服务，对于关联主机是该无法提供服务的CCF节点的各个关联对象，将所有提供服务的CCF节点中的一个作为该关联对象的关联主机，并且将与该关联对象相关的数据发送给它的新的关联主机以存储，其中，该新的关联主机被通过由所有CCF节点共享的方法来选出。

11.根据权利要求10所述的第二装置，其中，对于各个关联对象，在每个CCF节点处一个主关联主机和一个从关联主机被通过该共享的方法预先确定，当主关联主机变得无法提供服务时，该从关联主机将被作为新的关联主机。

12.一种控制元，包括根据权利要求7-9中任一项所述的第一装置。

13.一种CCF节点，包括根据权利要求10或权利要求11所述的第二装置。

Images