用于处理请求的数据处理系统和方法

专利名称：用于处理请求的数据处理系统和方法
技术领域：
本发明应用于分布式数据处理环境，例如数据库系统和消息系统。 本发明具体应用于响应于来自多个请求方的请求更新高可用性数据存 储的数据处理系统中。
背景技术：
利用计算机硬件和计算机软件实现的商业应用，例如订购系统， 越来越被要求具有高可用性和可靠性。许多商业机构要求它们的数据
处理系统每天24小时运行并且从不丢失数据，并且最好的信息技术公 司已经对这些要求做出响应(在一些情况下获得大于99.99%的数据处 理系统的可用性)。商业机构通常还希望高性能(高吞吐量而又不损 失可靠性)，这就随着数据处理要求的增加而要求可升级的解决方案， 并且它们不希望高成本。
利用(存储器、处理器以及网络连接的)冗余和恢复特征(备份 以及失效转移)的组合开发了高可用性的数据处理系统来避免任何单 点故障。 一种这种方案包括高可用性数据库(HADB)，其跨越使用 冗余存储方案的高度集成的服务器集群，比如整体作为单个系统镜像 的高度可靠的IBM大型计算机集群分布。将数据共享和并行处理相结 合来实现高性能和高可用性的处理器集群有时被称为并行系统联合体 (或"parallel sysplex")。在并行系统联合体中实施的典型的HADB 可以以高性能和高可靠性处理来自大量的分布式请求方的针对数据检 索和数据更新的多个并行请求。
HADB系统可以包括将消息队列和商业逻辑及路由功能进行组合 以管理数据存取的鲁棒的、高可用性消息处理系统。这可以提供有保 证的仅一次的消息投递，并且这种系统可以用更少的延迟有效地处理故障。然而，通常在这种高可用性系统中实现的事务管理、冗余管理 以及恢复特征在正常的请求处理期间引起显著的处理开销。任何这种 处理具有潜在的商业成本，因为高可用性数据处理系统比低可靠性的
系统贵。这些附加处理的示例是要求在HADB系统中的两步提交(two phase commit)处理，或者更具体地，在HADB系统内的资源和系统 外的资源之间的两步提交处理。另外，在HADB系统中实施消息队列 通常要求记录在HADB中的消息数据。
一种替代方案是采用从HADB系统分离的并行消息调度器的集 群，例如位于每个服务器不实施综合的高可用性特征的常规应用程序 服务器集群中。与单一的消息调度器相比，并行处理可以提高吞吐量 并且减少故障的影响，而从HADB系统分离消息调度器功能可以减少 处理开销。然而，如果消息调度器在不具备高可用性特征的服务器上 运行，影响一个服务器的故障将延迟对已经发送到那个服务器的消息 的处理。尽管存在其它消息同时被其它消息调度器成功处理的可能性， 这可能还是有问题的。发送到出故障的消息调度器的消息(此处称为 "孤儿消息，，或者"孤儿请求，，)通常被延迟直至该消息调度器回到在线 状态。
一些已知的集群消息系统实现针对节点故障之后的快速恢复的多 种特征，以减少处理孤儿消息中的延迟，但这些途径没有完全解决孤 儿消息的延迟处理的问题。

发明内容
本发明的第 一方面提供一种在包括数据存储和至少 一个业务请求 方的数据处理环境中使用的管理业务请求的方法，所迷方法包括以下 步骤
将请求方的业务请求复制到多个请求处理組件中的至少两个，所 述多个请求处理组件的每一个位于请求方和数据存储之间的通信路径 上；
防止任何没有成功地声明负责该业务请求的请求处理组件处理该业务请求；
第一请求处理组件声明负责该业务请求；以及
第一请求处理组件处理它的所声明业务请求的副本，包括存取数 据存储内的数据。
在一个实施例，声明负责的步骤包括在数据存储中的库中输入所 述业务请求的标识符的步骤，并且所述方法还包括防止所述多个请求 处理组件中任何一个在所述库中输入所述业务请求的重复的标识符。
在一个实施例，防止业务请求的处理包括防止请求处理逻辑的执 行。在替代实施例中，防止处理业务请求的步骤包括防止更新数据存 储内的数据(即对请求的某些处理是可以的，包括执行某些商业逻辑 和可能从数据存储读取数据，但防止对数据更新的写入)。
在本发明的一个实施例，所述数据处理环境包括多个分布式业务 请求方，并且所述数据存储包括在高可用性数据处理系统上运行的数 据库。
在一个实施例，所述请求处理组件包括商业逻辑，以用于处理接 收的请求，以确定数据存储中要求什么数据存取操作，以及用于处理 将请求的副本从业务请求方异步传递到数据存储的请求调度功能。
本发明的第二方面提供一种数据处理系统，包括
数据存储；
多个请求处理組件，其中多个请求处理组件中的每一个位于至少 一个业务请求方和数据存储之间的通信路径内；
复制器，用于复制业务请求方的业务请求到多个请求处理组件中 的至少两个；以及
声明管理器，包括用于防止任何没有成功地声明负责所述业务 请求的请求处理组件处理该业务请求；以及用于以第一请求处理组件 的名义声明对所述业务请求负责的功能，从而使得第一处理组件能够 处理业务请求的副本。
声明负责的功能可以包括在数据存储内的库中输入业务请求的标 识符，并且声明管理器还可以包括用于防止多个请求处理组件中的任何一个在库内输入重复的业务请求标识符。
本发明的一个实施例通过提供多个请求处理组件(请求调度器和 关联的商业逻辑)，并且将请求复制到两个或者更多个请求处理组件， 并且接着管理高可用性系统内的请求的处理以确保特定请求的仅一个 副本可以更新高可用性数据存储，来减轻现存的高可用性服务器环境 中的一个或多个问题。
通过提供彼此并行工作的多个请求处理组件，并且在并行请求处 理组件上复制每个请求，能够减少延迟的孤儿请求的问题。如果一个 副本请求被明显地延迟，则其它副本请求应当继任。在高可用性系统 之外实现这些请求处理组件允许实现减轻孤儿请求的问题而不在高可 用性系统上加上很高的处理开销，而在高可用性系统内管理仅一次的 数据更新则保持数据完整性。在本发明的一个实施例中，请求消息被 入队并且消息的商业逻辑处理被在高可用性系统之外进行，而结果的
HADB更新和请求消息从队列的确定的移除在事务范围下由高可用性 系统处理。本发明的具体实施例提供HADB系统内的管理仅一次的更 新的高效的机制。
本发明与现有的并行处理不同，其中任何消息被分配到并行设置 的一组组件中的仅一个，因为在本发明中在两个或者更多个并行请求 处理组件的集合上复制请求或消息。
本发明的另 一方面提供一种消息排队系统，其使用复制来实现在 队列上插入消息的操作的可靠性和被入队的消息的相对高可用性，但 与单一的高可靠性数据库(HADB)系统通信，并且使用事务处理和 锁定机制来进行有保证的HADB的仅一次更新。在消息的处理(以及 HADB任何要求的更新)之后确定地从队列移除消息的操作是由 HADB系统内保存的数据控制的。
在现有的队列系统中，在队列中插入消息的操作(例如响应于PUT 消息命令)，消息在队列上的存储，以及检索消息的操作(例如响应 于GET消息命令)全部在相同的系统中实现，并且因此使用相同的可 靠机制。根据本发明的消息队列系统与这种现有的系统不同之处在于，其通过在队列的一端进行复制(这支持实现可靠性，尽管使用廉价的 组件)，同时在队列的另一端利用单一的高可用性系统的能力以在队 列的末端确保数据完整性和可用性。这一点当正在插入消息的应用程 序已经在依赖于廉价和相对地不可靠的组件的环境中运行时具有很大 的优点，而消息意在更新高可用性系统中的资源。
在一个实施例，每个请求的HADB更新的仅一次的处理是通过在 HADB的库中保存存储在HADB中处理的请求的请求标识符；以及通 过在任何重复的请求能够更新HADB之前检查请求标识符的库实现 的。请求标识符的库中的条目可以在请求被处理时被锁定(利用现有 的HADB锁定功能)，这一处理的提交在高可用性系统中管理。随后 对请求标识符的识別确保该请求的全部副本的删除。锁定请求标识符 的库中的条目，并且避免重复条目，确保同一请求的多个副本不能多 次更新HADB。
在本发明的一个实施例中，请求标识符的库是数据库表格，其中 表格的行对应于请求。此表格以后称为"声明表格，，。第一请求处理 组件在声明表格中插入请求标识符并获得对该声明表格行的锁定，并 且获得对HADB中保存相关数据项的那部分的另一锁定。通过现有的 HADB机制实现并且维护锁定，直至特定请求的处理完成，此时此请 求要求的任何HADB更新被提交并且请求的任何副本被删除。
本发明的一个实施例实现仅一次的消息处理而不浪费HADB事 务，通过允许单一的HADB事务包含一个或更多个在声明表格中插入 请求标识符失败的尝试，以及包含最终的成功插入请求标识符和由消 息调度器和商业逻辑执行的相应请求处理(包括在"写入"请求的情 况下的HADB更新)。
本发明的另 一实施例提供一种计算机程序，包括用于控制数据处 理装置以执行如上所述的方法的一组指令。计算机程序可以作为记录 在记录介质上包括程序代码的计算机程序产品而可用，或者可以是可 用于经由例如经由英特网下载的数据传递介质而传递。


下面以示例的方式参照附图更详细地描述本发明的实施例，其中 图i是其中单一的消息系统处理请求消息并且向例如本领域已知
的数据库发送更新指令的数据处理系统的示意性表示；
图2是根据本发明的实施例的分布式数据处理系统的示意性表示； 图3提供根据本发明的另 一 个实施例的分布式数据处理系统的示
意性表示；
图4是根据本发明的实施例的更新声明表格的请求调度器的示意 性表示；
图5是尝试更新声明表格并且被拒绝的请求调度器的示意性表示； 图6是根据本发明的实施例的方法的示意流程图； 图7示出根据本发明的实施例的方法的 一 系列步骤，其中请求消息 孚皮成功地处理；
图8示出其中重复消息不被允许更新数据库的方法的一系列步骤；
以及
图9代表针对各种代替方式处理业务请求的相对的处理开销。
具体实施例方式
本发明在高可用性数据处理环境中具有特别优点，其中需要能够 以最小的延迟和最小的故障影响存取数据存储以及对数据存储进行更 新。
如本领域已知的，高可用性可以以多种途径实现。第一种已知的 方案采用复杂的硬件，包括多个冗余部件，以及专用的附加附件以安 排冗余部件之间的失效转移。这些冗余部件可以包括处理器、存储器、 控制器、硬盘驱动器以及通信总线。这些复杂的硬件被适当的计算机 软件补充。这种高可用性系统的示例是运行IBM的DB2数据库系统软 件和IBM的z/OS操作系统的IBM zSeries数据处理系统。IBM、 zSeries、 z/OS以及DB2是国际商业机器公司的商标。
第二个已知的方案提供多个简单的系统，每一个系统容易发生故障但相对地廉价，具有相对简单的软件机制以在之间共享工作和避免 出故障的系统。运行在这种系统上的软件的每一个实例典型地比高可 用性系统的弹性差，依赖其数量多来确保总是存在在任意一个时间工 作的能胜任的系统。该第二方案一般地用于高容量处理和无状态逻辑， 但由于当存在多个拷贝时决定哪一个是最后的数据实例的问题，很难 用于状态信息。
再次参照上述的第一已知方案，图l是分布式数据处理系统的示意
性表示，其中高可用性数据存储(HADB) 10与包括队列80、用于调 度执行商业逻辑30所导致的数据存取操作的消息调度器20的消息系统 相关联。商业逻辑30负责确定HADB需要哪些更新，并且然后与HADB 协作来管理该更新并协调该更新和从队列移除消息。通过示例，图l 示出了数据存储10分布在三个或者更多个服务器12、 14、 16上，其每 一个具有它们自己的数据处理和数据存储能力。多个请求方40、 50、 60经由消息调度器20提交对数据存取的请求。
为了实现系统作为一个整体的高可用性，消息系统20以及其商业 逻辑30可以集成在保存HADB的高可用性服务器内。如上所述，HADB 可以是来自IBM公司的DB2数据库并且所述服务器可以是运行z/OS操 作系统的IBMzSeries计算机系统，其包括冗余处理器和存储器以及失 效转移恢复特征，以提供最大的可靠性和可用性。尽管这种可靠性和 可用性是所期望的，并且对于一些应用而言是关键要求，但是消息调 度器和商业逻辑对高可用性服务器施加了不希望的处理开销。例如，
对HADB的仅一次的更新的确保通常涉及二次提交处理以防止HADB 更新和相应请求消息的最终删除之间的故障。具体地，由请求方40、 50、 60插入消息到队列中可以要求消息存储和请求方使用的其它资源 之间的协调。这一协调为高可用性消息存储造成很大的开销。本发明 减轻了这一问题。
代替地，消息调度器和商业逻辑功能可以于在不具备高可靠性特 征的硬件上运行的标准应用服务器上实现。这种应用服务器在本领域 中是已知的，并且例如来自IBM公司的Websphere应用服务器的产品可以运行在不为高可用性提供综合支持的相对廉价的计算机系统上。
Websphere是国际商业机器7>司的商标。
混合上述不同的处理风格也是已知的。在低成本复制的硬件上运 行一些数据处理系统，但对于长期数据存储则存取鲁棒的高可用性的 数据库(HADB)。至少在正常转发处理期间，从HADB系统分离商 业逻辑和消息调度器功能的方式对于运行HADB的高可用性服务器具 有较低的影响。然而，在标准应用服务器和低成本硬件上运行商业逻 辑和消息调度器增加延迟"孤儿请求，，的风险。即，发送到出故障的应 用服务器的请求被延迟，直至该应用服务器回到在线状态。
本发明减轻这一问题。在第一实施例，如以下详细描述的，多个 分布式业务请求方可以向请求处理系统输入业务请求。请求处理系统 包括与高可用性数据存储通信的多个廉价的请求处理组件。服务器请
求被复制到多个请求处理组件中的至少两个。任何没有成功地声明负 责所述业务请求的请求处理组件被阻止处理所述业务请求，以避免重 复更新数据存储。第一请求处理组件声明负责所述业务请求，并且然 后处理其被声明的业务请求的副本，包括存取数据存储内的数据。全 部多个请求处理组件被阻止输入对所述业务请求的重复声明，并且这 个对业务请求的有保证的仅一次的声明防止对重复更新数据存储。
图2示 出根据本发明的实施例的分布式数据处理系统。如图l所示， 多个分布式并行请求方40、 50、 60在请求业务，业务的商业逻辑要求 从HADB存取数据。然而，在图2的方案中，请求在多个相关队列80、 82、 84、 86中的两个或者更多个上被复制，所述队列80、 82、 84、 86 与并行设置的多个消息调度器20、 22、 24、 26相关联。当图l的请求方 将消息放入一个消息调度器20的输入队列中，在图2中，消息被入队以 经由复制器70分配。复制器70满足向N个并行消息调度器的集合中选 择出的子集k复制消息的有限角色，其中Kk-N。在特定实现中，k为2; 在另一实现中，k为3。
如图2所示，复制器70可以是接收部件，请求方40、 50、 60向其发 送全部请求。在另一实施例中(以下参照图3描述)，复制器功能可以在请求方的系统处实现或者在网络中其它位置的中间代理服务器处实 现。
根据图2所示的实施例，复制器70对请求的分配是k路扇出分配， 在至少两个消息队列(80、 84)中设置每个消息；但请参见以下对于 例外的描述。在所示的实施例中，我们使每个消息调度器与单个队列 相关联，例如，消息调度器20与队列80相关联。替代的实施例允许队 列和消息调度器之间更复杂的关联。由复制器对特定k个队列的选择可 以简单到是从集合N内的循环分配，但可以实施利用负载平衡技术的 其它选择。
在本发明的一个实施例中，数字k (以及对特定k个队列的选择) 是在每个消息的基础上确定的，对相对高价值和紧急的消息选择较高 的k值，而对低价值的消息选择较低的k值。特定的实施例为消息的复 制提供例外，允许为可识别的低价值或非紧急的消息选择单个消息调 度器(k-l)。由此将按照现有技术处理这些消息，而将不受益于本发 明，但不会防止本发明应用于其它消息。
简略地参照图3，与图2的差别是分布式复制功能的不同实施方式。 每个请求方利用各自复制器70、 71、 72的业务，该业务可以对于各个 请求方40、 50、 60是本地的并且是专用的，或者可以位于分布式网络 内的一些中间位置处。对于每个复制器，可以动态地确定或可以如图3 所暗示的那样预定义副本请求所要发送到的队列的数量k和具体k个队 列的具体集合的选择。
在图2和图3的实施例中，消息调度器(20、 22、 24、 26)每个实 现可以对HADB IO进行更新的请求调度器功能和商业逻辑(30、 32、 34、 36)。在第一实施例中，HADB被消息调度器视为单个系统，并 且为了效率或可用性任何HADB的内部分割对请求方和消息调度器不 可见。在这种系统中，消息调度器负责从其输入队列检索消息，并且 调用商业逻辑，并且负责请求在声明表格中插入条目，但是在HADB 中的路由不是消息调度器的责任。如上所述和以下更详细地描述的，
"声明表格，，是业务请求标识符库，识别请求处理组件已经声明负责的那些业务请求。HADB结构对于外部请求方不可见并且HADB内部特 征负责识别所要求的HADB片段的方案在本领域中是已知的。商业逻 辑通常是应用专用的，例如处理对货物或者业务的订单，并且产生特 定的更新指令以施加到HADB以反映该定购。由于对多于一个调度器 复制消息，如下所述，不要求消息调度器(20、 22、 24、 26)和它们 的输入队列(80、 82、 84、 86)实现高可用性特征。
HADB IO除了HADB商业数据卯之外还包括声明表格IOO。声明表 格100是数据库表格，其具有单一关键列以包含请求标识符(比如消息 标识符或者其它请求标识符)。对任何特定的请求标识符，仅一个消 息调度器被允许将条目插入声明表格。声明管理器110与声明表格100 相关联，并且负责在声明表格可以被更新之前检查它。在本发明的当 前实施例中，复制器70、消息调度器20、商业逻辑30以及声明管理器 IIO的功能以软件实现，尽管它们的逻辑操作可以在硬件中实现，比如 利用电子电路。
声明表格可以还包括附加信息，例如对业务请求的责任成功声明 的时间，以及声明者的身份。这对于本发明的操作不是关键的，但可 以提供关于系统行为的有价值的诊断和统计信息。
在实际中，声明管理器的操作很可能在消息调度器的分布式处理
器中执行的声明管理器专用代码、以及HADB内运行的通用数据库锁 定代码之间被分割。这在以下更详细地示出。
在一个实施例中，消息调度器功能和商业逻辑在消息驱动组件 (Message-Driven Bean )内实现，消息驱动组件是实现Java消息业务 (Java Messaging Service, JMS )的企业Java组件(Enterprise Java Beans, EJB )，允许J2EE应用异步地处理JMS消息。在本实施例， 运行消息调度器的应用服务器是从许多分布式请求方(J2EE应用客户 端或其它JMS应用或者系统)接收JMS消息的J2EE应用服务器。单个 消息驱动组件可以处理来自多个客户端的消息。声明管理器110的逻辑 可以实现为调用消息驱动组件的方法的EJB容器(container)的功能。 当消息到达时，容器首先调用声明管理器逻辑110以确保消息不是已经被处理的消息的副本。容器接着调用消息驱动组件的方法，该方法识
别具体的JMS消息类型并且根据应用专用的商业逻辑处理消息(如在 标准J2EE方案中那样)。这种应用专用的商业逻辑处理消息内的信息 以产生特定的数据库更新指令，该数据库更新指令然后被发送到 HADB。 Java和基于Java的商标是Sun Microsystem, Inc.的商标。
在替代实施例中，消息的调度是通过进行消息GET操作的常规消 息程序实现的。在此情况下，声明管理器110变为消息系统的一部分， 并且声明表格100是对消息存储的HADB延伸，而消息存储的其余部分 可以利用不同的技术实现。
潜在的大量的请求方40、 50、 60中的任何一个可以通过经由复制 器70发送请求消息来请求业务。每个消息被复制并入队到可用队列80、 84的子集合k。相关联的k个消息调度器(20、 24)中任一个对副本消 息可以进行以下操作。操作参照图4、 5、 6、 7和8描述。在请求消息被 一个消息调度器接收时，在210开始HADB事务，并且然后当前的消息 调度器24从其输入队列84检索220第一消息。这些步骤在图6、 7和8中 示出。在同一HADB事务中发生对HADB的商业数据和声明表格的更 新(以下描述)，以确保声明表格和商业数据被成功地更新，或者如 果更新不成功，两者被收回。
消息调度器24尝试230在HADB IO的声明表格100中插入对这个消 息的声明130，具体地说，尝试插入唯一的请求标识符作为声明表格中 新的一行。在插入声明之前，对请求标识符进行扫描240 (对应于扫描 声明表格所有行的逻辑扫描，但是对声明表格的索引进行扫描以避免 需要对表格的完全物理扫描)。该扫描识别任何匹配的请求标识符。 如图5、 6和8所示，如果另一消息调度器被确定250已经在声明表格中 输入了这个请求标识符，尝试的声明此时不继续下去；而如果在请求 表中没有匹配的条目则声明继续下去，如图4、 6和7所示。当在声明表 格IOO中成功输入260声明时，HADB锁定270声明表格的这一行以防止 被其它消息调度器20、 22、 26改变。
一份检索的消息的拷贝保留在消息调度器的输入队列84中，但消息状态被更新声明表格的动作隐含地改变，从"接收"状态(即消息在 队列中可用，并且对检索就绪)改变为"检索但被怀疑"状态(即消息 已经被从队列中检索以进行处理，但消息的处理还没有提交)。
参照图4、 6和7，第一消息调度器24 (来自k个调度器的集合)尝 试向声明表格100插入新的请求标识符是成功的。声明表格通过插入 260包含请求标识符的新的行130而被扩展，并且该第一调度器利用标 准HADB锁定机构实现270锁定声明表格的该行。具体地，HADB响应 于来自声明管理器110的请求实施对声明表格的锁定，维护哪个消息调 度器24与锁定行相关联的记录。行锁定防止在处理第一消息调度器的 消息时其它消息调度器20、 22、 26进行的修改(即，直至提交或者退 出HADB事务和消息事务，如以下更详细描述的)。
仅当表格当前不包含针对特别请求的标识符的条目时，才允许声 明管理器110对声明表格进行新输入，因此不可能有重复的表格条目。 如果声明管理器110在声明表格中发现240、 250具有匹配的请求标识符 的条目，如图5、 6和8所示，则第一消息调度器24获得的声明条目防止 以其它请求调度器名义作出的更改。
如果发现290将要以第 一 消息调度器24的名义锁定匹配的声明表 格行130，则不同消息调度器的在声明表格中插入重复条目的请求被保 存在存储器中，以等待300解锁保存该匹配条目的声明表格行。根据对 应的HADB事务和消息事务的结果，第一消息调度器的声明表格条目 130可以在被解锁之前被删除或者提交，因此不可能在此阶段预测是否 随后尝试更新声明表格将成功还是失败。这就是为什么重复的声明请 求可以被保存在存储器中以支持重试。
当在存储器中保存更新声明表格的请求的同时，在消息调度器20 的输入队列中的消息的拷贝现在具有隐含的状态"检索但被怀疑"。 HADB没有开始处理该副本请求的数据更新，但相同请求的另 一副本 正被处理，并且因此对当前副本的声明请求被保存在存储器中以等待 处理的结果。由此，被尝试HADB更新的消息的全部副本现在具有相 同的隐含状态"检索但被怀疑"，而它们在它们各自的消息调度器的输入队列80、 82、 84、 86上仍旧未被提交。不需要消息调度器20、 22、 24、 26写入任何明确的状态信息，因为从声明表格100中容易确定隐含 状态；如果尝试检索并且处理副本消息，则易于确定状态，并且直至 尝试检索和更新之前状态是不重要。
代替地，如果匹配声明表格行已经被提交并且被解锁，则在声明 表格中插入重复条目的任何随后尝试必须失败。在此情况下，故障报 告被返回310到尝试在声明表格中插入重复条目的消息调度器，并且消 息调度器从其输入队列删除320对应的消息。
在声明表格中获得针对行的锁定，而不是对整个表格或者包含相 关声明表格条目的页面的较低粒度锁定，因为复制请求使得有可能将
经常有沖突的更新声明表格的尝试。更高粒度的行锁定与较低粒度的 页面锁定相比将减少必须保存的请求的数量，避免如果实施页面锁定 而将发生的不同消息之间的冲突。尽管在声明表格级别有经常发生冲 突的可能性，比起如果全部的消息调度器功能和商业逻辑都实现在高 可用性系统内，声明请求的处理几乎不要求在高可用性系统内处理， 并且特别是能够涉及更少的性能成本。
本发明的 一个实施例还通过在复制器70产生的副本的时序中引入 轻微的"交错"，减少相同消息的多个副本之间的冲突。通常，当全部 消息调度器以相同速率运行时，在尝试计划第二个副本之前，第一个 释放的副本将被完全处理。在第一调度器暂时不工作的情况下，第二 副本仍将以及时方式被处理。将存在同时尝试处理两个副本的情况， 但这种情况的数量将被减少。
如上所述，防止冲突的更新可以包括HADB响应于识别240、 250 匹配的声明表格条目而暂时存储对更新声明表格的新请求(即，声明 请求可以保存在存储器的队列中)。声明请求等待300当前正被处理的 业务请求的结果(或者如果这发生的更早则超时350)，并且然后决定 是接受还是拒绝该新的声明请求。保存在存储器中的声明请求仍将被 保留，直至从声明管理器接收到"解锁，，的信号或者直到超时为止，无 论哪个先发生。超时之后可以是重复尝试从而以超时消息调度器的名义更新声明表格，例如在预定的延迟期之后。"解锁"的信号提出重复
扫描240声明表格l 00以识别250任何该声明请求的任何匹配的请求标识符。
当声明表格更新成功260时，获得270对声明表格的相关行的锁定 和对HADB的相关部分的锁定(例如，锁定特定服务器上的数据库行 或者页面140)，如图4中示意性地示出的，其中HADB管理器120获得 页面锁定。两个锁定都利用HADB中可用的标准机制实现。声明表格 100的成功更新是数据库120更新HADB内的商业数据90的前提，并且 仅一个消息调度器24能够为每个请求更新声明表格。商业数据卯的更 新仅能够出现在HADB内没有冲突的锁定时。这确保对每个复制的请 求仅一次地更新HADB商业数据，不管更新请求的k路复制和每个队列 数据如何，消息调度器和商业逻辑在HADB的高可用性系统之外实现。
如上所述，HADB的相关部分的识别可以在HADB本身内实现或 作为消息调度器的功能实现，在每种情况下都利用常规的数据存取机 制。对HADB被锁定部分140的写入存取现在为与当前消息调度器24相 关联的商业逻辑34预留(在一些实现中锁定也预留排他读取存取)。 消息调度器24内的商业逻辑34被执行以处理350该请求并且确定对 HADB的任何所要求的更新。所确定的更新然后被应用360到HADB商 业数据卯。
例如，商业逻辑可以处理规定货物或者业务的订单的消息，更新 订单的数据库。另一实例请求可以是检索关于现有订单的状态信息的 请求，或许检查产品的制备或者投递的进度。许多其它商业应用可以
利用本发明实现。
如果对请求的处理350、 360成功370，则对HADB (包括声明表格 条目和商业数据更新)的全部更改被提交380。然后向消息调度器系统 确认HADB事务的提交，消息调度系统然后删除320被处理的消息。
尽管由一个成功的消息调度器提交了消息事务，但消息的副本可 以在k个消息调度器20、 22、 26中其他消息调度器的输入队列80、 82、 86中保留一段时间。消息的每个其余副本现在具有被提交的隐含状态，并且仅是等待从各自队列被删除。
当已经提交了390对请求的处理时，在成功处理350、360请求之后， 将拒绝相同请求的其它副本的在声明表格中插入声明的任何新尝试。 在此情况下，请求消息的唯一请求标识符和声明表格中的请求标识符 的集合之间的比较将识别出匹配，并且匹配的请求现在具有解锁声明 表格条目所反映的"提交"状态。这个状态足以确认现在应该将消息从 未成功尝试向声明表格添加重复的条目的各个消息调度器20的输入队 列80删除。
消息的其它副本也应该被删除，尽管对提交的请求消息的确定的 删除指令不要求瞬时删除全部副本。提交的HADB更新作为指示提交 消息检索(即从全部消息调度器的输入队列删除消息)的确定指令是 有效的，但是特定输入队列的实际删除可以被推迟到相应的消息调度 器尝试在声明表格中输入声明。
以上描述的在第一消息处理正在进行时(未提交)将重复的声明 请求存储到存储器，并且如果第一消息处理是成功的则拒绝重复的声 明请求并删除相应的副本消息的步骤产生相对较小的处理开销，尤其 是最小化高可用性系统和HADB中的开销大的处理。
胜出副本的成功处理和删除不包括在HADB和消息存储之间的开 销大的二阶段提交操作。如果消息调度器对胜出副本消息在提交操作 380和删除消息操作320之间应失败，则声明机制将以与防止执行失败 副本的方式完全相同的方式防止重新执行胜出副本消息。将理解的是 用于防止重新执行单个实例消息的机制在本领域中是已知的(有时称 为"1.5阶段"提交)。
如上所述，即使在使用本发明的系统中，复制器70也可以选择不 对一些低价值的消息利用本发明。可以是这些消息被复制器标记为非 重复的，并且以特殊方式处理。在其它实施例中，利用上述声明机制 处理低价值和非紧急的请求消息以获得1.5阶段提交的优点。
在替代实施例中，对声明表格中被锁定的匹配行的识别可以触发 通过明确拒绝声明请求来回复相应的消息调度器(而不是上述将声明请求存储到存储器)。这可以在数据库使用"假定提交"锁定策略时发 生。这一 明确拒绝将把副本消息留在相应的消息调度器的队列上直至 随后重新尝试更新声明表格，并且有可能引起比其中对更新声明表格 中被锁定的行的请求暂时地存储到存储器的实施例更多的处理。
在上述任意实施例中，在请求消息的第一副本的处理还在进行时 (即处理还没有完成并且仍可能失败)，对更新声明表格的尝试可能 被拒绝。因此，保存对应于被拒绝的声明请求的请求消息的消息调度 器能够随后重试更新声明表格，除非消息调度器已经接收了删除该请 求的隐含指令(即响应于确定匹配声明表格条目被解锁的声明表格更 新故障报告，因为这暗示着消息处理成功完成并且被提交)。这种随 后的重试将在预定的延迟时段之后进行，或者重试的频率可以取决于 当前系统活动。
如果在消息处理期间出现故障，则HADB事务必须退出400、 410。 在此情形下，声明表格条目被删除并且声明表格行被解锁410。根据故 障的性质，消息调度器可以采取各种动作，包括[a将副本消息留在输 入队列中以用于稍后重新尝试处理，[b将副本消息移动到死信队列， 或[c]删除该副本消息并且向原始请求方发送故障通知。替代地，可以 是消息调度器自身出故障，在此情况下系统将隐含地退出HADB事务 (包括移除存疑的声明表格条目)并且副本消息将为了随后的重试而 保留在输入队列中。这些故障处理的实例在本领域是已知的。
在本发明的一个实施例中实现具体的优化以减少HADB处理开 销。当开始新HADB事务开始，但因为特定请求的副本已经被处理， 所以声明表格更新不成功时，新的HADB事务不被终止。代替地，从 第一HADB事务中的具体消息调度器的输入队列检索下一个请求消 息。这在图8中示出。消息调度器接着尝试为了该下一个请求消息添加 声明表格条目(在表格中输入请求标识符)，并且由于上述原因之一 或者成功或者失败。以此方式，在HADB的仅一次更新的实现中涉及 的事务处理机制被优化以减少处理开销(与为了每次尝试向声明表格 添加条目而需要开始和结束事务的方案相比)。图9中的表1代表处理需要对HADB内的数据进行存取的业务请求 的多个替代方式的一些处理开销(事务的数量和涉及哪些资源)。完 全在高可用性系统内实现的、队列和商业逻辑和HADB都在一个系统 中实现的方案包括高可用性系统内的两种事务。消息插入事务包括记 录消息的数据，并且可以与其它高可用性系统资源协调。两种事务均 涉及高可用性系统资源的大量开销。在表l的左侧以方案(A)示出。
在高可用性系统之外实现队列和商业逻辑的方案(B)避免高可 用性系统内的任何队列管理活动。然而，通常的方法将不提供期望的 对仅一次消息处理的保证，例如原因是上述的延迟的孤儿消息问题。 另外，消息处理事务有可能涉及HADB资源和外部排队系统之间的协 调，这比内部协调事务更昂贵。这个方案(B)在表l的中间列中示出。
本发明的实施例在表l的右侧表示为方案(C)。有可能总体上涉 及更多的操作，并且因此是不直观的，但是大多数这些操作不影响高 可用性系统。仅一个事务是在高可用性系统中必需的，并且这个事务 与同一HADB中保存的其它数据协调，并且利用相同的声明管理器110 和HADB管理器120。另外，由于队列中潜在的大量数据未在高可用性 系统中存储，这将节省高可用性系统中的记录。
在上迷实施例中，消息调度器和相关联的商业逻辑不知道HADB 内的数据的组织结构。在替代实施例中，或者消息调度器或者关联的 商业逻辑被实现为知道HADB片段和结构，并且包括路由/选择逻辑以 确保对适当的HADB片段的最充足的路径。这些路由和选择逻辑是在 本领域已知的。在这一实施例中，声明管理器可以为了应用数据片段 和声明表格片段之间的更密切的关系而分割声明表格。
在本发明的另 一示例中，每个消息调度器批处理消息以更有效地 进行消息处理。该批处理增加两个或者更多消息处理部件尝试在声明 表格中输入沖突的声明的可能性，但是冲突的声明尝试的处理的处理 成本相对较低。具体地，冲突的声明尝试对HADB的影响很小。消息 调度器根据本实施例进行的操作表示如下
对消息批次的循环开始消息事务 [消息的循环J
开始HADB事务 循环直至声明成功 获得消息
尝试在HADB声明表格中插入声明 如果声明尝试失败，循环以尝试声明下一个消息
如果声明成功则继续
执行商业逻辑，更新HADB
提交HADB 提交消息
循环到下一个消息批次
以上描述的实施例包括一种机制，凭借该机制，响应于尝试在声 明表格中插入条目的失败，在正常处理期间删除重复的业务请求消息。 这一机制可以被进一步的机制加强。例如，成功的消息调度器可以向 其它消息调度器通知其成功，而其它消息调度器可以接着删除其消息 的副本。另外，可以提供用于清除声明表格的机制，这必须伴随着从 消息调度器的输入队列清除被成功处理的消息的关联副本。
许多消息不要求一次且仅一次的处理。例如，请求简单的只读数 据库查询的消息能够重复而不牺牲数据完整性。本发明緩解涉及确保 消息的一次且仅一次执行的成本的问题，但即使对这种优化的一次且 仅一次的处理，仍然优选地避免该需求。如本领域已知的，用于避免 不必要的仅一次的处理的方法包括在消息中明确地标记要求的服务 质量，以及使用这样的假设比如非持续性消息不需要引起一次且仅 一次处理的开销。 一些系统包括明确的支持，例如IBM公司的 WebSphere MQ产品，其中 一个消息得到的选项是"如果是持续的则采 用同步点"。以上描述了本发明的各个实施例以提供对本发明如何能够在不同 实施例中实现的详细说明，并且强调本发明的具体实施例的一些优点。 然而，本发明不限于以上描述的具体示范性实施例，并且本领域技术 人员将意识到落入如所附的权利要求限定的本发明的范围的各种修 改。
权利要求
1. 一种在包括数据存储和至少一个业务请求方的数据处理环境中使用的管理业务请求的方法，所述方法包括以下步骤将请求方的业务请求复制到多个请求处理组件中的至少两个，所述多个请求处理组件的每一个位于请求方和数据存储之间的通信路径上；防止任何没有成功地声明负责该业务请求的请求处理组件处理该业务请求；第一请求处理组件声明负责该业务请求；以及第一请求处理组件处理它的所声明业务请求的副本，包括存取数据存储内的数据。
2. 根据权利要求l所述的方法，其中声明负责的步骤包括在数据 存储中的库中输入所述业务请求的标识符的步骤，并且其中所述方法 还包括防止所述多个请求处理组件中任何一个在所述库中输入所述业 务请求的重复的标识符。
3, 根据权利要求1或2所述的方法，其中所述数据处理环境包括多 个分布式业务请求方，并且所述数据存储包括在高可用性数据处理系 统上运行的数据库。
4.根据权利要求1至3中任何一项所述的方法，其中所述请求处理进行更新，并且其中防止:何请求处理;且件处i所述业务请求的步骤包括防止执行相应的请求处理组件的商业逻辑的步骤。
5.根据权利要求1至3中任何一项所述的方法，其中业务请求的完 整处理要求更新所述数据存储内的数据，并且其中防止处理业务请求的步骤包括通过防止更新数据存储内的数据来防止完整的处理。
6. 根据权利要求5所述的方法，其中所述防止处理业务请求的步 处理。
7. 根据权利要求2所述的方法，其中所述请求处理组件是消息系 统，并且其中复制的业务请求是在至少两个消息系统的输入队列中排 队的消息，并且其中输入标识符的步骤是响应于从第一消息系统的输 入队列成功检索消息而以第一消息系统的名义进行的。
8.根据权利要求2所述的方法，其中所述请求处理组件是消息系 统，并且其中复制的业务请求是在至少两个消息系统的输入队列中排 队的消息，并且其中防止多个请求处理组件中的任何一个输入重复的 标识符的步骤包括防止消息检索操作检索关于先前声明的业务请求的 任何消息。
9.根据权利要求2所述的方法，其中输入标识符的步骤包括锁定 所述标识符直至处理副本业务请求的步骤结束的步骤，并且其中防止 任何请求处理组件在所述库中输入重复的标识符的步骤包括检查所述锁定并且推迟或者拒绝对输入标识符的尝试直至锁定被释放。
10.根据权利要求9所述的方法，其中所述库内的未锁定的标识符 的识别是被认为是对所标识的业务请求已经被成功地处理的确认，并 且任何尝试在所述库中输入重复的标识符的请求处理组件通过删除相 应的请求处理组件的业务请求的副本而响应于未锁定的标识符。
11.根据以上任何一项权利要求所述的方法，其中所述库是数据 库表格，其中每个表格行包括与负责所标识的业务请求的声明相对应的单一的业务请求标识符。
12. 根据权利要求ll所述的方法，其中所述数据存储是包括所述 数据库表格的数据库，并且其中成功处理被声明的业务请求副本的效 果是对数据存储的更新，并且其中成功处理包括处理请求和更新所述 数据存储的步骤的单一阶段提交。
13. 根据以上任何一项权利要求所述的方法，其中复制请求方的 业务请求包括在时间上分离所述业务请求的副本。
14. 一种数据处理系统，包括 数据存储；多个请求处理组件，其中多个请求处理组件中的每一个位于至少 一个业务请求方和数据存储之间的通信路径内；复制器，用于复制业务请求方的业务请求到多个请求处理组件中 的至少两个；以及声明管理器，包括用于防止任何没有成功地声明负责所述业务 请求的请求处理组件处理该请求;以及用于以第一请求处理组件的名义声明对所述业务请求负责的功能。
15. 根据权利要求14所述的数据处理装置，其中声明负责的功能 包括在数据存储的库内插入所述业务请求的标识符，并且其中声明管 理器还包括用于防止多个请求处理组件中的任何一个在所述库内输入 重复的业务请求标识符。
16. —组计算机程序组件，每一个包括以计算机程序代码实现的 用于控制包括数据存储和至少一个业务请求方的数据处理环境中的操 作的一组命令，所述操作组合以提供用于管理业务请求的、包括以下 步骤的方法将请求方的业务请求复制到多个请求处理组件中的至少两个，所 述多个请求处理组件中的每一个位于请求方和数据存储之间的通信路径上；防止任何没有成功地声明负责该业务请求的请求处理组件处理该 请求；第一请求处理组件声明负责该业务请求；以及 第一请求处理组件处理它的所声明业务请求的副本，包括存取数 据存储内的数据。
17. —种在包括数据存储的数据处理环境中使用的管理业务请求 的方法，所述方法包括以下步骤在数据存储事务之外的多个消息处理组件的各自的输入队列上排 队业务请求的多个副本；在数据存储事务内，第一消息处理组件检索所述业务请求的第一 副本并且处理所述业务请求的第一副本，包括存取数据存储内的数据； 同时防止与第 一消息处理组件不同的所述多个消息请求组件中的任何 一个处理相同业务请求的其它副本，除非第一消息处理组件出现失败。
18. 根据权利要求17所述的方法，还包括响应于第一消息处理组 件成功地处理所述业务请求，进行数据存储事务的单一阶段提交，并 且响应于对提交的数据存储事务的识别，删除所述业务请求的副本。
全文摘要
本发明提供管理业务请求的方法、装置以及计算机程序。本发明减轻包括在高可用性数据处理系统上运行的数据存储的数据处理环境内的问题。多个分布式业务请求方输入业务请求，并且将业务请求复制到位于请求方和数据存储之间的通信路径内的多个请求处理组件中的至少两个。所述方法包括防止任何没有成功地声明业务请求的请求处理组件处理业务请求；第一请求处理组件声明负责业务请求；以及第一请求处理组件处理它的声明的业务请求的副本，包括存取数据存储内的数据。所述方法还包括防止多个请求处理组件中的任何一个输入对业务请求的负责的重复声明。在一个实施例中，请求处理组件包括商业逻辑，以用于处理接收的请求以确定数据存储内要求什么数据存取操作，以及请求调度器功能，用于处理请求的副本从业务请求方到数据存储的异步投递。
文档编号G06F11/20GK101512527SQ200780033678
公开日2009年8月19日 申请日期2007年9月13日 优先权日2006年10月5日
发明者S·J·托德 申请人:国际商业机器公司