保持客户端/服务器系统内的分布式复制内容的高度一致性的方法和系统

摘要

说明一种保持被分布至多层客户端/服务器数据处理系统的应用层的多个独立处理从结点（210、210’、210’’）部分的复制文件的一致性的方法和系统。复制文件被从主机层的主结点分布。当接收到更新主数据库的更新请求（142）时，复制文件的新版本被首先生成并存储在共享文件系统（160）内。然后，新版本的可用通知被转发至同步从结点，并从那里向所有从结点（210、210’、210’’）广播。每个从结点从共享文件系统（160）预加载复制文件的新版本（150）并确认成功结束。当在同步从结点接收到所有确认通知时，预加载完成通知被转发至更新主数据库的主服务器（112），从而承诺数据处理系统使用新版本。此承诺还被向同步从结点转发，其进而承诺复制文件的新版本（150）在旨在为所有从结点（210、210’、210’’）跟踪所有复制文件版本的从数据库中的使用。当接收到关于所有从结点（210、210’、210’’）的承诺通知时，主服务器（112）确认响应于所接收的更新请求（142）的完成更新。

说明书

技术领域

本发明一般涉及数据处理系统，特别涉及分布式客户端/服务器软 件结构，更特别地，本发明涉及一种可保持被分布至多个处理结点的 高速缓存文件的内容之间的一致性，同时可保证其准实时可用性的方 法和系统。

背景技术

在二十世纪八十年代末期出现的客户端/服务器模型是一种多用 途且模块化的软件结构，与当时已成规范的集中式、大型机、分时计 算相比，其旨在提高易用性、灵活性、互操作性和可扩展性。此后， 客户端/服务器结构已经逐步完全地取代了以前的大型机用软件结构。 在大型机用软件结构中，所有信息都在中央主机内，用户通过非智能 终端与主机互相联系。然而，在各种客户端/服务器结构中，如果仍使 用大型机，则大型机仅充当功能强大的服务器的角色，其中，非智能 终端也已被智能图形用户界面（GUI）代替，其能够自行处理从服务 器接收的数据和向服务器传递的数据。

在现代数据处理系统中，被大量使用并能够支持很多远程客户端 的客户端/服务器结构是所谓的三层结构。此结构的一个实施例被用图 1说明。主机层100通常围绕数据库系统120建立，数据库系统120可以 是任何企业组织、公司和所有者为实施多种商业操作和管理操作而进 行的日常操作所必需的所有数据的大或很大的库。数据库主要为关系 型数据库，换言之，数据库被关系型数据库管理系统或RDBMS控制。 通常，数据库被数据处理系统的管理者通过一台以上的主服务器112 从多个GUI140来管理。管理者一般都是系统的独占用户，其被授权 直接更新数据库内容。

如图1所示的示例性的三层系统的中间层或中层是应用层200，组 织（数据处理系统的拥有者）的所有特定的软件应用240均被从所述应 用层200运行。该特定应用集合，常被称作中间件软件，是组织的专有 软件。其用来从其数据库120通过主服务器110为该组织的所有远程客 户端服务。远程客户端构成三层结构的第三层300。因此，来自客户端 层300的询问被中间层200的特定应用软件基于从主机层100取出的数 据进行处理和应答。

在三层结构中，当多名远程客户端需要被服务时，通过在中间层 增加独立处理结点以增加数据处理系统的综合处理能力，获得可保持 整体性能的系统的可扩展性。因此，应用层200通常包括多个独立处理 结点，在以下说明中，独立处理结点被称作从结点210。那么，防止主 机层100被来自增多的从结点的过多的数据请求击溃的一种常用手段， 是使应用处理240针对只要有必要，就从主数据库取出并存储在每个应 用结点的各数据块进行工作。在如图1所示的示例性的系统中，这以应 用处理240工作所针对的高速缓存文件250的形式出现，其不会因每次 需要时都通过主服务器从主数据库获取而导致长延迟。因此，在如上 所述的数据处理系统中，处理能力和应用软件集被根据需要分布即分 割至多个结点210，从而达到该系统为所有远程客户端300服务所需的 处理能力水平。分布式的高速缓存文件250也是这样。

然而，已经证实：在如上所述的分布式计算环境下，不能同时完 全保证某些分布式数据处理系统的期望性质。如图2所示，分布式数据 处理系统的这些期望性质40是一致性、可用性、可扩展性。一条被称 作CAP定律的定律阐明：分布式系统能够同时满足三个性质中的任意 两个性质但不能同时满足所有三个性质。CAP代表一致性、可用性和 分割容差（partition tolerance），是由E.Brewer教授于2000年在美国 加州大学伯克利分校首次提出的。N.Lynch和S.Gilbert后来在其撰 写的论文内论证了该定律，此论文于2002年被发表在ACM SIGACT  News，v.33issue2,pages51-59。如上所述，系统的综合处理能力实 际是通过分布即分割该至各独立处理结点来获得的，所以CAP分割容 差性质是与可扩展性紧密联系的。

在三层结构中，只要被中间层应用使用的数据始终来自主数据 库，一致性和可用性41就能够被完全满足。获得这种满足，是以仅因 应答来自客户端层300的查询而产生很高的从主机层100到应用层200 的下行通信量，以及因应答这些查询而导致主数据库的占有率非常高 为代价的。这导致与管理级用户(140)对主数据库的管理和更新相冲 突，即使写入数据库的几率通常较低。在客户端层的用户数量增加的 情况下，对数据库的访问和数据和应用层之间的网络上的流量明显成 为限制性能的瓶颈。

在如图1所示的示例性的3层结构中，为了解决上述数据库占有率 以及数据与应用层之间的高流量的问题，通过分布式高速缓存文件250 来满足可用性和可扩展性42。然而，在这种情况下，因为高速缓存文 件被分布至各独立计算结点，所以不能保证其内容在各从结点之间保 持一致，且不能保证其内容与主数据库的内容保持一致。

本发明的目的在于提供一种解决此问题的技术方案。在客户端应 用和复制文件被分布至多个独立从结点的三层客户端/服务器结构中， 本发明公开一种保持各复制文件内容之间的高度一致性和完全可用性 并同时保持相当的可扩展性43的方法和系统。

而且，当参照附图审查下述说明时，本发明的诸多目的、特征和 优点对于本领域技术人员来说能够变得显而易见。任何额外的优点均 意在被包含在本说明书内。

发明内容

根据一方面，本发明描述了一种保持被分布至多层客户端/服务器 数据处理系统的应用层的多个独立处理从结点部分的复制文件的一致 性的方法，所述复制文件被从主机层的主结点分布。所述方法包括被 用至少数据处理器执行的下述步骤：

-至少在主机层的主服务器处接收更新请求，以更新数据处理系 统的主数据库；

-根据所述更新，生成并存储被存储在主机层的共享文件系统内 的复制文件的新版本；

-向所有从结点提供复制文件的新版本的可用性通知；

-在每个从结点，启动从共享文件系统预加载复制文件的新版 本，而且当预加载结束时，确认预加载成功结束，

●只有当所有从结点确认预加载成功结束时，执行下列步骤：

-在主服务器处接收预加载完成通知；

-从主服务器处用复制文件的新版本的数据来更新主数据库，从 而承诺复制文件的新版本被主机层使用；

-承诺复制文件的新版本的在被布置为保持跟踪所有复制文件 版本的应用层的从数据库中的使用；

-向主服务器转发所有从结点的承诺通知；

-从主服务器确认响应于接收到的更新请求的更新完成，

●如果不是所有从结点确认预加载成功结束，则在主结点接收错 误通知，而不更新主数据库，也不承诺新版本在从数据库中的使用。

由此，本发明提供了一种用于以近似实时的方式响应对信息的查 询、并同时在包含响应该查询所需的信息块的可能的大量节点上保证 高度一致性的有效方案。因此本发明使得能够以很短的延迟和增强的 可扩展性保持高度一致性和可用性。

可选地，本发明可包括以下可选特征中的至少一个：

在本发明中，被称为复制文件的是从主站复制的、并如此被送入 从节点以促进相应数据被应用处理所处理的完整文件。他们本身不是 从较慢的后端存储器送入高速缓冲存储器的小的数据块。在本发明的 背景中，也称为复制品的复制文件实际上是从节点中的应用处理可针 对其进行工作而不会经受任何要完成数据的丢失的完整文件。

根据具体但非限制性的实施例，也称为复制品的复制文件是高速 缓存文件。

向所有从结点提供复制文件的新版本的可用性通知的步骤包括 下列步骤：

-从主服务器向从结点中选定的同步从结点转发复制文件的新 版本的可用性通知；

-从同步从结点向所有其它从结点广播所述可用性通知。

确认预加载成功结束的步骤包括从结点向同步从结点的服务器 处理确认预加载成功结束的步骤。

一旦所有从结点向同步从结点的服务处理确认预加载成功结束， 并且在主服务器处接收到预加载完成通知的步骤之前，同步从结点向 主服务器转发所述预加载完成通知。

当承诺复制文件的新版本被主机层使用的步骤结束时，主结点向 同步从结点转发承诺通知，然后同步从结点触发承诺复制文件的新版 本在从数据库中的使用的步骤。

在被来自用户的信息查询启动的事务开始时，至少在所述事务所 所涉及的每个从结点处，应用处理询问从数据库并被指示是否从复制 文件的当前版本切换至被预加载的复制文件的新版本。

优选地，在被来自用户的信息查询启动的事务开始时，在所述事 务所涉及的每个从结点，应用处理读取复制文件的当前版本的标记， 所述标记指示复制文件的新版本是否可用。如果标记指示复制文件的 新版本是可用的，则应用处理询问从数据库并被指示是否从复制文件 的当前版本切换至复制文件的新版本。

当复制文件的新版本的预加载成功结束时，设置标记；并且当应 用处理被首次读取时，重置标记。

被接收的更新请求至少包括更新，而且在共享文件系统内生成并 存储的复制文件的新版本的步骤是包括在主服务器中的以下步骤的增 量式处理：

从共享文件系统检索复制文件的当前版本并将要被更新的复制 文件的当前版本转换成适当格式，

将更新应用至当前版本，然后将复制文件的新版本转换并存储到 共享文件系统。

当复制文件被存储在共享文件系统内时，复制文件被压缩。

共享文件系统内存储的复制文件当执行增量式更新时被主服务器 解压并转换成适当格式，而当预加载时被从结点解压并转换成适当格 式。

如果不是所有从结点都确认预加载成功结束，则主结点向发送所 述更新请求的管理者发送错误通知。

主数据库可存储在主机层的单个机器或多个机器中。从数据库可 存储在应用层的单个机器或多个机器中。

共享文件系统是网络连接式存储NAS。

根据另一方面，本发明涉及一种被存储在非暂时性计算机可读存 储介质中并实行根据以上特征所述的方法的计算机程序产品。

根据另一方面，本发明涉及一种保持包含业务规则的复制文件的 一致性的方法，所述复制文件被分布至构成多层客户端/服务器数据处 理系统的应用层的一部分的多个独立处理从结点上，所述复制文件被 从主机层的主结点分布，其中所述方法包括被用至少数据处理器执行 的下述步骤：

-至少在主机层的主服务器处接收更新请求，以更新存储在数据 处理系统的主数据库中的业务规则；

-基于所述更新，生成并存储被存储在主机层的共享文件系统内 的复制文件的新版本；

-向所有从结点提供复制文件的新版本的可用性通知；

-在每个从结点，启动从共享文件系统预加载复制文件的新版 本，而且当预加载结束时，确认预加载成功结束，

●只有当所有从结点确认预加载成功结束时，执行下列步骤：

-在主服务器处接收预加载完成通知；

-从主服务器处用复制文件的新版本的数据来更新主数据库，从 而承诺复制文件的新版本被主机层使用；

如果不是所有从结点确认预加载成功结束，则在主结点接收错误 通知。

可选地，本发明可包括至少一个以下特征。

有利地，每个业务规则包括标准和内容集合。优选地，每个标准 与权重相关联，从而使得在进行搜索时，搜索引擎能够识别最相关的 规则。

标准集合包括销售点、国家、国家组、飞行起点国家、飞行目的 地和用户简档中的至少一个。

多层客户端/服务器数据处理系统是旅行提供商的库存的一部分。

更一般地，从节点连接到航空公司库存、航空公司出发控制系统、 航空公司收益管理系系统、航空公司收益账目系统、航空公司电子票 服务器中的至少一个。

本发明的另一方面是一种分布式多层客户端/服务器数据处理系 统，该系统包括应用层和主机层，所述应用层包括多个独立处理从结 点。所述主机层包括被布置为将复制文件分布至从结点的主结点、主 数据库和主服务器。所述主机层包括共享文件系统和主服务器，所述 主服务器被布置为接收更新请求以更新主数据库、生成被存储在共享 文件系统内的复制文件的新版本、并将所述新版本存储在共享文件系 统中。根据本发明的所述系统还包括从数据库，所述从数据库与所有 从结点连接，并被布置为保持跟踪所有复制文件版本。所述系统被配 置为：

●向所有从结点提供复制文件的新版本的可用性通知；

●在每个从结点处，启动从共享文件系统预加载复制文件的新版 本，而且当预加载结束时，确认预加载成功结束；

●只有当所有从结点确认预加载成功结束时，实施下列步骤：在 主服务器处接收预加载完成通知；从主服务器用复制文件的新版本的 数据更新主数据库从而承诺复制文件的新版本被主机层使用；承诺复 制文件的新版本在从数据库中的使用；向主服务器转发所有从结点的 承诺通知；从主服务器确认响应于接收到的更新请求的更新完成，

●如果不是所有从结点确认预加载成功结束，则在主结点处接收 错误通知，而不更新主数据库，并且不承诺新版本在从数据库中的使 用。

附图说明

图1图示标准分布式三层数据处理系统的示例；

图2论述分布式数据处理系统的一致性、可用性和可扩展性；

图3说明根据本发明的示例性数据处理系统，其中，主数据库的 内容被以复制文件的形式分布至从结点；

图4包括图4a和图4b，其说明用于获得根据本发明的数据处理 系统的分布式复制文件之间的高度一致性的方法的步骤；

图5说明当生成复制文件的新版本（Vn+1）时被执行的增量式 更新。

实施例

关于本发明的下述详细的说明参照附图。虽然此说明包括多个示 例性实施例，但是其它的实施例是可能存在的，而且在不脱离本发明 的精神和范围的前提下，可以对多个被说明的实施例做出变更。

图3说明根据本发明的示例性的分布式数据处理系统，其包括应 用层200和也被称作数据层100的主机层100。应用层200包括多个 独立处理从结点210、210’、210’’。主机层100包括主结点110、主数 据库120和主服务器112。主数据库120的内容被以复制文件250、150 的形式分布至从结点210、210’、210’’，以便在这些从结点210、210’、 210’’上运行的客户端应用240、240’、240’’能够无须询问主数据库120 地使用对应的数据块。

主机层100包括含有一台以上的服务器112的主结点110。主机 层100负责管理系统的数据库即主数据库120，其一般为一个大或很 大的数据库系统，其保持为进行任意类型的大型业务活动所需要的所 有数据，包括商业与工业应用、还可能覆盖各种管理活动、教育活动 和政府活动。例如，在航空公司和旅行行业，此数据库系统例如可能 是全局分布式系统，或GDS。GDS是允许实时访问航线费用、时刻 表和可用座位以及一般的任何旅行产品的旅行行业公司妥善设置的任 何大型数据处理系统。GDS通过多个在线旅行网站为旅行社和个人提 供从世界各地预定保留的座位并生成旅行票的能力。

任意被授权的用户通过主服务器112从系统的用户界面140（通 常是图形用户界面（GUI））管理这样的数据库120。数据库的管理 级用户是那些被允许更新数据库的内容的用户，例如，就GDS来说， 允许其添加或修改适用于预定旅行票的商务规则，或者允许其更改旅 行产品报价。这主要包括对旅行产品的当前报价进行更新的情况。因 此，必须将更新依次地复制在分布式复制文件内，所述分布式复制文 件供在从结点210、210’、210’’运行的客户端应用240、240’、240’’ 使用。

主机层110还包括共享文件系统160，例如网络连接式存储或 NAS系统160，其旨在保存根据管理级用户的请求生成的复制文件的 新版本。用图4进一步解释所述系统的NAS160和其它元器件的用途。 图4论述一种保持从结点210、210’、210’’的各分布式复制文件与主 数据库120的内容一致的方法。

就客户端应用层200而言，其包括多个从结点210、210’、210’’， 每个从结点均能够为构成所述系统的第三层（未被显示在图3里）的大 量远程终端用户服务。例如，在GDS的上述例子中，这些远程终端用 户包括常规旅行社的旅行代理和通过公用网（即通过互联网）与在线 旅行网站连接的网站的个人用户。这样一来，启动从结点210、210’、 210’’的应用处理240、240’、240’’的很多不同的软件客户端应用能够 通过进入到从结点210、210’、210’’的共享存储器230、230’、230’’内 的复制文件来运行。因此，这些应用中的任意应用能够便利地访问这 些应用所需的数据，而且不需要为其中的每一个应用程序复制所述数 据，从而大幅度地减少存储器使用。在从结点210、210’、210’’上运行 的应用软件产品的范围和数量可能相当可观，而且实际上仅受所述结 点的计算资源的限制。其主要取决于所述数据处理系统的所有者所实 施的业务的类型。就GDS而言，在旅行行业，其包括特定应用，诸如 如今为所有旅行者提供的电子预定和出票服务以及机场旅客出行控制 等。针对任何类型的业务的更普通的应用包括关于商品和服务的可用 性、收益管理和收益核算的那些应用。因此，应用层200的用户并不限 定为客户，而是还包括负责管理拥有该数据处理系统的公司的资产的 专业人士。

所述客户端应用层200还包括从数据库260，其负责存在于每个从 结点210、210’、210’’的、控制复制文件的新版本（Vn+1）150的调度 的特定服务器处理任务220、220’、220’’，所述复制文件被任意主服务 器112基于所述数据处理系统的管理级用户的请求最初存储在NAS系 统160内。实质上，所述从数据库目的在于保持跟踪被保存在从结点 210、210’、210’’的共享存储器230、230’、230’’内的复制文件的版本， 以便一方面强制被分布至从结点210、210’、210’’的复制文件的新版本 150与当前版本250之间的高度一致性，另一方面强化与主数据库120 内容的高度一致性。有利地，该从数据库260仅存储与复制文件的版本 有关的数据，而不存储该复制文件的内容。

以下，用图4说明使如图3所示的示例性数据处理系统能实现该效 果的处理。

所有构建根据本发明的系统的软件构件可由能够在一个或多个 互联网络上通信的各种个人计算机或计算机化平台30、30’、30’’实现 和运行。这样的网络一般是形成企业网络的局域网或LAN。LAN按照 标准通信协议集运行。在大多数情况下，使用使互联网的传输控制协 议（TCP）与互联网协议（IP）自身关联的TCP/IP协议套件。实际上， 通过信息交换来实现各个计算机化平台与软件构件之间的通信。例如， EDIFACT（管理、商业和运输电子数据交换）消息，一个被联合国（UN） 组织和国际航空运输协会（IATA）提倡的标准，可以用来在数据处理 系统的各个软件构件之间建立通信信道。一般地，通过企业服务总线 （未被显示），也被称作服务集成器（SI），交换消息。

图4包括图4a和图4b，其说明用于获得根据本发明的数据处理系 统的分布式复制文件之间的高度一致性的方法的步骤，其中，所述数 据处理系统已用上一图说明并论述。

用于在所述系统内更新数据的两阶段承诺进程中的第一阶段被 显示在图4a里。该阶段被授权的管理级用户触发，通过主结点100的多 台主服务器中的一台启动更新事务。从一般的用户界面，通常为图形 用户界面（GUI），按照发送1更新请求142至主服务器112的如图5所 示的方式执行启动。这是更新数据的处理的第一步骤或步骤1。

负责的主服务器112实施步骤2，当接收到更新请求142时，主服 务器112生成对应的复制文件的新版本150（Vn+1）并将其存储在NAS 系统160内。为了加速生成新复制文件150，有利地，执行上一版本250 的增量式更新。以下，用图5说明增量式更新。无论使用哪种方法，此 步骤的最终结果都是使得复制文件的新版本（Vn+1）150在NAS160 针对整个数据处理系统可用。

其次，在步骤3，必须进行新复制文件150的可用性通知。这经由 从结点210、210’、210’’中的一个从结点（例如如图3所示的从结点210） 来实现。为此，负责的主服务器112向服务器处理220、220’、220’’（即 在该节点和所有其它从结点210’、210’’上执行的特定软件任务）发送 消息。从那时起，被选定的从结点210于是充当针对系统的所有从结点 210、210’、210’’的同步点。因此，在本发明的下述说明中，将此从结 点210称作“同步从结点”210。从主机层的角度看，所有从结点发挥同 样的作用。因此，同步从节点的选择通常是基于工作负荷的考虑。

下一步骤即步骤4包括在同步从结点210的服务处理220任务的控 制下向所有其它从结点210’、210’’广播复制文件的新版本150的可用性 通知。

然后，在步骤5，当接收到新复制文件150的可用性通知时，每个 从结点210、210’、210’’，包括同步从结点210在内，实施下列两个子 步骤：

-复制，即从NAS系统160预加载51新的可用的复制文件150，其 已被主管执行更新的主服务器112预先存储在所述NAS160内。

-一旦预加载已完全结束，每个从结点210、210’、210’’的服务 器处理220、220’、220’’任务向同步从结点210发送回成功结束确认52。

同步从结点210的服务处理任务220还负责收集所有预加载成功 结束的确认。当预加载完成时，随即向负责的主服务器112转发在所 有从结点210、210’、210’’成功完成预加载6的通知。这是整体更新 处理的步骤6。在此步骤中，新复制文件150已被预加载在每个从结 点210、210’、210’’的共享存储器230、230’、230’’内，因此可供在这 些从结点运行的客户端应用使用。然而，新复制文件150保持不活动 的状态，直到执行了更新处理的下列步骤为止。

用于在所述系统内更新数据的处理中的第二阶段被显示在图4b 里。在步骤6中，当主服务器接收到新复制文件150被所有从结点210、 210’、210’’成功预加载完成的通知时，第二阶段开始。同步从结点210 的服务处理任务220发出预加载完成的通知。接着，在步骤7，负责的 主服务器112将新复制文件150版本（Vn+1）的数据存储在主数据库120 内。从而，向整个数据处理系统承诺新版本150的使用。

需要实施步骤8来进一步完成承诺步骤，，即由主服务器112向 同步从结点210的服务器处理220任务发出承诺消息，以便通知后者 新预加载的复制文件（Vn+1）150已准备好被使用。

在步骤9，当接收到承诺消息时，同步从结点210的服务器处理 任务220实际上还在从数据库260内承诺复制数据文件的新版本150。 此外，在该阶段，从结点210、210’、210’’的客户端应用实际上没有 使用已被预加载到各从结点210、210’、210’’的新版本150，直到下述 切换步骤出现为止。

尽管如此，在步骤10，主服务器112接收来自同步从结点210 的服务器处理220任务的回复，该回复通知主服务器完成了在从数据 库260内的承诺。在步骤11，向数据处理系统的管理级用户的数据处 理装置140进一步传播此回复，以便通知所述管理级用户被请求的更 新请求142确实已被承诺，并且到目前为止有效。

然而，当应用处理实际需要复制文件的新版本150以响应对信息 的查询时，所述复制文件的新版本150的实际使用将仅在系统内生效。 在本发明中，对信息的查询是一种要求对存储在系统内的数据进行检 索以执行的查询，而更新请求要求更新要执行的存储数据。因此，所 述系统的终端用户（例如顾客或旅行代理）发送对信息的查询，而负 责更新与被提供给所述终端用户的产品、服务或信息相关的数据的管 理级用户发送关于更新的请求142。当执行一个应用程序时，对应的 客户端应用始终从数据库260检查264必须使用所需要的复制文件的 哪个版本。如果新版本150是可用的，则使到已被预加载在共享存储 器内的该新版本150的切换起作用。该切换在这一点上遵循为数据库 事务定义的ACID规则，即：原子性、一致性、隔离性、耐久性，从 这个意义上讲，该切换是所谓的原子操作。原子性意味切换被完全执 行且不被任何其它处理中断，从而客户端应用不引发延迟。同样的机 制被用于所有客户端应用处理。此方案保证来自任意分布式副本的所 用数据的高度一致性。因为切换属于原子操作，所以当检索复制文件 的新版本150时，不可能冻结应用处理。既然在执行更新处理的早期 已经预加载复制文件，在客户端应用访问复制文件的新版本150时， 不会进一步引入延时。

可以有利地修改应用处理流程以优化对从数据库260的请求的次 数。确切说来，有必要仅在在新高速缓存版本的预加载与在从数据库 260中承诺此新版本之间的转换期间访问此同步点。

为此，在预加载操作期间，将“预加载”标识符附加于共享存储器。 如果此标识符没有出现，则应用处理将访问高速缓存的最新可用版本， 而无需执行对从数据库260的请求。否则，执行对从数据库260的请求， 然后使用来自从数据库260的版本。

如果被预加载的版本已在从数据库260进行了承若，则执行上述 的切换操作。在此操作中，从共享存储器移除“预加载”标识符。

用以上多张附图说明的机制解释了如何使复制文件准实时地对 从结点210、210’、210’’可用，该机制清楚地区别系统的两种类型的结 点的两种类型的行为：

-主节点110是可能包括多台主服务器112的写入结点。多台主服 务器112中的每一台主服务器使得可以通过数据处理系统的任意授权 管理级用户经由用户界面140来管理所发布的事务。管理事务意味着最 终更新主数据库120。为此，如上所述，管理事务处理首先生成复制文 件的新版本（Vn+1）150并将其存储在NAS系统160内。本发明假设： 主结点110不知道从结点210、210’、210’’的拓扑结构，而且不负责将 数据进一步推入从结点210、210’、210’’。因此，应用200的可扩展性 完全与主节点110无关。

-相反地，从结点210、210’、210’’通过直接从共享的NAS系统 160预加载复制文件，来自己获得复制文件的只读副本。通过先前提到 的企业服务总线或服务集成器（SI），向从结点210、210’、210’’广播 信息。为了尽可能高地保持性能，有利地将被广播的数据量保持为最 小。为了达到此目的，如图4所解释的那样，本发明的方法设法向从结 点210、210’、210’’仅广播新复制文件的可用性通知，从而允许其从公 共的共享文件结构，即NAS160复制新复制文件150。

准实时复制意味着：管理事务一结束，即在如图4所论述的步骤 11中，所有客户端结点都确实能够切换至复制文件的新版本150。此类 型的复制也通称为勤奋型复制，其远比通常被形容为懒惰复制的其它 类型的较不严格的复制更有约束力。为了获得此结果，本发明将数据 流分成控制流和数据流。因此，如上所述，通过服务集成器，向客户 端结点广播将使用的复制文件版本的通知。就复制文件的数据而言， 使他们从共享文件系统，即NAS系统160可得。只有载有版本的控制流 需要通过同步从结点210被传递并路由到应用层200的所有其它从结点 210’、210’’，而数据能够被并行地直接转移至每一个从结点210、210’、 210’’。此结构满足在主节点100的服务器112（即写入器）与从结点210、 210’、210’’之间产生分离的需要。因此，写入器仅需要首先将新数据 存入NAS共享文件系统内，然后存储在主数据库120自身内。写入器不 需要知道从结点210、210’、210’’的拓扑结构的任何信息。主服务器即 写入器借助服务集成器向从结点210、210’、210’’路由版本信息。

用图5说明写入NAS的共享文件结构。此图说明了在步骤2当生成 复制文件的新版本（Vn+1）150时执行增量式更新。

使复制文件可用，即从共享文件结构（例如NAS系统160）公开 复制文件可提供额外益处。负责处理更新请求142的主服务器112能够 便利地访问NAS的共享文件结构以获取152被所有从结点210、210’、 210’’当前使用的复制文件的最近版本250。为了便于检索复制文件， 而且还为了最小化存储需要，有利地设计为二进制结构的NAS160。 因此，复制文件能够被压缩以进一步限制保存所有的复制文件所需的 存储总量。在访问时间与存储要求之间可能必须做出折中，以使得允 许在与数据处理系统的期望性能相适应的访问时间内检索复制文件， 同时以某种方式限制要求的存储量。还应考虑因转移文件而导致的网 络带宽消耗。无论采用哪种折中方案，主服务器都需要将被检索的复 制文件转换成业务对象模型（BOM）114，主服务器能够处理所述业 务对象模型到服务器存储器。然后，主服务器112可以通过将被请求的 更改加入复制文件的当前版本以插入被管理级用户用更新请求142请 求的修改，从而实现增量式更新116，。

更确切地，主服务器需要将被检索的复制文件转换成C++业务对 象模型114到服务器存储器中。然后，主服务器112可以通过添加更新 来针对此C++结构执行增量式更新116。于是，基于此新C++结构生成 了新的复制文件。

与来自主数据库120的相应信息的检索相比，此方式能够大幅度 地加速用于生成复制文件的新版本的处理。可以实现平均提高一个数 量级（10×）的改进。最后，将被更新的复制文件转换并存储回到154 NAS共享文件结构160。

以下进一步论述本发明上下文中的高度一致性意味什么，以及如 何凭借如上所述的系统和方法在各自在不同的物理机器30、30’、30’’ 上实现的从结点210、210’、210’’的所有复制文件中获得高度一致性。

在本发明的数据处理系统中，假设主数据库120被有规律地更新。 尽管该特征可能取决于本发明的应用而显著变化，但所考虑的一般更 新频率约为每分钟若干次。每次更新产生复制文件的新版本（Vn+1） 150。于是，如果从给定版本（例如版本N）的复制文件在给定从结点 被读取开始，在任何其它从结点210’、210’’上的任何后续读取确实返 回相同的复制文件版本N，则高度一致性被实现。明显地，如果与此 同时新版本150已被分布，则也可以读取到更高版本。

通过向所有从结点210、210’、210’’提供跟踪所有复制文件的有 效版本的中心访问点，来实现一致性。优选地，此访问点被实现为在 标准关系型数据库管理系统（RDBMS）的控制下运行的数据库的表， 以保证满足ACID性能。在本发明的系统中，如图3所示，从数据库260 扮演此角色。262显示所存储的版本表的节录。在图示的例子中， BA-NGI与Vn+1相对应，其意指必须使用复制文件的版本（Vn+1）， 换言之，由旅行供应商英国航空公司（BA）操作的NGI应用的数据。 NGI是新一代存储库（New Generation Inventory）的首字母缩略词， 区别哪个特定的应用是给定规则数据的所有者，即负责给定的规则数 据。存储在从数据库中的中心版本表利用如图4所示的2阶段承诺处理 来更新。

然后，当被在从结点上运行的客户端应用启动的每项事务开始 时，有效复制文件的版本被从从数据库260的版本表262取出264。如果 被发现的有效复制文件版本比当前所用的版本新，则从结点210、210’、 210’’立即切换到新复制文件（Vn+1）150。如用图4所解释的那样，这 是可能的，因为更新的复制文件已被预加载到从节点210、210’、210’’ 的共享存储器230、230’、230’’内。在此，值得注意的是：如果被客户 端应用启动的事务需要多次访问复制文件，则所述系统设法在此事务 有效期间使用相同版本，即使与此同时新版本150已变为可用。这满足 适用于数据库事务的ACID规则组中的隔离规则。

为了提供访问共享存储器内的数据的更高水平的性能，可选地跳 过在开始每项事务时对从数据库的上述询问264。在这种情况下，存储 在共享存储器内的复制文件需要包括一个标记或标志，其指示新版本 150是否可用。因此，在开始每项事务时，并不系统地询问从数据库， 而是首先检查此标志。如果标志指示没有新版本150可用，则使用当前 复制文件。如果标志指示新版本150确实可用，则从从数据库读取版本 表262，以使应用处理240、240’、240’’能够切换至新的预加载复制文 件（Vn+1）。在新版本150的预加载完成时被设置的此标识，在客户 端应用已经结束处理其当前事务时被重置。在许多处理访问相同复制 文件的环境下，仅有少数在它们中的一个程序重置此标识之前不得不 询问从数据库。

为了在生产环境下工作，上述机制也必须是容错的。只有在可以 在主数据库中承诺管理事务之前，复制文件确实全部被成功预加载， 即被分布并映射到所有从结点的共享存储器内，才能够达到完全一致 性。这是强制保证从结点确实能够以原子方式切换至新复制文件。否 则，可能存在一些从结点能够切换至新版本而另一些不能的错误情况， 因而导致缺少一致性。因此，为了防止此情况发生，当因任何原因而 在任意给定从结点上分布失败时，中止全部事务并响应于更新请求而 向终端客户发送错误。由于实现了如图4所示的两阶段承诺处理的缘 故，这是可能的。在一致性与可用性之间，本发明强调一致性。重要 的是强调仍然彻底保持从从结点的读取可用性，并且能够实现接近实 时的信息查询。可用性中唯一可能被折中的部分是数据的更新/管理。 在本发明的上下文中，此部分远不如读取可用性和所有从结点上分布 的复制文件的高度一致性关键。因此，将复制文件成功地分布至每个 从结点是本发明的关键部分。如上所述的企业服务总线或服务集成器 （SI）用来保证积极参与客户端应用层的从结点组的映像总是可用的。 当从结点加入或离开组时，此映象被相应地更新，使得本发明的方法 能够被适当实施。

虽然在此说明并描述了本发明的现有优选实施方案，但是可清楚 地理解的是：本发明并不仅限于此，可能在以下权利要求的范围内以 各种方式实现。