CN102016842B - 与海量处理指令的实时处置和处理相关的改进 - Google Patents

Abstract

一种在处理时段期间实时处理和处置超大量处理指令的系统(150)，其中每个处理指令指定涉及两个不同实体(14，16)的资源帐户数据文件(30)以及在这些文件(30)之间待要交换的资源的数量和类型。该系统包括：预加载器(152)，用于获取关于指令的参考数据，所述参考数据指示每个指定资源帐户数据文件的当前值，以及所述预加载器被设置为从主数据库并行读取针对多个接收的指令的参考数据；加料指令队列(166)，用于将多个处理指令与它们各自预加载的参考数据一起排队；执行引擎(154)，被设置为使用所接收的参考数据依序确定每个接收的指令是否在相关资源帐户文件的当前值下是可执行的，并被设置为针对每个可执行指令生成更新命令；更新器(158)，响应于来自执行引擎(154)的更新命令，利用每个可执行指令的结果来更新主数据库(24)，将多个更新器的操作从执行引擎的操作退耦。

Description

与海量处理指令的实时处置和处理相关的改进

技术领域

本发明涉及与海量(massive numbers)处理指令的实时处置(handling)和处理相关的改进。本发明更具体而非排他地涉及一种计算机处理机构(architecture)，其被具体设计为对每秒成百条指令的处理进行优化。

背景技术

已有多种方法来应对海量处理指令的实时处置和处理的问题。所有这些方法已在处置大量此类指令方面取得成功，而大部分这样的成功依赖于这种采用更快和更强大的计算的系统。然而，构成这种方法的基础的机构无论怎样都有其局限性，其已对这种系统的最大可能吞吐量造成封顶(cap)。

这种技术有多个应用领域，例如海量数据通信系统和数据处理系统。这种数据处理系统之一(其表示为该如何使用这种技术的非限制性而是示例性的实例)为交易结算系统(transaction settlement system)，其中可执行用于表示在不同参与方(party)之间的协定(agreement)的数据指令消息以实行实际结算或实行该协定的执行。在这种安排中(以下详细描述其实例)，对于发给可信结算实体的计算机的指令(或命令)而言，仅当由结算实体计算机确定的条件(规则)允许执行这些指令时才能进行动作。因此，作为处理的第一部分，需要对有关资源(resources)的电子数据帐户文件的当前状态作出核对，这是结算协定的主体(subject)。这些核对确定执行针对电子数据帐户文件的指令的效果是否可接受。

在处理的第二部分中，指令或者是：被批准执行，称为“提交(commit)”；或者是被拒绝执行，称为“回退(rollback)”。更具体地，在此非限制性实例中，由结算实体计算机来估计双方资源帐户文件的位置，以确定该指令是否可执行而不会导致针对电子数据帐户文件的不可接受的位置。如果条件合适，则执行包含于数据记录内的指令(命令)，并随后更新(提交)存储有资源帐户的当前位置的数据文件。如果条件不合适，则电子数据帐户文件保持不变，而在此时并不及时进行指令的执行。如果第一阶段指出针对电子数据帐户文件的获得位置将不可接受，还能缺省地更新所有帐户和撤销更新(回退)。对于高吞吐量系统，这是优选的选择。一旦针对失败的命令的条件已经改变，则经回退的数据指令可以再次循环，并且相关的命令在后续阶段被再次尝试。所有这些通常也需要实时地报告给多个协定方的计算机。

过去，限制了所提出方案的可扩展性(scalability)的这种数据处理的执行的一个特征是：不同资源(需要访问此不同资源以执行这些指令)的数目往往不是随着指令数目增加而增加。这是因为随着指令数目增加，通常针对一定数目的资源的指令执行会有集中。这种集中带来一个问题，因为每条指令(其对资源帐户文件的值有影响)需要在指定该帐户的下一指令能被处理之前更新这个值。典型地，这通过处在处理中的对给定帐户文件实施临时排他性(锁住)的特定指令来实现，或通过核对和随后更新该资源帐户文件的值的特定指令来实现。这种在下一指令能被处理之前需要的更新对可处理这些数目增加的指令的最大速度具有直接影响。如果实体资源对很多不同类型的指令而言是共同的，则对该实体资源而言这是棘手的问题。具体地，对于50％的指令正在更新仅5％的资源帐户的情形(这被认为是高度集中的情形)，这是一个特别棘手的问题。

当需要核对数据文件(其存储有实体的现金帐户)以查看资金是否针对待要执行的指令为可用的时，可看到这个情形的非限制性实例。当在先指令更新了现金帐户位置以作为其指令的执行结果之后，需要针对每条指令来执行对这个资源帐户的核对。由此，这些处理需要有序进行，否则执行能改变该帐户余额(balance)的一条指令的动作即可使得同样需要访问该帐户的任意后续指令无效。现有机构(以下所述)的最大处理速度都受此限制。

在使用了并行处理机构的现有系统中出现的另一问题是“死锁(deadlock)”。以下是出现这个问题的条件：两条并行指令访问相同的两个帐户，导致一条指令锁住一个资源帐户，且另一指令锁住第二资源帐户。这避免每条指令对于其他帐户的访问(这是为了核对以实施指令)。在等待状态下捕获这两条指令，从而避免它们执行提交(执行)动作来处理指令。应该理解，当一条指令的回退将释放另一条指令的处理时(总有这种可能)，这个方案大大降低了指令处理的吞吐量。

核对和更新电子帐户文件的基本处理对单个处理而言似乎价值不大，但每天几百万条这种指令的处理使得该方案不会没有意义。结算实体采用任意系统的目的在于实时地获得能得到的最高吞吐量。任意方案的可扩展性特别重要，因为其对任意处理步骤的时间的少量节省，对于大量指令的处置而言，这种节省会成倍增加。

已开发出很多现有系统来实施这种结算过程，并且下面将参照图1至图5描述这种系统的典型实例。

参照图1，示出一般的现有中心资源管理系统10，其被设置为每天处置几百万条指令数据消息。系统10被耦接至各种信道12，信道12可以是专门租借的通信线路，或者也可以是其他类型的有价证券信道。经由这些信道，系统10连接至很多不同参与方的服务器。在这个实例中，为了简化说明，系统10连接至A方服务器14和B方服务器16。A方服务器14和B方服务器16均访问记录的各个数据库18、20，其中每个记录描述了与另一方的协定。

中心资源管理系统10典型地包括指令执行服务器22，该指令执行服务器22访问主资源数据库24，主资源数据库24包含表示所有参与方(即本实例中的A和B)的资源帐户的数据记录。

参照图2，提供的是对每个参与方的主资源数据库的结构的示意性表示。数据库24包括针对每个参与方的多个不同类型的资源帐户文件30，以及包括针对这一参与方的累积(aggregated)资源值指示符32。在这个特定实例中，给每个指令数据消息定向，以实行针对这些帐户文件30的命令或指令，典型地，从一方帐户向另一方帐户传送资源，并相应地更新累积资源值指示符32。帐户是数据文件30，其表示参与方14、16的实际资源。资源可以是一个参与方的任意资源。在这个实例中，它们表示一方拥有的且该方希望交易的任意事物。

现在参照图3，示出指令数据消息40的一般结构或格式。指令数据消息40主要具有6个基本字段，需用这些字段来实行指令。指令数据消息40具有参与方ID字段42，用于识别指令的参与方；在这个实施例中，指令数据消息40可识别A方和B方。其还提供有执行日期字段44，以定义待要执行这个指令消息40的日期。剩余4个字段识别资源细节，这是指令的主体。提供第一资源类型字段46和对应的第一资源数量字段48，用于识别第一方(例如A方)的资源以及待要纳入该指令中的该资源的数量。提供第二资源类型字段50和对应的第二资源数量字段52，用于识别第二方(例如B方)的资源以及待要纳入该指令中的该资源的数量。

对于双方之间的每个协定，将存在两条指令数据消息(每方一条)。

图4示出图1的现有指令执行服务器22的组件(component)。所述组件包括指令验证器60，其被设置为核对所接收的指令数据消息40的有效性；以及指令匹配器模块62，其使得涉及相同协定的2个不同指令数据消息40匹配在一起。指令匹配器还针对匹配后的指令数据消息40创建结算指令。还提供有定时模块64，用于将当前时间与关联于新创建的结算指令的时间相比较。定时模块64还可确定用于访问每个参与方的资源帐户文件30的定时窗口当前是开放的还是关闭的。还提供指令数据库66，用于存储未来执行的结算指令。指令执行服务器22还包括报告模块68，用于给相关参与方传送信息消息。最后，在指令执行服务器的中心，提供有指令核对执行和更新引擎70。报告模块68被耦接至指令验证器60、指令匹配器62和指令核对执行和更新引擎70。待要处理指令的方式由指令核对执行和更新引擎70的特定数据处理机构来确定，并且其在不同的现有设备(如以下所述)之间是不同的。

下面参照图5的流程图描述指令执行服务器22的运行方法。下面将更详细地描述以下步骤：即，通过在定位引擎70处执行指令(结算指令)并更新和报告更新的结果来接收、验证和匹配指令数据消息40的步骤。更具体地，现有指令执行服务器22的一般处置78在步骤80开始，其中服务器22连接至信道12且针对接收指令数据消息40是可接收的。然后，在步骤82，A方给服务器22发送数据指令消息40，其描述与B方的协定。类似地，在步骤84，B方给服务器22发送数据指令消息40，其描述与A方的协定。在服务器22自身处，接收消息40，并且指令验证器60在步骤86尝试验证每个所接收的指令40。如果在步骤88的验证核对失败，则在步骤90将其传送至报告模块68，并在步骤90向未通过验证的数据指令消息40的源发送报告消息(未示出)。

否则，针对经验证的指令数据消息40，在步骤92指示报告模块68，以向经验证的指令消息40的源发送回肯定消息，以指示指令数据消息40的接纳和有效性。

将经验证的指令消息40传递至指令匹配器62，并且在步骤94作出尝试以匹配用于描述相同协定的对应的指令数据消息40。

在步骤96，指令匹配器62尝试将不同消息40匹配在一起。如果在步骤96的匹配核对失败，则在步骤98将其传送至报告模块68，并且在步骤98将报告消息(未示出)发送至不匹配的数据指令消息40的源，并且处理在步骤100结束。这里，这个失败被特别简单地示出，以简化对现有系统的说明。然而，在实践中，匹配失败可能是只有在多次尝试之后才能得出的结论，以及可能是在设定的匹配时间段过期之后(可能是几天)才能得出的结论。

向报告模块68通知在步骤96确定的匹配的指令消息40，所述报告模块68轮流在步骤102向匹配后的数据指令消息40的源(此处的A方和B方)报告指令数据消息40的匹配对的存在。此外，指令匹配器62随后在步骤102创建具有执行日期的执行指令(结算指令)。这个执行日期在步骤104从匹配后的指令数据消息40的任一个(因为它们相同)的执行字段的日期获得。然后，在步骤104，将执行结算指令的日期与执行时间窗口(由定时模块64确定)的当前日期和有效性相比较。

如果在步骤106确定的比较结果为结算指令现在不可执行，则在步骤108，将结算指令存储在指令数据库66中。以规则间隔核对数据库66，并且处理78在步骤110一直等待直到执行日期并执行窗口开放。典型地，执行窗口每天可开放几个小时。

可选地，如果在步骤106确定的比较结果为结算指令现在可执行，则不存储结算指令。

在步骤112，指令执行服务器22的一般处置78进程中的下一阶段是向指令核对、执行和更新引擎70(也称为定位引擎)发送结算指令。定位引擎70具有与其关联的一组执行规则“(rules)72。这些规则72确定是否可执行结算指令，即，其确定针对资源帐户文件30和累积资源值32的结算指令的结果是否将是可接受的。不可接受的条件的实例是，作为执行命令的结果，特定资源帐户文件30或累积资源值32是否将具有预定数量以下的值。在上述非限制交易结算系统的实例中，资源帐户可以是现金和有价证券帐户，累积资源值32可以是信贷额度(credit line)，其中当资源被用作针对所提供的信贷的保证时，资源的当前值提供一个定量的信贷。

在步骤114，定位引擎70核对如果执行命令的话是否仍将满足执行规则72，即，针对双方的资源帐户文件30和累积资源值32产生的影响将是可接受的。

如果在步骤116确定不能满足执行规则，则在步骤118向报告模块发送提示，并且报告模块在步骤118生成和发送消息，向失败的结算指令的双方(例如此实例中的A和B方)报告未成功的结果。随后，在步骤120，失败的结算指令留在定位引擎70中，并在后续时间/日期重新尝试(重复步骤114至126)以进行结算。

可选地，如果在步骤116确定能满足执行规则72，则在步骤122执行结算指令。然后，在步骤124，定位引擎70用执行结算指令的结果更新资源帐户文件30中的当前位置，即，在实行了资源的转帐(transfer)之后，用正确的余额更新累积资源值32。最后，在步骤126指示报告模块68，以在步骤126生成和发送消息，向成功的结算指令的双方(例如此实例中的A和B方)报告结算的成功结果。

结算指令的成功执行使得现有指令执行服务器22的一般处置78针对该单条指令结束。然而，由于每天处理几百万条指令，所以处理78针对从很多不同参与方服务器接收的其他指令数据消息40还要继续下去。

如上所述，结算指令的待要处理的方式通过指令核对执行和更新引擎70的特定数据处理机构来确定，并且这在不同的现有系统之间是不同的。主要存在两种不同类型的方法：批处理和并行输入匹配处理，下面将分别参照图6和7进行描述。

批处理是标准顺序更新方法，其中执行指令被存储以用于顺序处理，并且以自动方式依序执行。图6中示意性示出这个处理130，其中提供含有一批(有序集合)新指令(结算指令)的新指令文件132，同时提供主文件134，后者存储所有资源帐户文件30的当前位置和任意累积位置32。

每个结算指令对协定涉及的双方、资源帐户文件30、之前如图3所述的资源数量(其是在多方之间的协定的主体)和执行时间/日期加以识别。这种处理机构的主要特征是需要将这些结算指令按照它们涉及的资源帐户30的顺序予以列表。典型地，为每条指令提供顺序密钥(key)以协助交叉引用。

主文件134同样使用上述顺序密钥来顺序列出资源数据帐户30。针对批处理而言，主文件和输入数据文件之间的这个顺序对应非常重要。

提供顺序更新程序136，以确定是否每个协定均可由对应的指令的结算来实现。在处理引擎(未示出)上实施的顺序更新程序136使用称为匹配算法的标准算法。如上所述，匹配算法需要以顺序密钥的相同顺序存储两个输入文件(已有主位置文件134和新指令文件132)。在指令文件132中使用的密钥称为“交易”密钥，并且在已有主文件134中存储的密钥称为“主”密钥。

顺序更新程序136定义顺序读取文件132，134这两者的逻辑，直到这两个文件结束为止。顺序更新程序的结果被存储在新主文件138中，该文件保持所有参与方的资源帐户文件30的更新位置和累积位置32。

顺序更新程序136通过读取每个文件132、134的第一指令或记录来开始。顺序执行与给定资源帐户文件30相关的所有指令，资源帐户文件30的值的每次改变在运行匹配算法的处理引擎的存储器中被更新。一旦完成了特定资源帐户文件30的更新(通过下一指令的交易密钥的改变来感测)，随后将该资源帐户文件30所获得的值与任意更新后的累积位置32一起写入新主文件138。针对每个不同资源帐户文件30重复此处理，直到到达交易文件132的结尾。

在需要更新多个资源帐户以执行指令时，使用更加复杂的方法。为了处置多个帐户的更新，将更新分成多个阶段。该方案是仅在第一回合执行资源帐户值的借贷(debit)，在针对对应的资源帐户应用信贷(credit)之前以资源帐户的借贷的顺序报告成功借贷的指令。当因为资源帐户的信贷被延迟时，失败的指令将带来问题，这可通过多个回合来解决。

顺序更新程序136典型地定义了处置以下情形的逻辑：

交易密钥＝主密钥  ＝＞将当前指令应用于资源帐户文件的当前主数据记录

                  ＝＞将当前资源帐户的新位置存储在存储器中作为更新后的主记录

                  ＝＞读取下一指令

交易密钥＞主密钥    ＝＞将更新后的主数据记录写入新主文件138

                    ＝＞恢复主数据记录(如果可用)或针对下一主

数据记录读取主文件

交易密钥＜主密钥    ＝＞存储当前主记录

                    ＝＞创建缺省主记录

                    ＝＞将指令应用于主记录

                    ＝＞从交易文件读取下一指令

                    或

                    ＝＞拒绝指令，因为对应的主文件信息不存在，

即，在主文件134中未找到帐户资源文件30

                    ＝＞读取下一指令

当这个处置完成时，从交易文件132读取下一指令记录，并且重新应用相同处理，直到交易密钥变为大于当前主密钥为止。

在这个算法中，存储器中的单个处理网织(net)针对新主文件138的多次更新，这无疑提供了指令的更快处理。其局限之处在于所有指令需要在运行处理(批)之前被分组和分类。所有指令还需要在能够向多个参与方返回第一应答消息(该第一应答消息确认指令执行)之前被处理。此外，在批处理中，当运行匹配算法时，数据不可用于其他处理。为了实时提供对数据的访问，需要数据库更新。如果直接进行此更新，则这些数据库更新抹杀了处理的总吞吐量。如果在执行(例如DB2加载实体)之后的附加步骤中实施此更新，则不利地阻止了在该时段对数据的所有访问。其结果是，批处理在执行时是非常有效的，但是因为在执行之前需要进行分组和分类，因此不能实时地执行。

图7中示出另一备选方法，即，之前提到的并行输入匹配方法。在这个方法中，由多个处置计算机或处理140、142的独立指令来处置由指令匹配器62生成的结算指令。同样，顺序文件处置处理144可处置在指令数据库66中存储的一批指令。每个处理140、142、144针对直接更新程序146都有自己的版本，其可读取当前资源帐户30的值和累积资源值32，以及在主数据库24中针对参与方的资源帐户文件30创建直接更新指令。提供单个指令执行管理器148，以通过从处理140、142、144接收的指令作出关于数据库24更新的最终决定。指令执行管理器148使用执行规则72的集合(见图4)来提交用于执行的更新指令或将其回退用于随后执行。

指令执行管理器148必须实施的执行规则72之一处理停工(lockout)的问题。如先前所述，停工是当进行用于另一更新指令的处理时避免针对资源帐户文件30的访问的情形。在实践中，这意味着通过插入等待状态直到从在先更新指令已释放出资源帐户文件30(即，已经完成在先更新)为止来处置有关更新特定资源帐户30的争用。这样，指令执行管理器148避免两个不同更新指令并行修改同一资源帐户文件30。

每个处理140、142、144并行运行，并且提供比单个处理更大的带宽，这应能导致更大的潜在吞吐量。更具体地，当更新被分配在大量不同资源帐户文件30上时，并行系统是可扩展的。在这类情况下，可以通过并行运行很多更新处理140、142、144来增加系统的吞吐量。然而，当所述更新未得到很好分配时，意欲确保数据完整性的停工处理的实施会快速封项系统能达到的最大吞吐量。当到达这个极限时，多运行一个更新处理不会增加整体吞吐量，因为这还会增加针对不可用(锁住)的资源帐户文件30的其他更新指令的“等待状态”。

这个方法对于实时更新是优良的，但其在大部分情形下得忍受较差的吞吐量。这是因为，一般而言，通常都不是将更新分配在大量不同资源文件30上。在很多应用中，倒是很多不同指令大量使用某些特定的资源帐户反而更常见。例如，在交易结算领域中，常常是50％的指令集中在5％的可用资源帐户文件30上。在这类情况下，图7的实时处理技术具有较差性能。

另一个侧重考虑的问题是失败指令的再循环(recycling)。对于因为资源帐户不具有满足执行规则的所需值而在特定时刻不能够及时执行的任意指令，这里只是将其简单存储以在后续时间再次尝试执行。可以将每次临时性失败报告至指令者，其指示一旦资源帐户条件业已改变即可执行指令。多次失败的尝试或超时时段的过期可导致作为最终失败的指令的报告。

这种现有的再循环处理利于降低提交至引擎的新指令的数目。通过将指令保持为“挂起”，当条件改变时将获得更多的处理机会。如果进行处理的指令的数量是给定的，当不属于不得不报告最终失败的情形时，大部分再次循环的指令存在将被执行的极大可能。

然而，这种再循环会导致执行引擎的吞吐量成问题，因为该执行引擎由于再循环处理会降慢速度。具体地，在并行输入时，描述较大资源帐户动作的指令因为在再循环周期内(在超时发生之前)没有达到它们执行的条件而常常失败。在顺序输入时，这种失败可导致需要更多回合来处置这些失败指令。

已有尝试克服这些问题的诸多努力。而且，致力于发现解决这些问题的方案的金钱和资源量都颇为不菲。尽管有这些努力，在指令处理机构中吞吐量与实时处理的矛盾仍然存在。

在以下文献中描述了各种现有技术，这些文件用于示出所述问题及了解到其尚未发现可行方案的时间长度。

1)KAI LI等人：“多处理器主存储器交易处理(Multiprocessor MainMemory Transaction Processing)”19881205；19881205-19881207，1988年12月5日，P177-187，XP010280434。

2)GARCIA-MOLINA H等人：“主存储器数据库系统：汇总(MAINMEMEORY DATABASE SYSTEM：AN OVERVIEW)”IEEE关于知识和数据引擎的交易，IEEE服务中心，LAS ALAMITOS，CA，美国，第4卷，no.6，1992年12月1日，p509-516，XP001167057ISSN：1041-4347。

3)GRAY等人：“交易处理：概念和技术，选段(Transaction processing：concepts and techniques，PASSAGE)”1993年1月1日，交易处理：概念和技术，p249-267，301，XP002323530。

4)GRAY等人：“交易处理：概念和技术(Transaction processing：conceptsand techniques)”1993年1月1日，交易处理：概念和技术，p333-347，496，XP002207245。

本发明寻求克服至少一部分上述问题，以及提供用于实时处理和处置超大量处理指令的改进系统。

在考虑本发明的更具体的目的之前，重要的是理解任意指令处理机构的某些重要特征，并且这些将在下文中阐述。

每个新系统将具有特定的吞吐量要求。吞吐量表示系统为顺应系统目的而应该在预定时段内执行的指令数。吞吐量可通过每天、每小时、每分钟或每秒处理的指令数来表示。当每秒大于100条指令时，吞吐量被限定为“高吞吐量”。

在以指令处理器的单个实例来实施处理机构的系统中，这个处理器应能够达到所需的吞吐量。然而，在单个处理器不能够实现时，具有处理器(其对指令进行并行处理)的多个实例应能使得该目得以实现。在后一情形下，整体吞吐量是每个实例达到的吞吐量的总和。如果用多个后续步骤构成指令执行处理，则由最弱(最慢)步骤(例如瓶颈)的吞吐量来确定总指令执行处理的吞吐量。

新系统的响应时间表示在从第三方服务器对进来的指令执行请求的接收与向该服务器发送回相关应答之间经过的时间。可将具有5秒以下的平均响应时间的指令处理系统限定为“实时”系统。当运行指令处理器的单个实例时，可测量响应时间以作为处理请求(读取请求和执行指令)的时间和发送应答(生成应答并发送)的时间。如果请求以大于系统吞吐量的速率到达，则出现请求排队。在这种情形下，请求在队列中花费的时间不得不看作针对该请求的总系统响应时间的一部分。当指令处理器包括多个处理步骤时，系统的总响应时间被计算为多个步骤中的每个的响应时间的总和。

典型地，每个指令处理系统通过几百个参与方的服务器来运行，并且本地存储有针对每个参与方的对应的资源帐户。因为每个参与方可具有很多资源帐户(几十和几百都不罕见)，指令所涉及的资源帐户就能横跨所述很多资源帐户文件而均匀传播。然而，在指令处理系统的某些特定应用中，要求在指令中频繁涉及少量的资源帐户文件集合，从而以高频率更新。指令处理系统的集中确定少量资源帐户文件集合在处理后的指令中被频繁涉及的程度。具有50％的指令更新5％的资源帐户文件的指令处理系统定义为具有“高度集中”。

通过给定上述特征，本发明的另一更具体目的在于提供一种指令处理系统，其实时地运行(如以上所定义)，具有高吞吐量(如以上所定义)，并且可处置高度集中(如以上所定义)。

发明内容

本发明部分地基于对现有技术在可处理高度集中的指令的实时指令处理系统中尝试实现超快吞吐量时的局限性的考虑。本发明人开发了一种新的混合数据处理机构，其在必要时利用了分配式处理的速度，而在其他时间利用了顺序处理的确定性，针对可处理高度集中并且可实时运行的海量指令提供最佳的数据处理机构。

根据本发明的一个方面，提供一种在处理时段(session)期间实时处理和处置超大量(very high)处理指令的系统，每个处理指令指定涉及两个不同实体的资源帐户数据文件以及在这些文件之间要交换的资源的数量和类型，该系统包括：多个预加载器，每个预加载器被设置为获取关于指令的参考数据，所述参考数据指示每个指定资源帐户数据文件30的当前值，以及所述多个预加载器被设置为并行操作以从主数据库读取针对多个各自接收的指令的参考数据；加料指令队列，用于将多个处理指令与它们各自预加载的参考数据一起排队；执行引擎，被设置为使用所接收的参考数据依序确定每个接收的指令是否在相关资源帐户文件的当前值下是可执行的，以及被设置为针对每个可执行指令生成更新命令；更新器，响应于来自执行引擎的更新命令，利用每个可执行指令的结果更新主数据库，将更新器的操作从执行引擎的操作退耦(decoupled)。

为了实现本发明，发明人第一个理解以下阐述的各点。

为了提供实时响应，本发明的指令处理系统需要能够处理和响应各自的请求。因此，不可能实现纯粹的“面向批处理”的技术方案，即使这种方案很有效。

本发明的指令处理系统必须达到超高吞吐量，并且为此，在短时间段内将针对存储的资源帐户文件执行大量更新。在常规的现有并行输入匹配方法(图7所述)中，实时处理是可能的，并且可通过并行运行指令处理器的多个实例来实现吞吐量的增加。然而，因为系统有处理高度集中的指令的要求，并行运行指令处理器的多个实例将仅会导致指令的锁住的增加，这不利于减少吞吐量。

本发明业已理解针对现有方法的特征的新特定组合可导致方案的改善，其获得本发明的目的。新的混合方案通过依序处理指令来避免对指令的锁住效应。这样导致的吞吐量的减少通过将实际处理减少至无冗余的最小值(即仅需要指令处理器作出是否可执行指令本身的决定)来排除。帐户资源文件的更新从指令处理器和缘于其的外包(outsourced)作出的决定退耦，从而增加指令处理器的吞吐量。而且，通过利用作出处理决定所需的所有数据来预加载指令，指令处理器避免了费时的数据库访问。

因为本发明基于单个顺序执行引擎的运行，所以其需要将参考数据预加载至处理指令。如果不是这样，在预加载器下游执行的单个顺序执行引擎将不能够达到期望的高吞吐量。这是因为执行引擎必须读取参考数据的很多值，以处理指令，以及如果读取动作是针对主数据库而执行的，则其在处理器周期方面将非常耗时。为了达到期望的整体吞吐量，预加载功能以多实例组件实现，这意味着优选提供多个预加载器，用于针对并行处理的多个指令中的每一个来读取一次主数据。而且，预加载器还可具有多个(multiple)输入队列(实例)，其有助于缓解瓶颈，每一个输入队列被设置为向多个预加载器对应的一个提供专用输入。并行处理的可扩展性不受锁住问题的威胁。这是因为预加载器操作是只读的，其不会引起锁住问题。

主数据库仅通过更新器而被实时更新。因此，预加载器的只读处理将有利于不产生数据库锁住。预加载器刚好在尝试读取已经被更新器的更新处理锁住的资源帐户文件时延迟。通过增加并行运行的数据读取功能的新实例，这也有利于预加载器性能的可扩展性。

所述系统还包括：当前状态表，其存储在该执行引擎处，并且被设置为利用针对资源帐户文件的执行指令的结果来被更新，从而获取每个更新后资源帐户文件的更新后的实时值的表示，其中针对指令的后续顺序处理配置，该执行引擎被设置为针对特定资源帐户文件优先于来自预加载器的参考信息来使用当前状态表中的信息。

其中每个预加载器包括主数据收集器，每个主数据收集器被设置为从主数据库读取。因为这是异步处理，参考数据的检索值可能过时(obsolete)。但这不是问题，因为执行引擎了解当其第一次接收信息并将其存储在当前状态表中时主数据是精确的。如果执行第一指令，则进行当前状态表中资源帐户文件的值的更新。然而，同样引用相同资源帐户文件的后续指令方便地使用当前状态表中的值，以具有针对特定资源帐户文件的精确更新值，而不是主数据库的过时值。

为了确保尽可能快地实现当前状态表，执行引擎优选包括高速本地数据存储器，用于存储当前状态表。

所述系统还可包括：初始输入队列，被设置为从多个不同的源接收实时指令和批指令，以及针对预加载器的输入而对指令进行排队。同样，可提供初始输入队列的多个实例，以利于吞吐量。优选地，初始输入队列(多个队列)被设置为给每个进来的指令分配优先级。

当处理指令的结果导致违背执行规则集合时，出现处理指令失败。所述规则可提供处理的不可接受结果的定义或阈值。例如，如果其导致资源帐户的数量在零以下，则指令可能不是可接受的。对于某些资源帐户而言，当累积资源值处在预定水平以下时，可达到阈值。

执行引擎被设置为根据每个指令的优先级处理指令。优先级控制还被应用至可被再循环的失败指令。为此，执行引擎包括失败指令的重新处理，当指令所涉及的资源帐户之一的余额发生改变(其典型地是增加)时，失败指令可能成功地变为可执行的。

系统在处理时段(session)内运行，典型地，每日一个时段。从操作日角度来看，时段的开放触发所有预存储的指令的执行，当系统不可运行时其不能够被处理。在这个初始时期，系统动作更是面向批处理的。然而，即使在时段开放期间，当指令批次正在被系统接收以用于处理时，系统也能够实时处理任意新进来的非批次(non-batch)处理指令，给它们分配优先级，以及根据它们的相对优先级对其排序以用于处理。

优选地，执行引擎包括：再循环模块，用于在高速本地存储器中存储失败处理指令，以及用于在由失败处理指令识别的资源帐户文件中已经发生更新之后，呈上失败处理指令以用于重新执行。优选地，可针对这些失败指令分配优先级，以提高在再循环期间成功执行的可能性。更优选地，系统可被配置为给具有大资源帐户借方或贷方金额流动(movement)的指令提供的优先级高于具有更小金额流动的指令的优先级。

一旦完成了由时段开放触发的大批指令，系统的动作就是纯粹实时的。在这个时期，特定资源帐户文件的值或特定累积资源值的任何增加都导致所有因该特定资源帐户文件的值或特定累积资源值太小而无法结算的在先指令被再次循环。优选地，这个再循环根据上述为了再循环而存储的每个指令的预定优先级来执行。

优选地，所述再循环模块被设置为按失败指令的优先级的顺序存储所述失败指令，以及在再循环过程期间首先呈上最高优先级的指令用于重新执行。

因为执行引擎在其存储器中保存了所有失败指令，所以针对资源帐户文件的等级或累积资源等级的任意增加都可优选引起(trigger off)等待其增加的所有失败指令的再循环。执行引擎优选在其本地存储器中保存失败指令的这个列表，等待参考数据的增加(改变)，并且相对容易地处理符合优先级顺序的指令列表。

所述再循环模块可被设置为在列表中保留(reserve)针对指令的资源帐户文件的当前值，以及在再循环过程期间使用这个保留值以满足指令的要求。

为了大指令而在资源帐户中保留可用资源以避免较小指令使用这个数量，其提高了再循环的结算效率。例如，指令需要50而余额为30。此结算由于缺少20而失败。保留30将避免仅需要20来结算的较小指令的执行。其目的是如果发生了20的接收(可由其他指令的执行提供)的话，则给待要执行50的较大指令提供一次机会。这个保留选项针对失败指令而保持(maintain)。再循环引擎尝试执行失败指令，当给定资源帐户文件的余额数量出现增加时，其可增加保留数量。

如先前所述，现有执行引擎中指令的再循环导致执行引擎的总体性能减慢。而上述动态再循环则大大提高了效率，从而执行引擎的总体性能实际上得以比根本不提供再循环功能的情形更快。

因为执行引擎在其存储器中保存资源帐户文件的当前值和累积资源层的更新后的精确映像(image)，在本地存储器自身中可相对容易地实质化(materialize)用于保留的任何需求。因为在执行引擎的操作中不存在并行性，所以按优先级顺序接收指令，使得最高优先级的能首先保留。

所述再循环模块可被设置为呈上失败处理指令以用于重新执行到预定的最多次数，而如果处理指令仍没有被执行，则再循环模块可被设置为取消所述失败指令。

业已创建了具体实现本发明的系统，以实现期望的目的。从所采用的机构来看，该系统具有以下技术特征：

该系统实时运行。当实体发送指令时，典型地，在三秒内接收反馈(指令的成功或失败)。这个经过的时间包括在实体的通信设施(infrastructure)和该系统平台之间传输所接收的指令和应答消息所需的时间，以及执行指令的处理所需的时间。这分为向处理平台传输消息的一秒，在处理平台内执行的一秒，以及向指示器传输回应答消息的一秒。当然应该理解，传输时间可略微改变，因为它们取决于网络传输负载和运行条件。由此，上述时间表示针对指令而到达和来自SSE的平均传输时间。

具体体现本发明的系统实现了高吞吐量。更具体地，该系统能够实现在峰值时间每秒500条指令的吞吐量，这典型地发生在处理时段的开放之时(正在接收批指令时)。

具体体现本发明的系统实现了所谓的“最终同步”。这意味着，当执行引擎正在处理指令时，针对所有所涉及实体的受影响(effected)的资源帐户和累积资源值的更新作为相同的工作逻辑单元的部分来执行。

具体实现本发明的系统被配置为能够通过其他应用访问资源帐户值的主数据库。当系统是活跃的(active)时，这个可用性有利于还需要引用主数据库的外部系统的运行。

对本发明的机构的设计导致具有非锁住关系(non-locking affinity)的系统。以如下方式管理在主数据库上执行的更新，即当执行引擎以高速率更新相同的资源帐户文件时，不影响性能。当其中存在集中更新(例如能在一秒内更新50次特定累积资源值)时本发明的这个特征真正有利。

优选地，该系统还包括：步进模块，用于确定执行引擎的处理指令吞吐量，以及将等待状态应用至指令注入处理(队列)，以将处理指令的加载速度减慢至小于执行引擎的吞吐量。此外，在执行引擎具有几个处理模块时，每一个处理模块都具有多个实例队列用于加载指令，步进模块被设置为将等待状态应用至执行引擎内的任意处理模块的任意队列，以将加载指令的速度减慢至小于执行引擎自身的吞吐量。

在消息排队设计中，该系统应避免在任意指令队列中存储太多指令。实际上，消息排队系统被设计为用来传输指令，而不是将它们当作数据容器。后者这个功能应该留给数据库。当然，在对很多指令排队时，指令队列不能够直接在存储器中保存它们。在这种情形下，指令队列反而不得不将它们卸载至磁盘。结果，吞吐量急剧降低。

为了避免在系统中存储太多消息，步进模块控制向系统中加载新指令的速度。如果加载速度大于排队设计的最弱链路的吞吐量，将会发生排队。为了控制加载速度，可在每次提交之后执行称为“步进”的休眠时间，以避免加载吞吐量超过预定速率。

优选地，所述执行引擎包括报告模块，用于报告所接收的指令的执行结果，所述报告模块被设置为针对已经被确定为可执行的每个指令输出更新指令，以及针对每个失败指令输出通知指令。

该系统还可包括：最终队列，被设置为从报告模块接收更新指令和通知指令并对其排队。

从执行引擎决定更新的主数据库的退耦是本发明的机构中与现有技术的主要不同。将更新指令放置于最终队列中是将指令宣称为最终的方式。大部分现有批处理系统基于“全有或全无”而工作。所以，在批处理的结束处达到最终。大部分现有实时系统通过提交主数据库中的改变来得到它们的最终指令。在本发明中，只要执行引擎将更新指令提交至最终队列中，则达到最终。这意味着，在主数据库中执行的指令和资源帐户文件的相关值之间不存在实时同步。

处理机构的这个退耦特征意味着由多个预加载器读取的参考数据可能过期。本发明确保第一时间向执行引擎提供参考数据，参考数据的值精确反映了参考帐户的实际当前状态和累积参考值。为此，系统优选需要确保在开始处理时段之前(即在开始预加载器和执行引擎的操作之前)在主数据库中反映用于反映指令的执行的所有更新命令。换句话说，应确保在开始处理时段之前，所有队列为空。

优选地，所述报告模块被设置为临时存储多个更新命令，直到提交事件发生为止，以及在发生提交事件时输出多个所存储的更新命令，其中所述提交事件表示通过执行引擎的工作的一个物理单元的完成。

通过设计，该系统处理步骤包括多个步骤。系统的整体吞吐量受到最弱链路的限制。当处理中的步骤通过并行处理而具有扩展性时，其不能够是最弱链路(通过并行运行进一步的步骤，其性能始终能提高)。结果，系统的最弱链路是顺序执行引擎，因为它是系统的唯一组件，其不支持并行处理。

为了提高执行引擎的性能从而提高系统的性能，必须尽一切努力，以通过避免不必要的外部数据访问来保持执行引擎的操作尽可能多地绑定CPU。通过使用多个预加载器，将执行引擎所需的所有读取数据预加载给指令，并且，在输出端中，将待要实现的所有更新指令绑定至单个指令消息中。结果，将执行引擎的外部数据访问限制至输入端中的一个持久消息，并限制至输出端中的一个持久消息。增加其他数据访问是可能的，但是会不利地减少系统的整体吞吐量。

为了提高性能，必须尽一切努力，以避免浪费(burning)CPU周期来执行除了实际指令执行之外的其他逻辑。作为实例，CPU周期在提交时期被浪费。由此，执行引擎具体实现工作的物理单元，其绑定(bundles)一组工作逻辑单元(在执行提交处理之前(在本地存储器中)执行多个进来的指令)。以50的提交频率，每秒500条指令的吞吐量导致每秒10个提交，而非500个！提交处理表示执行引擎的工作的物理单元。50的提交频率意味着50条处理指令因为正在进入技术提交阶段而得以执行和报告，所述技术提交阶段给所有被执行的更新设为最终(进来的指令的物理删除以及报告消息的物理写入)。

优选地，该系统还包括路由架构(framework)，所述路由架构被设置为向并行运行的多个初始输入队列或更新实例队列分发指令。在多个不同队列或处理元件可用时(例如在预加载器和更新器中)，这使得指令均匀分配。

所述路由架构优选被设置为向指令分配指令名称和工作量均衡器(balancer)密钥，其中该指令名称描述所述指令涉及的信息类型，该工作量均衡器密钥提供识别指令的唯一密钥。在这种情形下，路由架构可被设置为通过使用接收指令名称和工作量均衡器密钥来选择输入队列或更新实例之一。

优选地，所述路由架构包括与所述路由架构组合设置的工作量均衡器，以通过使用接收的指令名称和工作量均衡器密钥来选择初始输入队列或更新实例队列之一。

针对使用并行处置达成吞吐量的系统的每个组件(例如预加载器和更新器)，在它们每一个之间通过工作量均衡器和路由架构正确地分配工作量。然而，有利地，这个分配并不会在排序规则(其定义待要执行进来的指令的顺序)中造成破坏。

路由架构和工作量均衡器能够在队列集合(例如主数据隔离队列)上分发工作量，以及确保具有相同排序密钥的指令被路由至相同队列。该架构能够通过分析可用实例的数目以及通过在不破坏排序限制的情形下传播出去的消息来直接针对目标处理的配置调整(adapt)自身。

换句话说，工作量均衡器被设置为将给定工作量均衡器密钥始终链接至相同的特定目的地，以确保始终将与特定资源帐户数据文件相关的所有指令路由至多个队列中的同一个。

优选地，该系统还包括定界符(delimiter)架构，被设置为响应于处理时段在给定时间的关闭，向在执行引擎的输出端处提供的队列的输入端发送消息并等待其响应，以及向更新器的输入队列发送进一步的消息并等待其响应，依序响应的接收指示用在处理时段的关闭之前执行的所有处理指令的结果来更新主数据库。

其中，该系统包括调度器模块，用于报告每个处理指令的结果，优选地，定界符网络还被设置为向调度器的输入队列发送消息，以及等待各自的反馈，以验证在处理时段关闭之前执行的处理指令的报告消息都已发送。

换句话说，定界符架构向执行引擎的输出(即最终队列)发送消息。只要接收到针对该消息的响应，这表示在定界符消息的到达之前在最终队列中存储的所有指令已经得到处理。之后，定界符架构可向调度器的每个实例发送消息，以及等待来自它们中的每一个的对应的反馈。当来自调度器的所有实例已经将它们的相关反馈发送至定界符架构时，定界符架构了解到已经完成了所有分派处理(指令、执行、结果和报告)。然后定界符架构可在更新器上开始定界处理。这可通过向主数据更新器的每个实例发送消息并等待所有相关反馈来执行。

当从主数据更新器的所有实例接收到反馈时，定界符了解到在期限之前与由定位引擎执行的处理指令相关的所有指令更新现在被反映在主数据库中。定界符工作流结束，并且可由调度器生成时段活跃性报告。

本发明还扩展成在处理时段期间实时处理和处置超大量处理指令的计算机实现的方法，每个处理指令指定涉及两个不同实体的资源帐户数据文件以及在这些文件之间待要交换的资源的数量和类型，该方法包括：从多个预加载器获取关于指令的参考数据，所述参考数据指示每个指定资源帐户数据文件的当前值，所述获取步骤包括并行操作所述多个预加载器以从主数据库读取针对多个各自接收的指令的参考数据；在加料指令队列中将多个处理指令与它们各自预加载的参考数据一起排队；利用执行引擎，使用所接收的参考数据依序确定每个接收的指令是否在相关资源帐户文件的当前值下是可执行的，并且针对每个可执行指令生成更新命令；以及使用响应于来自执行引擎的更新命令的多个更新器，利用每个可执行指令的结果来更新主数据库，更新步骤从执行引擎的操作退耦。

根据本发明另一方面，提供一种在处理时段期间实时处理和处置超大量处理指令消息的系统，每个处理指令指定涉及两个不同实体的数据文件以及在这些文件之间待要交换的资源的数量和类型，该系统包括：多个预加载器，每个预加载器被设置为获取关于指令的参考数据，所述多个预加载器被设置为并行操作以从主数据库读取参考数据；指令消息队列，用于将多个处理指令消息与它们各自获取的参考数据一起排队；执行引擎，用于依序执行每个指令消息，所述执行引擎使用预加载的参考信息而不是通过使用任意主数据库访问来确定接收指令是否在相关文件的当前状态下是可执行的；以及当前状态表，被设置为利用执行指令针对文件的结果而被更新，以创建相关文件的更新后的实时位置；其中执行引擎被设置为，针对指令的后续顺序处理，对于特定的数据文件而言，如果在处理时段期间已经由执行引擎更新了所述数据文件，则优先于使用来自特定数据文件的多个预加载器的参考信息而使用当前状态表中的信息。

本发明的这个方面提供如下方式，通过在存储器中具有针对执行引擎的最近资源帐户值的实时可更新副本来避免主数据库的更新。这是重要的设计特性，其克服了现有技术中实时处理海量处理指令的很多问题。

根据本发明的另一方面，提供一种在处理时段期间实时处理和处置超大量处理指令消息的系统，其中指令以不同速率被异步接收，所述系统包括：多个处理模块，用于执行针对指令消息的不同类型的处理，处理模块中的一个包括执行引擎，被设置为依序处理指令消息；多个指令队列集合，每个集合的提供用以对各个数据处理模块的输入进行排队；步进模块，用于确定执行引擎的处理指令吞吐量，以及将等待状态应用至任意指令队列，以将处理指令的加载速度减慢至小于执行引擎的吞吐量。

如前所述，一种在处理时段期间实时处理和处置超大量处理指令消息的系统，其中指令以不同速率被异步接收，该系统需要避免在任意指令队列中存储太多指令。需要传输而不是存储所述消息，存储消息是数据库的功能。如果排队指令的数目变得太大，则必须将它们卸载到磁盘，这是直接减少吞吐量的耗时处理。

为了避免在系统中存储太多消息，步进模块有利地控制向系统中加载新指令的速度。如果加载速度大于排队设计的最弱链路的吞吐量，则发生排队，在这种情形下就是顺序执行处理器。为了控制加载速度，可在每个处理时间单元之后执行称为“步进”的休眠时间，以避免加载吞吐量超过预定速率。

根据本发明的另一方面，提供一种在处理时段期间实时处理和处置超大量处理指令消息的系统，每个处理指令指定涉及两个不同实体的数据文件以及在这些文件之间待要交换的资源的数量和类型，该系统包括：多个预加载器，每个预加载器被设置为获取关于指令的参考数据，所述多个预加载器被设置为并行操作以从主数据库读取参考数据，以及向执行引擎输出参考数据和指令消息；所述执行引擎被设置为依序执行每个指令消息，所述执行引擎使用预加载的参考信息而不是使用任意主数据库访问来确定指令消息是否在相关资源帐户文件的当前状态下是可执行的；以及高速本地存储器，用于存储当前状态表，其被设置为利用执行指令针对文件的结果而被更新，以创建相关文件的更新后的实时位置；再循环模块，用于在高速本地存储器中存储失败处理指令的列表，以及用于执行再循环处理，其中在由失败处理指令识别的表中的资源帐户文件的更新已经发生之后，呈上失败处理指令以用于重新执行。

优选地，所述再循环模块被设置为按失败指令的优先级的顺序存储失败指令，以及在再循环过程期间首先提供最高优先级指令用于重新执行。这提供了以最大吞吐量处置指令的不同优先级的最佳方式。

所述再循环模块可被设置为在列表中保留针对指令的资源帐户文件的当前值，以及在再循环过程期间满足指令的要求时使用这个保留的数量。这确保能够在早期阶段识别针对资源的可能要求，以避免重要的故障。

此外，所述再循环模块可被有利地设置为提供失败处理指令用于重新执行到预定的最多次数，而如果处理指令仍没有被执行，则再循环模块能被设置为取消失败指令。这就避免了不打算执行交易的问题阻塞系统。

以上已描述了涉及再循环模块的动态再循环发明的优点，因此在这里不再重复。

附图说明

下面将参照附图描述本发明的具体实施例，其中：

图1是示出执行A方和B方之间的协定的指令处理的基本现有结构的示意图；

图2是示出在主数据库中存储的资源帐户文件的示意性框图；

图3是示出来自一方的数据消息指令的组件的示意性框图；

图4是示出图1的指令执行服务器的主要组件的示意性框图；

图5是示出现有指令处理平台的操作的一般性方法的流程图；

图6是示出用于批量输入的标准的现有匹配处理的示意性视图；

图7是示出用于并行多处理输入标准的现有匹配处理的示意性视图；

图8是示出根据本发明实施例的处理平台的示意性框图；

图9是示出图8的处理平台的操作的流程图；

图10是示出图8的处理平台的预加载器模块的操作的流程图；

图11是图8的处理平台的定位引擎的示意性框图；以及

图12是示出图11的定位引擎的操作的流程图。

具体实施方式

现在参照图8至图12描述根据本发明实施例的处理平台150。处理平台150位于指令执行服务器22中，该指令执行服务器22与参照图2和图4的介绍部分中的描述相似，并且在一般功能上等同于现有指令执行服务器22。更具体地，下面将描述的本实施例的处理平台150将替代图4中所示的现有指令核对、执行和更新引擎70。

从图8可看出，处理平台150包括4个主要组件：多个预加载器152、定位引擎154、调度器156和更新器158。这些组件与下述的排队和其他功能模块一起如图8所示那样设置。

预加载器152具有对所有参与方的资源帐户文件30和累积资源值32的主数据库24的只读访问。应该理解，在图8中，为了方便起见，主数据库24示出为预加载器152的一部分。然而，应该理解，预加载器152不包括主数据库24，因为在系统中仅存在一个主数据库24。更确切地，每个预加载器152用于从其自身专用初始输入队列164存取指令，包括主数据收集器182(如下所述)，其用于从主数据库24获得所需信息并向加料(enriched)指令队列166输出结果。每个预加载器152都包括主数据收集器182(然而，为了简洁，图8仅示出总共2个)。数据收集器182是处置进来的结算指令的模块，每个进来的指令被分配给单个主数据收集器182。主数据收集器182的功能是从主数据库24读取该命令的适当的主数据，以及将它们与原始结算指令组合在一起，以形成加料指令(未示出)，该指令从各个预加载器152输出。预加载器152(以及此后的主数据收集器182)的数目是可扩展的，因为它们都是并行执行它们的操作，当它们正在运行只读数据库的操作时，不存在任何数据库冲突(例如锁住)。当不断更新主数据库24时，这些现有问题可通过以下操作避免：分离主数据库更新和读取功能，并且在处理期间的第一次读取之后，不要求所读取的资源帐户值30是精确的。

定位引擎154包括单个实例逻辑处理器184和更新主数据记录表186，后者存储在处理器的存储器中。更新主数据记录表186包括与主数据库中的资源帐户文件对应的多个文件30a。然而，从图11可看出并且将在随后说明的是，并非所有资源帐户文件30具有对应的文件30a。

单个实例逻辑处理器184接收在预加载器152中创建的加料指令，并处理这些指令，每次一条，以确定是提交还是回退加料指令所基于的结算指令。实质上，如果在执行结算指令之后，针对每一方的资源帐户文件30的值和累积资源值32将是可接受的(即，符合执行规则72)，则结算指令被接受。为了作出这个决定，单个实例逻辑处理器184连续地用从可接受结算指令得到的每个资源帐户文件30的最新更新值来针对更新后的主记录存储器表186的对应的文件30a进行更新。资源帐户文件30a的这些更新值优先地用于随后接收的加料指令中包含的对应值。定位引擎154的输出是过去输入至定位引擎154的结算指令的列表，其指示指令是否为可接受的，即，所述指令是否应该被提交或是否是不可接受的(即，此指令应被回退)。此外，被回退的指令得以保留，并且可被再次循环，这将在随后详细描述。并非指令主体的这些资源帐户文件30在主记录存储器表186中不具有配对物(counterpart)，因此存储器的大小小于数据库的大小。

调度器156包括调度器程序模块188。调度器程序模块188接收从定位引擎154输出的处理后结算指令的列表，并且向与结算指令相关的参与方报告处理的结果(提交或回退)。针对回退指令，在响应消息中阐述失败的原因。针对提交的指令，将这些指令报告为成功处理后的结算指令，此外，将它们传递至更新器158。

更新器158包括多个主数据更新器190，每个主数据更新器190业已访问主数据库24的唯一部分。为了简洁，图8示出访问主数据库的3个部分24a、24b、24c的3个主更新器190。然而，在这个实施例中，这是平台150的可扩展部分，从而提供大倍数的主更新器190和相关的数据库的唯一部分24a、24b、24c。随后将描述将成功的结算指令分发至主更新器中的精确方式。

进入至处理平台150的输入来自多个顺序文件处置处理160，每个处理提供成批的结算指令160作为输入，以及处置计算机或处理162的一个或多个单独的指令(尽管在这个实施例中仅示出1个)，其处置实时接收的结算指令和待要被实时处理的结算指令。

在处理平台150的主要组件之间提供排队模块。在某些实例中，这些队列用作从并行处理域转换至顺序处理域或反向转换的装置。更具体地，提供多个初始输入队列164，作为多个预加载器152的输入，以对可从多个顺序文件处置处理160和个别的指令处置处理162接收的异步结算指令中的任一个进行排队。提供加料指令队列166，用于对预加载器152的主数据收集器的同时动作的结果加以整理(collate)，并将这些结果放置于顺序域中用于输入至定位引擎154。定位引擎154的输出是最终队列168，其还用作进入调度器156的输入。最后，在调度器156的输出和更新器158的多个输入之间提供多个主数据隔离队列170。来自调度器156的另一输出被送至应答队列172，其提供返回至指令处置处理162的实时消息。

为了避免疑虑，应该理解，如图8清楚地所示，可通过多个实例(即并行操作的多个队列)提供全部的初始输入队列164、加料指令队列166、最终队列168、主隔离队列170和应答队列172。

还提供3个其他模块来协助通过处理平台150的指令流。步进模块174将来自批处理160的指令的排队速率调节为处在平台150的吞吐量的最弱链路(weakest link)之下。由此，平台150中的队列始终几乎为空。

路由架构(framework)175用于经由工作量均衡器176向队列路由指令。路由架构灵活可变，它可在不改变所接收指令的排序的情形下改变路由的不同方面。

工作量均衡器176用于将指令的工作量分配在一组队列上，并确保具有相同排序密钥(随后描述)的指令/命令被路由至相同队列。

定界符(delimiter)架构模块178用于确保所有处理由定位引擎154执行，并且在给定时间内已经写入最终队列168，并且日期期限被反映在主数据库24中和确认更新的实时消息中。

现在参照图9，下面将描述处理平台150的总操作处理200。在步骤202，处理200通过从非实时批文件160或从实时的各指令处置处理162接收的结算指令而开始。例如，可通过重复存储具有特定的未来执行日期的指令以及为了一旦该特定日期到达就执行而创建的批次来创建非实时批文件。这里使用的术语“批”没有暗示必须以特定顺序排列记录。针对本实施例，在批中的结算指令的排序无关紧要。该术语更多是简单地用于指示结算指令的收集。

处理200继续，在步骤204，在初始输入队列164中针对所接收指令排队，用于随后向各个预加载器152的输入。此步骤204处的排队将结算指令的流从异步并行输入域转换成同步顺序域。然后，在步骤206，通过多个预加载器152处理指令，以从主数据库24获得针对每条指令的参考数据。这个处理使用多个主数据收集器182(一个收集器针对预加载器152之一)并行地执行。

针对每个结算指令，对结果信息进行整理，以在步骤208形成加料执行指令，其包含定位引擎所需的结算指令自身和所有参考主数据库数据，以确定是否在不违反执行规则72的情形下可执行该指令。同样在步骤208，将所有加料执行指令放置于加料指令队列166中。再次，加料指令队列166用于将并行运行的多个主数据收集器182的输出转换成待要处理的顺序加料结算指令的列表。

然后，在步骤210，定位引擎154依序顺序处理每个排队后的加料结算指令。随后描述这个处理的细节。然而，在步骤212，在此处确定结算指令是否可在违反规则72的情形下被执行。如果答案是否定的，则在214再循环结算指令，并且在步骤216生成通报用(notify)调度器消息。该消息指示结算指令未成功，但是在未来再次循环时还是可以成功的。

在步骤212，如果答案是肯定的，则在步骤218执行结算指令，并且用资源帐户文件30的新值以及在该结算指令中涉及的多个参与方的累积资源值32更新本地存储的更新后主记录存储器表186的对应的文件30a。然后，在步骤220，将执行后的结算指令存储为最终队列168中的更新执行指令，用于馈送调度器156以及用于随后传送至更新器158。尽管在图9中未示出，再循环后的指令同样在最终队列中具有项目。这些失败的指令同样位于最终队列中，但是仅用于报告目的，并且它们不被传递至更新器158上。

调度器156读取在最终队列中存储的指令，并且在步骤222，创建待要向由结算指令识别的多个参与方发送的报告消息，而无论指令成功与否。这些消息也在步骤222被发送至应答队列172，用于向结算指令的一方的指令处置处理162的实时输出。随后，在步骤224，输出应答队列中的消息。

针对最终队列168中的成功执行后的更新执行指令，调度器156还在步骤226将这些更新指令传递至多个主数据隔离队列170上。这个处理包括从工作量均衡器176和定界符架构178的输入，随后将详细描述。

最后，在步骤228，由更新器158更新分配至每个主数据更新器190的主数据库24的部分24a、24b、24c。

现在更详细描述处理平台150的主要组件及其功能。

初始输入队列164是平台150的公共接口。这允许将来自各指令处置处理162的输入流(其期望得到实时应答)与来自多个顺序文件处置处理160的批流(其期望超高吞吐量)合并。步进模块174控制向初始输入队列164中的输入。步进模块174将批指令的加载速度限制在平台的最低流量组件(典型地，其为定位引擎154)之下。针对批指令，加载速度需要被限制，以避免在初始输入队列164中产生积压(backlog)。来自各指令处置处理162的加载速度受到用户计算机的输入新指令的实时能力的限制。加载初始输入队列164的控制被应用于平台150中的所有队列。

步进模块174在处理一组指令(例如从主数据库的提取或基于文件的批处理)时被激活。在图8中，步进模块174用在流的上部，在顺序文件和初始输入队列164之间。其功能类似于浏览控制，因为其限制向初始输入队列164的批指令注入的速率，从而避免在指令流中的排队(在最弱的链路步骤处)。

出于两个主要原因来控制平台150中的队列输入速度。第一个是消息队列164、166、168、170实际上是传输层，而不是数据容器。可存储在队列中的消息或指令数目是有限的。产生积压可能导致队列满员条件而阻止任何负载处理写入队列。此外，当在队列中存储大量消息时，消息排队性能降低。这是因为通常需要在消息数据的盘上进行卸载。

用以控制负载处理的速度的第二个原因是确保来自各指令处置处理162的实时指令将不被排在一组批指令之后。当对实时请求进行排队时，针对各指令处置处理162的响应时间不能够匹配于实时响应(最大响应时间被设置为两秒)的要求。

通过两个后续提交之间的最小延迟来定义步进。在执行提交之后，计算在执行该提交的时间和执行在先提交的时间之间的delta时间。

实例：

当前提交＝2007-07-01-09.05.04.224335

在先提交＝2007-07-01-09.05.04.100635

在2次提交之间的经过时间(delta)为0.123700。

如果在两次提交之间的步进为0.5秒，则要执行0.3763秒的延迟。如果提交频率为50并且步进为0.5秒，则期望的吞吐量为100个指令。

向初始输入队列164的输入通过实行消息路由功能的路由架构175和工作量均衡器176来处理，其中提供工作量均衡(balancing)技术架构，用来横跨初始输入消息队列164的预定集合均匀地分发消息。

应该理解，在来自批文件160的指令或来自实时信道162的指令之间没有区别。在用于平台150的操作时间窗口(操作时段)开放时，要对所有挂起的存储指令进行排序，并将其注入至初始输入队列164中。排序规则还应用于在执行开放注入时实时进来的指令。需要基于实时指令的优先级而将它们注入至初始输入队列164。当完成操作时间窗口的开放过程时，正在进行中的排序是基于时间的。必须在相同初始输入队列164中注入涉及相同参与方的相同资源帐户文件30的两条指令(以便先后处理)。

针对多个初始输入队列164，为了处理例如在处理时段(操作时间窗口)开放时出现的大量初始指令，并行运行这些实例至关重要。这里，路由架构175负责将指令加载至多个初始输入队列164中，从而使得工作量均衡器176能够在初始输入队列164之间均匀地分配工作量。

每一个预加载器152均被设置为从初始输入队列164中对应的一个队列检索处理指令。其目的在于分析进来的处理指令，以从主数据库24检索所有参考数据，定位引擎154将需要这些参考数据来确定是否执行处理指令。参考数据是在处理指令中涉及的任意资源帐户文件30的当前值以及在处理指令中涉及的多个参与方的累积资源值32。然后，这个检索到的数据用于生成增强(enhanced)指令，所述增强指令不仅含有进来的处理指令，而且含有从主数据库24检索到的所有参考数据。

图10详细示出每一个预加载器152的操作。很显然，每个预加载器实例154独立和并行操作，以利于更大的吞吐量。

在步骤242，预加载器154的操作处理240通过从专用于该预加载器实例154的初始输入队列164读取结算指令而开始。然后，在步骤244，预加载器实例154的主数据收集器182确定每一个参与方的资源帐户文件30的数据库读取以及针对该参与方的累积资源值32。一旦计算了所有这些读取指令，则在步骤246，依序执行数据库读取。之后，在步骤248，通过预加载器实例154处理读取数据，以创建针对这个指令的参考数据的整理映像(collated image)。然后，在步骤250，将这个映像与原始指令加以组合，以形成合成的加料指令。在步骤252，预加载器操作240通过将每个预加载器实例154的合成加料指令输出至单个加料指令队列184而结束。

定位引擎154实现本实施例的创新性机构中的关键元件之一，即，定位引擎154的主逻辑处理器184不并行执行指令。因为主逻辑处理器184作为单个实例运行，它自身必须达到整体吞吐量。然后，这提升了主逻辑处理器184的时间临界(critical)操作的重要性。已经用来实现最高可能吞吐量的必要限制之一是需要禁止数据库访问，因为它们导致低吞吐量。在初始负载(主逻辑处理器184在此处能检索到高频使用的静态参考数据)之后，将到达和来自处理器184的外部数据访问限制为被输入的一个指令和被输出的一个处理结果。然而，借助于作为每个加料指令的一部分而提供的参考数据的整理映像，为了处理指令而需要用到但是在启动阶段没有加载的参考数据就变为可用。定位引擎154将在其对应的上传的主记录存储器表186的文件30a中仅仅存储从预加载器152之一接收的针对给定资源帐户文件30的参考数据的第一映像。这个第一副本始终有效，因为它还未被指令的实时流修改。

当已经处在上传的主记录存储器表186的对应的文件30a中时，简单地忽略由预加载器152之一检索到的参考数据的映像，因为其可能过期(在主数据库中还没有反映出由定位引擎154确认的更新)。因此，在上传的主记录存储器表186的对应的文件30a中，当与资源帐户的值相关的参考数据可用时，其总是优先于提供有加料指令的参考数据映像而使用。

现在参照图11，更详细地示出定位引擎154的组合。定位引擎154包括：指令接收模块260，用于从加料指令队列166检索加料指令；以及时间戳模块262，用于设置当前加料指令的时间戳。定位引擎154的单个实例逻辑处理器184包括参考数据检索和更新模块264、金额流动计算器和本地存储器存储更新器266和指令处理逻辑268。

参考数据检索和更新模块264用于检索在上传的主记录存储器表186的对应的文件30a中存储的数据，确定此数据是否将被更新，以及它是否要照样更新。在高速本地存储器数据存储装置(store)270中向单个实例逻辑处理器184提供上传的主记录存储器表186，这导致针对定位引擎154的快速数据读取和写入时间。由此，可仅通过快速的本地存储器数据核对而并非借助于耗时的外部数据库核对来进行指令的执行的确定。数据存储装置270还保留了失败指令(稍后再次尝试以进行结算)的再循环列表272。

金额流动计算器和本地存储器存储更新器266用于读取上传的主记录存储器表186的对应的文件30a内存储的参考数据，使用指令信息来确定如何改变(金额流动)这个数据，并且将更新后的参考数据写回上传的主记录存储器表186。

提供指令处理逻辑268，以评估资源帐户文件30的更新值和累积资源值32是否导致针对这个资源数据的可接受位置。即，评估资源帐户文件30的值和累积资源值32以符合规则72。

提供再循环模块274用于读取和向再循环列表272中写入失败指令，所述再循环列表272可由指令处理逻辑268顺序读取或写入。单指令逻辑处理器184的输出是发给报告模块276，其将指令处理的结果作为更新执行指令输出至最终队列168。

再循环基于输入指令的优先级而进行。优先级分组(例如高优先级、正常优先级和低优先级)之前已经被分配给每个指令。再循环模块274按照准备发生再循环事件的优先级顺序来保持再循环列表。主要根据向每个指令分配的优先级分组来确定顺序。之后，使用指令的大小来进行优先级排序(prioritization)。通过在再循环列表内保持优先级，使得再循环的实现相对简单，因此运行时速度很快。此外，所述再循环过程为动态的，因为其可改变重新执行所接收的处理指令的顺序，以反映每个处理指令的优先级。

再循环模块274还有能力保留通过特定指令处理的资源帐户文件30的内容。这发生在资源帐户文件中的可用资源数量应该满足存储的处理指令272的要求时。通过保留这个数量，再循环模块274确保优先级得以保持，并且在较小的低优先级指令之前执行大的高优先级指令，即使存在可用于执行低优先级指令但不能用于更大的高优先级指令的资金。

这在以下的非限制性实例中更好地示出，所述实例即定位引擎154中的再循环模块274如何实现对所接收的处理指令的保留和优先处理的实例。

实例：

资源帐户文件Acc/Sec1包含50个有价证券(securities)

通过以下Acc/Sec1的变动(impact)来依序接收处理指令：

步骤1高优先级指令1需要200

步骤2正常指令2需要100

步骤3正常指令3需要150

步骤4正常指令3带来60

步骤5正常指令4带来290

存储器结构(Acc/Sec1中的余额，以及再循环列表的内容)表示以下的Acc/Sec1的再循环列表：

在步骤1之后

Acc/Sec1

-包含50

-已经保留

-指令1，用于50

-失败列表<指令1>

在步骤2之后

Acc/Sec1

-包含50

-已经保留

-指令1，用于50

-失败列表<指令1，指令2>(ins2具有比ins1更低的优先级)

在步骤3之后

Acc/Sec1

-包含50

-已经保留

-指令1，用于50

-失败列表<指令1，指令3，指令2>(ins3具有与ins2相同的优先级，但是更大，所以更加重要)

在步骤4之后：Acc/Sec1的余额的增加已经再次循环了失败指令，其中该失败指令允许指令1向其保留(reservation)中增加新的60个有价证券。所述保留避免指令2(仅需要100)使用在资源帐户中可用的110个有价证券

Acc/Sec1

-包含110

-已经保留

-指令1，用于110

-失败列表<指令1，指令3，指令2>

在步骤5之后：Acc/Sec1的余额的增加启动再循环处理

在再循环开始时，存储器看起来是：

Acc/Sec1

-包含400

-已经保留

-指令1，用于110

-失败列表<指令1，指令3，指令2>

在指令1(在再循环列表中的第一个)的再循环(和结算)之后

Acc/Sec1

-包含200

-已经保留

-0

-失败列表<指令3，指令2>

在指令2(在再循环列表中的新的第一个)的再循环(和结算)之后

-包含50

-已经保留

-0

-失败列表<指令2>

指令2的再循环将失败(缺少50)。如果没有保留，则存储器保持不变。

现在参照图12详细描述定位引擎154的操作280。在步骤282，操作280通过从加料指令队列166读取加料指令而开始，然后在步骤284，通过时间戳模块262对读取的指令加上时间戳。通过给定每秒正在处理的指令数，时间戳具有高分辨率，并且典型地是直到毫秒的记录时间。

如果加了时间戳的加料指令包括新的参考数据，即还未存储在上传的主记录存储器表186的对应的文件30a中的特定资源帐户文件30的值(这是在步骤286确定的)，则在上传的主记录存储器表186中存储未知参考数据。如果参考数据不是新的，则在步骤290，操作280简单地移动至本地余额更新，这是在金额流动计算器和本地存储器存储更新器266上实现的。在这个步骤中，从本地存储器数据存储装置270中的上传后的主记录存储器表186读取参考数据，将指令中指定的金额流动应用于读取的参考数据，以及将参考数据的结果值写回上传的主记录存储器表186的对应的文件30a。

随后，在步骤292，指令处理逻辑268考虑参考数据的当前值，并且确定资源帐户文件30得到的更新值以及累积资源值32是否符合与参考数据的可接受值相关的预定规则72。当它们不符合时，采取三个动作。第一，在步骤294，经由报告模块276报告失败原因。第二，在步骤296，恢复参考数据的先前值。最后，在步骤298，在再循环列表272中存储失败指令，用于后续的结算尝试。

当更新后的参考数据符合预定规则72时，在步骤300，通过报告模块276报告结算指令的成功执行。这个报告用于生成针对指令所涉及的参与方的应答消息，以及指示更新器158更新主数据库24。然后，在步骤302均衡此动作的变动(impact)，即，生成适用于主帐户数据的资源帐户金额流动数据，并且创建余额更新消息集合。在以下阐述的实例中，在两个步骤中描述报告消息以及余额更新消息的生成。

最后，在步骤304，运行再循环动作，以观察修改后的参考数据现在是否允许任意之前失败的指令被执行。

当然，当正在被更新时，所报告的所有参考数据保存在定位引擎154的本地存储器(上传的主记录存储器表186)中，以在处理后续结算指令时重新使用(替代由预加载器之一提出的相同数据的过期版本)，该指令包括经再循环的指令。

始终不清除在定位引擎154的本地存储器270的文件30a中保持的更新参考数据30、32。在处理周期(例如为一天)结束时，定位引擎154停止，导致存储器的完全复位(reset)。如果在定位执行期间发生主要问题，则这个复位也会发生。特定的重启处理已经准备就绪，以确保所有最终更新都被反映至主数据库24，以及在重启多个预加载器152之前针对加料指令队列166中的所有挂起指令执行清除(此时，主数据库24反映所有余额的最终版本)。

下面将提供多个预加载器152和定位引擎154如何在一起工作的非限制性实例。

实例：

由预加载器实例1(主数据收集器1)处理指令1(Ins 1)。这是在acc1(其属于A方)和acc2(其属于B方)之间的结算指令，用于资源帐户类型：sec1针对Sec2的500单位交换Sec1的10个有价证券。

由预加载器实例2(主数据收集器2)处理指令2(Ins 2)。这是在acc3(其属于C方)和acc2(其属于B方)之间的结算指令，用于sec1针对Sec2的1050单位交换Sec1的20个有价证券。

并行执行这两条指令。

由实例1生成的消息如下：

(指令的映像)+(相关余额的映像：acc1/sec1＝1000，acc2/sec1＝300，acc1/sec2＝25000，acc2/sec2＝30000...)

由实例2生成的消息如下：

(指令的映像)+(相关余额的映像：acc3/sec1＝3000，acc2/sec1＝300，acc3/sec2＝5000，acc2/sec2＝30000...)

将两条消息依序写入定位引擎的增强指令队列166。

很显然，针对acc2/Sec1和acc2/Sec2两次给出相同的值。定位引擎154的责任是当第一次接收它们(精确值)时考虑这些值，以及当之后接收时丢弃它们(重新使用存储器副本来替代)。

定位结果将如下：

首先处理来自实例1的指令(顺序不重要)

在结算之前在本地存储器186中余额：

<空(Empty)>

在结算之后在存储器中余额：

<acc1/sec1>＝990(1000-10)

<acc2/sec1>＝310(300+10)

<acc1/sec2>＝25500(25000+500)

<acc2/sec2>＝29500(30000-500)

处理来自实例2的指令

在结算之前在存储器中余额(＝在在先指令的结算之后的余额)

<acc1/sec1>＝990(1000-10)

<acc2/sec1>＝310(300+10)

<acc1/sec2>＝25500(25000+500)

<acc2/sec2>＝29500(30000-500)

在结算之后在存储器中余额

<acc1/sec1>＝990(不变)

<acc2/sec1>＝330(310+20，由预加载器给出的值300被丢弃)

<acc1/sec2>＝25500(不变)

<acc2/sec2>＝28450(29500-1050，由预加载器给出的值被丢弃)

<acc3/sec1>＝2980(3000-20)

<acc3/sec2>＝6050(5000+1050)

最终队列168是本实施例的重要部分。其表示关于这样的决定的退耦(decoupling)方式，所述决定是定位引擎154关于给定指令(其与具有指令结果的实际实时报告的规则相关)的可接受性的决定和更新主数据库24的决定。这个退耦使得定位引擎154能够最小化其处理任务，因此比该其他情形具有更大的吞吐量。

定位引擎154的终结(finality)(所述时间戳表示，只要发生就确认结算指令)不是通过反映主数据库24中的定位引擎更新、而是通过将它们记录在最终队列168的更新执行指令中来达成。换句话说，将最终指令记录(更新执行指令)写入指令队列168，这是调度器156的输入队列。此时，原始处理指令被认为是最终的，即被执行的指令。调度器156的责任是生成针对指令的参与方的通知，以及传播关于更新器158的不同输入队列的更新(主数据隔离队列170)。主要目的是避免在工作的相同逻辑单元中混淆报告动作与数据库余额更新。

因为由定位引擎154生成的输出被限制为一个持久(persistent)消息(包含待要实施的所有主数据库更新，以完成基本指令)，由调度器156提供传播更新以及生成关于指令执行(例如，对实时的各指令处置处理162进行答复)的专用处理。针对输入端接收的一个消息，调度器156将写入输出(针对每个更新的资源写一个输出，以及针对每个生成的报告写一个输出)。为了处理整体吞吐量的要求，这个分配逻辑并行运行。调度器156是可扩展的(通过多运行一个程序副本而增加吞吐量)。

由调度器156生成的报告消息的格式为简单构造的文本消息。然而，这个格式必要时也可改为使用外部或ISO格式。调度器还被设置为生成处理时段报告，其列出在该时段期间发生的所有交易以及它们针对每个涉及的实体所具有的关于资源帐户文件30和累积资源值32的值的结果。

调度器156没有确定需要指示哪个主数据更新器190来进行更新。这反而留给以下所述的路由架构175和工作量均衡器176来进行。

提供路由架构175以辅助工作量均衡。经由路由架构175和工作量均衡器178，朝向在主隔离队列170之上的更新器158，针对初始输入列表164的输入和调度器程序188的输出得以发送。调度器程序188向路由架构175发送指令，而无须知道该指令的精确目的地(主隔离队列170)。路由架构175的目的是准备用来特定路由至平台上并行运行的多个可能队列之一的指令。在这个实施例中，路由架构准备用来适当地路由至多个初始输入队列164之一或主数据隔离队列170之一的指令。路由架构175增加两个技术字段：消息名称和工作量均衡密钥。消息名称描述在消息中包含的消息类型，以及将工作量均衡密钥设置为指令ID，以保证在相同报告队列中将报告两个后续执行尝试，以避免例如因排序问题而报告随后跟随有“指令失败”的“指令被结算”。这借助内部查询表来执行。

路由架构175还有能力给指令流增加新处理，以改变处理之间的指令的路由。也可给指令流增加新指令，抑制从处理发送指令，并在必要时复制指令。然后，通过以下所述的工作量均衡器176处理具有消息名称和工作量均衡密钥的指令。

在平台150的操作中，路由架构175的责任是决定是否发送处理指令，发送给谁，以什么格式以及在哪个实例上(用于并行处理)进行。路由架构175用于确保关于一个指令的报告被排在相同指令的在先报告之后。例如，在指令被最终接受之前已经失败若干次的情形下，报告处理指令被成功执行必须跟在相同指令156的失败结算报告消息之后。同样，每个失败指令的报告依序发送，以允许指示方对指令失败正确反应。

实例。第一指令处理尝试提供为失败，原因＝＞A方的资源帐户的等级不足以支持指令(A方可采取某些动作)。然后，第二指令处理尝试也失败，原因＝＞B方的资源帐户的等级不足以支持指令(B方可采取某些动作)。在报告时，重要的是A方的资源帐户失败消息之后跟着的是B方的资源帐户失败消息。当并行运行调度器模块时，路由架构175的责任是在调度器156的同一实例上发送针对一个指令的所有报告(针对指令标识符的工作量均衡)。

工作量均衡器176基于指令名称和均衡密钥(未示出)确定指令的最终目的地，指令名称和均衡密钥由处理平台150一并考虑来唯一描述每个指令。消息名称用于标识目标主数据隔离队列170，该目标主数据隔离队列170轮流馈送特定主数据更新器190(见稍后关于如何将每个主数据更新器190引导至更新的特定类型)。均衡密钥用于计算特定实例(主数据隔离队列170)。工作量均衡器176确保针对相同密钥总是选择相同实例(主数据隔离队列170)-见以下的简单实例：

实例：

消息名称＝“SECURITY_BALANCE_UPDATE(有价证券_余额_更新)”＝＞有价证券余额更新器

均衡密钥＝有价证券id＝13

并行运行的有价证券更新器的总数＝3

选择的实例＝13-(整数(13/3)*3)+1

＝13-(4*3)+1

＝13-12+1＝2

＝＞每次针对有价证券id 13进行更新时，将选择实例数2(消息路由)。

每个主数据隔离队列170简单地从调度器程序188接收指令(已经通过路由架构175和工作量均衡器176将其特别路由至该队列170)。每个主数据隔离队列170涉及特定主数据更新器190，其仅在主数据库24的特定部分24a、24b、24c上轮流运行。

更新器158专用于在主数据库24的一个特定分区24a、24b、24c中反映被定位引擎156宣称是最终指令的更新指令。因为每个主数据更新器190在唯一的数据库分区上独立工作，所以不受其他更新处理生成的任何潜在锁住的影响。此外，因为每个更新器190唯一地更新其管理的参考数据集合；所以其可执行更新指令的网络化。更新器的每个实例在其自身的密钥范围内工作(用于识别指令路被由至其处的更新器)，无论这些密钥是否被隔离至主数据库的特定部分。

存在如何具体实现更新器158的两个不同实施例。在一个实施例中，更新指令(更新)通过delta(即通过对资源帐户文件的值的改变)文档化。在另一实施例中，更新是通过资源帐户文件的最后值来文档化。以下描述这两个实施例，它们实行执行网络化的方式。

当更新通过delta文档化时，由主数据更新器190实现的网络化算法(未示出)包括在执行针对该资源帐户文件30的一个单独更新之前针对给定资源帐户文件30对每个指令的金额流动进行求和。当更新通过最后值文档化时，网络化包括将所述值保持为具有较高更新时间戳以及在更新陈述的“其中”句式中增加时间戳验证(见以下实例)。

更具体地，在最后值模型中，网络化处理寻求保持由定位引擎154执行的最后更新。在未确保更新序列时，网络化算法例如可在12:45:01接收最后值，然后在12:45:03已经接收最后值。为了实现更新，仅须考虑在12:45:03的最后值。当然，如果在数据库中反映了例如12:45:06的最后值，则必须忽略在12:45:03的值。这可在更新主数据时使用时间戳来完成，如下所示：EXEC SQL UPDATE(执行顺序更新)PP_SEC_BAL

SET BALANCE_VALUE(设置余额_值)＝输入中接收的最后值，

余额时间戳＝定位时间戳的最后值

其中余额ID＝来自更新请求的余额id以及

余额时间戳(DB中)＜定位时间戳的最后值

由更新器接收的更新消息是最终的(始终应用)。这意味着它们可被分组在一起，从而通过主数据更新器190将相同密钥的两个后续更新指令翻译成单个物理更新。

以下阐述最后值的实施例和delta值的实施例如何操作的实例。

最后值的实例。

更新器依序接收以下输入：

余额1 10000  2007-08-01-09.01.01.112335(时间单位为微秒)

余额1 12500  2007-08-01-09.01.02.100475

余额1 25000  2007-08-01-09.01.01.875221

余额1 12500  2007-08-01-09.01.02.077054

主数据更新器190依序检索所有更新。

针对第一个，其保持该值(第一次，余额是指在工作的当前逻辑单元中的)。

针对第二个，其在存储器中覆盖先前值(在未来将该请求与第一个比较)。

针对第三个，其丢弃，因为在第二个值之前已经生成该请求。

针对第四个，其丢弃，因为同样在第二个值之前已经生成该请求。

在提交时间(提交频率)，生成物理更新：

EXEC SQL UPDATE SET(执行顺序更新设置)余额值＝12500，时间戳＝2007-08-01-09.01.02.100475

其中余额id＝余额1以及时间戳＜2007-08-01-09.01.02.100475

如果数据库中的映像已经与提出的一个进行预期比较(futurecompared)，则时间戳条件将异常中断(abort)更新请求。

Delta的实例。

主数据更新器190依序接收以下输入：

余额1 10000  2007-08-01-09.01.01.112335(时间单位为微秒)

余额1 12500  2007-08-01-09.01.02.100475

余额1 25000  2007-08-01-09.01.01.875221

余额1 12500  2007-08-01-09.01.02.077054

主数据更新器190依序检索所有更新。

针对第一个，其保持该值(第一次，余额是指在工作的当前逻辑单元中的)。

针对第二个，其增加delta 10000+12500＝22500

针对第三个，其增加delta 22500+25000＝47500

针对第四个，其增加delta 47500+12500＝60000

在提交时间(提交频率)，生成物理更新：

EXEC SQL UPDATE SET(执行顺序更新设置)余额值＝余额值+60000

其中余额id＝余额1借助步进模块174确保队列通常为空并不是对遍及平台的指令流实现的唯一控制。在实时处理期间，定界符架构178确保在主数据库24中正确反映处理时段的结束之前执行的所有更新，以开始处理时段(其在调度器156中报告动作)的结束。

向最终队列168写入更新执行指令可被认为是平台150针对指令的最后执行，即使主数据库更新还未执行。然而，仍旧有必要从技术观点确保更新执行指令在关联主数据库资源帐户30的值之前实际上实现于主数据库24之中。

为了实现这个目标限制，定界符架构178提供这样的基本功能，即向最终队列的项部写入请求/应答消息。当接收到该应答时，意味着已经执行了先前写入最终队列的所有指令。

平台150中的指令处理流由依序执行的处理集合构成。具体地，主数据隔离队列170仅在更新执行指令通过最终队列168之后处理更新执行指令。由此，一旦从最终队列接收了应答，则依序向下一队列(即主数据隔离队列170)发送新的请求/应答消息。每个队列操作FIFO排序。

定界符架构178的功能不是核对主数据库是否在其中具有正确更新的数据，而是核对所有更新执行指令是否已经利用通过系统的不同处理阶段依序执行的这个核对而已经得以轮流执行。

当实现并行化时，处理可在多个队列上并行运行。为了确保所有队列已经处理了它们的积压项目，请求/应答消息不仅应写入它们之一，而是应写入全部队列。路由架构175的责任是检测消息应该发送至处理的n个实例，而定界符架构的责任是在开始下一处理的定界之前等待，直到接收了n个应答。

以下实例阐述了定界符架构178如何运行以确保在处理时段关闭之后由更新器158执行更新执行指令。

实例：

在特定时间，例如4PM，平台150定义执行指令的期限。一旦到期，则开始报告处理，从主数据库提取所有的执行指令，以创建待要发送至处理时段动作中所关注的参与方的顺序报告文件。

在4PM，调度器开始报告处理。

作为处理的第一步，定界符应用(utility)(未示出，但其为定界符架构178的一部分)用于生成和发送定界符消息至定界符核(未示出，但其也为定界符架构178的一部分)。基于接收到的消息，定界符核开始向待要定界的不同处理写入消息，以确保将由定位引擎154宣称为最终的所有更新反映至主数据库(调度器188和更新器190)。

作为报告处理的第二步，执行定界符完成核对应用(未示出，但其为定界符架构178的一部分)。其保持报告处理搁置，直到定界符核宣称完成定界符处理。当完成这个操作后，在下一步骤继续对报告处理的执行。

作为报告处理的第三步，基于在主数据中包含的精确数据执行调度器188中的报告商务(business)逻辑。

提取报告任务请求定界符架构178，以确保在4PM期限之前到达的更新执行指令由调度器156处理以用于报告目的，并且还将它们应用至主数据库24。当完成这个操作后，主数据库24状态反映了在该期限和提取报告得以如上所述精确生成之前验证的所有动作。

与图8至图12的实施例相关的上述特征已经在所附权利要求中加以阐述。应该理解，本发明的其他实施例可使用上述特征的子集来构建。例如，其他实施例可能不使用上述再循环特征，而是使用公知的备选特征。类似地，可改进或移除步进模块以提供不同的解决方案。然而，在选择备选的数据处理结构时，需要考虑其对吞吐量的影响。在本发明情形下，认为所主张的处理结构是提供了吞吐量的最佳可能程度的最佳结构。诸如步进模块等特征简单地改善了吞吐量。

这里已经对本发明的特定优选实施例加以描述，应该理解这些实施例仅是示例性的，并且可在不偏离于所附权利要求阐述的本发明的精神和范围的情形下，可作出对本领域普通技术人员而言将会出现的修改和变型。

Claims (27)

1.一种在处理时段期间实时处理和处置超大量处理指令的系统，每个处理指令指定涉及两个不同实体的资源帐户数据文件以及在这些文件之间待要交换的资源的数量和类型，该系统包括：

多个预加载器，每个预加载器被设置为获取关于指令的参考数据，所述参考数据指示每个指定资源帐户数据文件的当前值，以及所述多个预加载器被设置为并行操作以从主数据库读取针对多个各自接收的指令的参考数据；

加料指令队列，用于将多个处理指令与它们各自预加载的参考数据一起排队；

执行引擎，被设置为使用所接收的参考数据依序确定每个接收的指令是否在相关资源帐户文件的当前值下是可执行的，并且该执行引擎被设置为针对每个可执行指令生成更新命令；

多个更新器，响应于来自该执行引擎的更新命令，利用每个可执行指令的结果来更新该主数据库，将所述多个更新器的操作从该执行引擎的操作退耦。

2.如权利要求1所述的系统，还包括：初始输入队列，被设置为从多个不同源接收实时指令和批指令，以及对所述实时指令和/或所述批指令进行排队以输入至上述预加载器。

3.如权利要求2所述的系统，其中所述初始输入队列包括多个初始输入队列，其中的每一个初始输入队列被设置为给所述多个预加载器中对应的一个预加载器提供专用输入。

4.如权利要求2或3所述的系统，其中所述初始输入队列被设置为给每个进来的指令分配优先级。

5.如权利要求1所述的系统，还包括：当前状态表，其存储在该执行引擎处，并且该当前状态表被设置为利用针对资源帐户文件的执行指令的结果来被更新，从而获取每个更新后资源帐户文件的更新后的实时值的表示，其中针对指令的后续顺序处理，该执行引擎被设置为针对特定资源帐户数据文件优先于来自该预加载器的参考数据来使用该当前状态表中的信息。

6.如权利要求1所述的系统，其中每个预加载器包括主数据收集器，每个主数据收集器被设置为从该主数据库读取在每个可执行指令中识别的资源帐户文件的值和累积资源值，以及编译和输出包含从该主数据库读取的数据的加料处理指令。

7.如权利要求1所述的系统，其中所述执行引擎包括用于存储当前状态表的高速本地数据存储器。

8.如权利要求1所述的系统，其中所述执行引擎被设置为通过参照存储的预定规则集合来确定当前指令是否在相关资源帐户文件的当前值下是可执行的。

9.如权利要求1所述的系统，其中所述执行引擎包括：时间戳模块，被设置为确定所述处理指令之一的接收时间，以及创建时间戳并将其应用至所述处理指令。

10.如权利要求1所述的系统，其中所述执行引擎包括：再循环模块，用于在高速本地数据存储装置中存储失败处理指令的列表，以及用于执行再循环过程，其中在由该失败处理指令识别的资源帐户文件中已经发生更新后，呈上该失败处理指令以用于重新执行。

11.如权利要求10所述的系统，其中所述再循环模块被设置为按所述失败处理指令的优先级的顺序来存储失败处理指令，以及在再循环过程期间首先呈上最高优先级的指令用于重新执行。

12.如权利要求10所述的系统，其中所述再循环模块被设置为在该列表中保留针对指令的资源帐户文件的当前值，以及在再循环过程期间使用这个保留值以满足指令的要求。

13.如权利要求10所述的系统，其中所述再循环模块被设置为呈上失败处理指令用于重新执行到预定的最多次数，而如果所述失败处理指令仍没有被执行，则该再循环模块被设置为取消所述失败处理指令。

14.如权利要求1所述的系统，其中所述执行引擎包括报告模块，用于报告所接收的指令之一的执行结果，所述报告模块被设置为针对已经被确定为可执行的每个指令输出更新命令，以及针对每个失败指令输出通知指令。

15.如权利要求14所述的系统，其中所述报告模块被设置为临时存储多个更新命令，直到提交事件发生为止，以及在发生提交事件时输出多个存储的更新命令，其中所述提交事件表示通过该执行引擎的工作的一个物理单元的完成。

16.如权利要求14所述的系统，还包括：最终队列，被设置为从该报告模块接收更新命令和通知指令并对其进行排队。

17.如权利要求2所述的系统，其中每个更新器包括并行操作的多个更新实例，每个实例在该主数据库的唯一部分上操作。

18.如权利要求17所述的系统，还包括：针对每个更新实例的隔离输入队列，每个隔离输入队列被设置为接收属于该主数据库的特定部分的多个更新命令，其中该主数据库的特定部分由对应的更新实例更新。

19.如权利要求18所述的系统，其中每个隔离输入队列被设置为实行更新命令的网络化，其中所述更新命令涉及相同的参考帐户文件。

20.如权利要求18所述的系统，还包括：调度器模块，被设置为确定送至特定隔离输入队列的每个更新命令的路由，以及为不同实体创建报告消息，其中在所述报告消息中描述执行指令的失败或成功。

21.如权利要求18所述的系统，其中所述初始输入队列包括多个初始输入队列，多个初始输入队列中的每一个被设置为给所述多个预加载器中对应的一个预加载器提供专用输入；所述系统还包括：

路由架构，所述路由架构被设置为向并行操作的所述多个初始输入队列或隔离输入队列分发指令。

22.如权利要求21所述的系统，其中所述路由架构被设置为向指令分配指令名称和工作量均衡器密钥，其中该指令名称描述所述实时指令和/或所述批指令涉及的信息类型，该工作量均衡器密钥提供识别所述实时指令和/或所述批指令的唯一密钥。

23.如权利要求22所述的系统，其中所述路由架构包括与所述路由架构组合设置的工作量均衡器，以通过使用所接收的指令名称和工作量均衡器密钥来选择初始输入队列或隔离输入队列之一。

24.如权利要求23所述的系统，其中所述工作量均衡器被设置为将给定的工作量均衡器密钥链接至相同的特定目的地，以确保与特定资源帐户数据文件相关的所有指令始终被路由至多个队列的同一个队列。

25.如权利要求1所述的系统，还包括：定界符架构，被设置为响应于处理时段在给定时间的关闭，向在该执行引擎的输出端处提供的队列的输入端发送消息并等待其响应，以及向多个更新器之一的输入队列发送进一步的消息并等待其响应，依序响应的接收指示利用在处理时段的关闭之前执行的所有处理指令的结果来更新该主数据库。

26.如权利要求25所述的系统，还包括：调度器模块，被设置为确定送至特定隔离输入队列的每个更新命令的路由，以及为不同实体创建在其中描述执行指令的失败或成功的报告消息；以及其中

所述定界符架构还被设置为向该调度器模块的输入队列发送消息，并等待各自的反馈，以验证针对在处理时段关闭之前执行的处理指令的报告消息都已经被发送。

27.如权利要求1所述的系统，还包括：步进模块，用于确定该执行引擎的处理指令吞吐量，以及将等待状态应用至任意队列，以将处理指令的加载速度减慢至小于该执行引擎的吞吐量。